This test is to determine the refresh rate of a given mode exactly and in so doing it also determines how long TimeDX should spend when it determines the retrace rate automatically for the Vertical Retrace Sync Test test.    Without Enhanced Rate Detection this was an extremely sensitive test, with Enhanced Rate Detection you can pretty much forget about this test (unless you are using an LCD flat panel display, see below) beyond making sure that it doesn't throw an error.  If you cannot get the test to run without flagging an error all other programs should be closed when using this test, particularly things like MS Word.  The BIOPAC Acquire program is also horrendous, until they change the program so it doesn't use every single CPU cycle even when it isn't doing anything DMDX and TimeDX are going to have a tough time doing accurate timing.

    The refresh rate test was completely redesigned for version 2 of TimeDX, what it does is setup two screens with the text "Refresh Rate <>" and "Refresh Rate ><" and flips between them as fast the hardware will allow, which should be at the refresh rate.   With version 3.0.02 of TimeDX the Enhanced Refresh Rate determination code was added and with it turned on (as it should be by default) as long as the test doesn't report an error it's accurate to 0.01ms using default settings.   Without the Enhanced Rate Determination on you must pay attention to the visual display, when the test is working properly you should see the sets of angle brackets imposed on each other, smoothly, there should be no flickering beyond the first few flips.  You should see four little Xs in a 2x2 grid that should be dimmer than the Retrace Rate text except at the centers of the Xs where they will have the same intensity as the Retrace Rate text. Sometimes a machine just gets flat out ornery and this test coughs and farts producing results all over the place, restart TimeDX and all is plain sailing again.  In the past when I experienced this problem it was directly attributable to MS Word, closing it removed all trace of instability.  These days it's usually a LCD flat panel running at a non-native resolution (see below) adding yet another complicated wrinkle to everything.  Although the display might be flickering all over the place TimeDX might in fact determine the retrace interval correctly because it's the panel itself causing the flickering, not the computer.  Using the Enhanced Rate Determination the test waits until these flickers stop, otherwise the user has to recognize the visual indications of poor testing conditions by observing this test a number of times and noting the visual display when results are produced that differ from the majority of tests -- if in the Vertical Retrace Sync Test you notice a visual indication of a poor retrace rate determination you can perform the test again by clicking the Re-Determine Automatic Values button.   But unless I've overlooked something in the Enhanced Rate Detection code it should be set and forget.
    Another good check is that a number of monitors these days sense what the refresh rate is and store brightness, contrast, etc, parameters for each video mode, when you adjust these the monitor usually displays the current refresh rate in Hertz, invert this number and that is the number the Retrace Rate determination code should be coming up with, if it's not you need to tweak it's parameters until it does.
   
    The user can control how many cycles (flips) are performed to determine the refresh rate in the Number of Cycles to Time edit box.  This value (that determines the minimum time the test runs for) is stored in the registry and used by the Vertical Retrace Sync Test when it determines what the automatic timing values should be for any given video mode.   The default value of 100 is perhaps a bit brief if you aren't using the Enhanced Rate Detection mode but 100 cycles typically yields values that are accurate to 0.01ms with the Enhanced Rate Detection.
   
    The Enhanced Rate Detection mode will keep on flipping screens until it gets the number of uninterrupted flips specified in the Number of Cycles to Time edit box, should a machine not be ever able to get those number of flips without error the detection will abort with an error after the number of cycles specified in the Maximum Number of Cycles to Time box.   Under those circumstances you should get some newer drivers for your video hardware, if you have the most recent drivers then you'll be forced to lower the number of cycles the Refresh Rate test uses to determine the retrace rate.   This will reduce the accuracy of the test but you won't have any choice other than getting some other video hardware or changing the operating system.   Without Enhanced Rate Detection checked the Maximum Number of Cycles to Time box becomes the Number of Cycles to Ignore and specifies how many cycles are to be ignored at the commencement of timing.
   
    The user can also flag whether the routine is not to check for other activity as the test is running.   I stuck this is in in the hope that perhaps I could block MS Word's interference with it but alas it doesn't look like it -- the design of the Enhanced Rate Detection mode renders this consideration moot however.   Checking this checkbox stops the timing routine from processing windows messages, if checked you won't be able to abort the timing loop (so if you specified 10000 loops you'll be waiting for them) but there's less chance the timing loop will be interrupted.
   
    There is a possibility that the hardware may be cheating on flips (see flip waiting time at the end of the Video Mode selection), by buffering a number of flips up so benchmarks look better.   While the Enhanced Rate Detection mode renders such cheating irrelevant without Enhanced Rate Detection there will be a constant number of frames error in this test's determination and a larger Number of Cycles to Ignore will be needed to get around the error.   There is code to detect this cheating in the non-enhanced old code and a dialog will be displayed at the end of the test if it is found to be suspicious and the current parameters are not dealing with the cheating well.   There are two values reported by this test that are times spent at the very beginning when flips are not being timed and then at the beginning of timing.   If the drivers are buffering up flips the first of time will almost always be less than 0.1ms but the second should always be much greater 0.1ms (the cutoff), it should in fact be very close to the retrace interval. Should you get one of these alerts do the test again or restart TimeDX (closing MS Word should it be open), if you still consistently get this error you will have to use greater periods of time to determine the retrace, usually increasing the Number of Cycles to Ignore is enough, if values from successive runs still fluctuate the Number of Cycles to Time should be increased as well.   If no consistency can be had (and for some reason you can't have the Enhanced Rate Detection mode turned on) you might have to turn on the Read Between Flips to Stop Cheating Drivers check box, however no video card has been perverse enough to require this checkbox, indeed, turning it on breaks everything so far (you can see stalls as the test runs) and it is left in there because I don't want to delete code that could be useful some day on some future setup that I can't predict currently (that day arrived a few years ago, it's now fairly common to need it, but you can't just turn it on all the time as it kills other drivers...)



