The delay measured for 7 monitors

The delay measured for 7 monitors

After practical tests, here is something more precise. This time we measured the possible delay of LCD monitors to a 1/1000th of second. We realised four points:
- the CRT monitor was never late compared to a LCD monitor.
- the delay isn´t due to the refreshing rate: 60Hz or 75 Hz doesn´t´ change anything.
- it isn´t due to the interface. One monitor won´t be faster in DVI than in analog. The double conversions do not slow down the monitor. It’s important to remind you that all CRT function with analog signals.
- the delay changes with time. We took ten measurements in a row to look for the maximum, minimum and, most of all average, delay.


In this example, the dell monitor is 32 ms late. This value comes back regularly and corresponds to a delay of two images.

Delay in ms compared to our reference Mitsubishi CRT
Measurements were taken with a DVI input at 60 Hz.


With a couple of exceptions (the ViewSonic VX922), the 6 LCD monitors are on average one to two images late (60 Hz = 1 images every 16.7 ms).

This delay is subject to variations. Here are three examples of delays (in ms) measured for 10 consecutive tests between the CRT and the monitor tested:


The VX922’s result is excellent and this compensates for the difficulties in the 19 inches survey.

1 delay, + 1 delay, +... (mouse, graphic card...)

1 delay, + 1 delay, +... (mouse, graphic card...)

The delay wouldn´t be problematic if it was isolated. In fact it is the conclusion of a whole chain of events that we should try to minimise.

It begins with the peripherals devices. Whether we used a cabled or wireless mouse, none reacted immediately. A "normal" mouse in principle is restricted to an exchange frequency of 125 Hz for the USB hub or one exchange every 8 ms. This is a systematic delay of 1 to 8 ms for every command and we are talking about a good mouse. We found some that sent signals much less often and the delay can easily go up to 16 ms. Now, a "new" generation of mouse went over this limitation at 125 Hz and benefits from the high transfer rate of the USB2. Some mouses like the Razer go up to 1000 Hz and this corresponds to an optimum latency of 1 ms. In fact our tests showed some instability of these systems. We never stick to 1000 Hz. The transfer rate varies from 50 to 1000 Hz with an average noticeably higher than the 125 Hz of the USB 1 mouse. The gamer product line of Logitech reaches 500 Hz with some instability.

Then comes the graphic card. Here we have two options…

1: The easy way: Say that we have a very powerful processor coupled to a very high end graphic card. In short, we minimised calculation time and even neglected some of them. Also, I estimated that the graphic card will always provide more than 60 fps in games and even 100 fps, which is easier for measuring purposes.

2 : I remembered that I work with two graphic cards authorities, Damien Triolet and Marc Prieur. I described my problem to them and immediately I regretted it as they just made my life more complicated. Inevitably with these guys you have to get into details. My calculation is accurate, but if we want to be a little bit more accurate…Here is the beginning of their dark thoughts for those who want to think about it a little more, complete calculations, make them more precise and have a better evaluation of the possible problems:

A graphic card uses two buffers, one in which the image is calculated and another in which the image to be displayed is read. One image can only be displayed after being entirely calculated.

In Vsync OFF, when the graphic card has calculated the image in the buffer A, it directly inverts the A and B buffers, regardless of the eventuality that the buffer B was being read and about to be displayed. If this was the case, the image displayed would be half of the image n-1 and half of the image n. There are two different parts of the image and two different delays. Between two refreshing of the monitor several images might have been calculated if the graphic card and processors are very efficient. In this case, the delay coming from the graphic card is comprised between twice the image calculation time and one times the calculation time with a possible difference between the different pieces of the image displayed. It all depends on the power of the graphic card and processor.

In Vsync ON, this problem is avoided because the buffers A and B can be inverted only when the monitor has just been refreshed. When the graphic card has calculated the image in buffer A, it waits before reaching this point to invert buffers. Then buffer A becomes buffer B and vice versa. With a 60 Hz monitor, buffer B is read 60 times per second, but it doesn´t mean that it is updated 60 times per second! If the graphic card is still capable of calculating the image in less than 1/60th of second, it is perfect, the delay will always be 1/60th of a second. If the graphic card takes more time, it finishes the calculation after the monitor refreshment at the only moment when it can invert the buffer and will have to wait for the next refreshing. It means that the same image will be displayed two times. The first time, it will be 2/60th of a second late and the second time 3/60th of second. The problem is accentuated by the fact that the calculation time of an image is variable in the game and the delay can increase from 1/60th to 3/60th while the scene progresses. This can lead to a significant delay in addition to the framerate disruption. In Vsync ON, it is crucial to have a system capable of ensuring fps at least as high as the refreshing rate. We don´t decrease from 60 to 50 FPS but directly from 60 to 30 even if the average can mask it.

It is also helpful to understand that the game engine has a role to play and that triple buffering can reduce the shifting that happens in VSync ON at the expense of a higher generalised delay.

All this to say that you can complicate the calculation by changing the initial parameters. If you think this is fun, you can start all over again and estimate that the graphic card won´t sustain a framerate of 60 or 100 fps in the following examples. I took the first option.

3 cases and conclusion

Back to option 1 : the easy way

We will have the best reaction time with the Vsync option OFF as the card progressively sends the calculated information to the monitor. There is however one little delay (less than one image) for the display due to calculation times.

Vsync OFF is the optimum solution. The problem is that it introduces ruptures in images. Aesthetically, it is less nice. Very often mostly with LCD, we activated the synchronisation of the card with the monitor. The monitor displays images only when they are fully calculated. It is nicer, but the framerate is reduced (we are restricted by the monitor refreshing rate, or 60 fps for 60 Hz like most of the monitors) and the delay increases. This time it is 2 whole images (on average).

The last solution is that some use Triple Buffering to smooth the framerate. This solution, which is less and less used, increases the delay to 3 images (on average)!

Lastly, there is the monitor. We voluntarily neglect the processor calculation time to simplify the analysis.

Conclusion of the delay chain, three possibilities

In the end, if the optimum solution is chosen, we will have one Razer Copperhead mouse, one graphic card with V Sync OFF and one CRT. The delay will be 1ms + 0.5 images (with a frequency at 100 Hz, it will be 1/100/2= 5ms) + 0 = 6 ms. Less than one image of delay, which shouldn´t be perceptible.

Standard solution: a good USB 1 mouse (all Microsoft´s, most of Logitech´s, the cheap razer) + V Sync ON + average LCD, type Dell 2407WFP monitor. The delay is now 8 ms + 2 images (LCD = 60 Hz, or 33 ms) + 24 ms = 65 ms. Almost 4 images late!


Unrecommended solution: slow mouse + Triple Buffering + slow monitor (Acer AL2032W). 16 ms + 3 images (3 x 16.7 = 50 ms) + 44 ms (the longest delay measured with the Acer monitor) = 110 ms, or 6.5 images late!!!

Where does this delay come from? It’s hard to tell for now and we will have to investigate a little more. Nevertheless this new test sends us back to our previous article: Panels a la carte: Mura, components, dead pixels.... Almost certainly, the quality of electronic components must play on the monitor reaction time. And as we said before, these electronic components have a direct influence on the quality of monitors. It has an influence on the longevity of components, color quality in time, rate of dead pixels, and Mura effects. We will have to add to the list the problem of reactivity measured on most monitors. Anyway, we have found here a new test to add to our procedure…

Thanks to Marc and Damien for their help … and patience.