LCD Flat Panel Displays.

    The prevalence of TFT or LCD flat panel displays these days introduces new and critical issues for tachistoscopic displays when using the non-native resolutions of the flat panel and it just so happens that the Refresh Rate test is a really good way of detecting whether you've actually selected said native resolution or not.  When a flat panel sees a video signal that's not at it's native resolution it has to render that video data into it's own resolution, this takes time and thus lags the display and can also drop whole frames of video data so selecting the native resolution as the video mode becomes critical.  The Video Mode dialog now has a button to select the desktop resolution which is normally but not always the native resolution and in addition there are flat panels that only operate correctly at particular retrace rates so the video mode selection really has to be checked against the monitor in real time to see whether the monitor is screwing things up and the Refresh Rate test is a really good test because it presents a continuous train of different displays which the unaided eye can easily detect changes in.  So when the monitor drops a frame you see the display flicker.  Which presents a bit of a problem as a failure anywhere produces the some sort of flickering display, you can have cheating drivers (or other more severe problems) producing flickering and you can have the monitor producing it leaving the poor user with even less clue as to what's happening.  Principle difference here is that TimeDX can time the display correctly while it's flickering due to monitor based non-native resolution factors whereas the other flickering (caused by drivers or worse) won't get timed correctly till the Stop Cheating Drivers checkbox gets set the right way (or otherwise fixed).  So if you see the Refresh Rate test correctly determine the refresh rate in a reasonable period of time but the display is still flickering you can be sure you're not using the native resolution of the flat panel as the flickering is being caused by the panel.  To cap it all off I've seen recent examples of flat panels that operated at 60, 70 and 75 Hz, some of them only operate correctly at 60 Hz, others at 75 Hz.  So the Refresh Rate test becomes your acid test for determining what display you should use.  If the Refresh Rate test is operating quickly and giving the right sort of results but the display is flickering Stop Cheating Drivers is set correctly but the display resolution and or the refresh rate isn't to the monitors liking.  Get it all right and you'll finally see an even display.  All is not lost however, even if you get everything wrong (assuming you get half way correct video timing parameters in the Vertical Retrace Sync test) the worst error DMDX is going make is still only a couple of ticks or so so all of this only really matters to people doing masked primes and other sorts of tachistoscopic displays.  And color depth doesn't appear to be a variable so you've still got the choice of 16 or 32 bit displays.

    There's a rather good article on LCD flat panels on X-bit labs:  Contemporary LCD Monitor Parameters: Objective and Subjective Analysis.  Saved version is here.


TimeDX Index.