Back to the roots! Sorry to bring up an old post but I thought it would be interesting to see how the sum of lag adds up when we know so many factors. Let's start from the beginning calculating with no vsync at 180 fps... Wheel: 2 +/- 2 ms (500 Hz = 2 ms, assuming 0% CPU load) Physics: 1.5 * 2.5 +/- 0.5 * 2.5 ms (400 Hz = 2.5 ms, assuming 100% CPU load) Rendering: 5.5 ms (180 fps = 5.5 ms) Frame delay: 10.5 +/- 10.5 ms (0.5/60 Hz + 0.5/180 fps = 8 + 2.5 ms) Monitor input lag: 19 ms Total: 40.7 +/- 13.7 ms (27.0 - 54.5 ms) Which I think sums up pretty well to your minimal measured time, but there is quite an interval.
I was taught many years ago in driver training class to watch the front wheels of the cars around you because the wheel will turn before the car will. I have always found this to be true and it saved me from many accidents. How much input lag is there with a real car?
Depends on how much wear it has. The steering will lag, the engine will lack response. Under zero degrees celisius it will actually freeze. A good thing looking at the front wheels are when they turn you know in what direction to turn the steering wheel.
Besides everything else, real vehicles have to overcome the slip angle of the tire in order to effect a change of direction of the car.
This morning I came up with this example. I think it could be informative for those who are still struggling with why the refresh rate will cause lag. It should also be equally important to those who are making lag experiments with camera. Lets take Keikei's numbers in this example. At 180 fps and a 60 Hz display you will have 180/60 = 3 tearing lines. As said previously tearing lines is caused by that the graphics card can render frames faster than it can transfer them to the monitor. As it has rendered a new frame it will simply switch frame buffer and continue sending from the same position within the new buffer instead. The above will make the screen look like this after the monitor has made a full screen refresh. The line at the bottom tries to illustrate this, where the current refresh line of the monitor is. As I'm to lazy to do any drawing we'll have to do with ASCII art. HTML: AAAAA BBBBB BBBBB CCCCC CCCCC _DDDDD_ A, B, C, and so on represent different frames generated by the graphics card. If we have a smooth frame rate the two bands in the middle would be of equal size in height and the upper and lower bands will together be roughly he same size as either of the other two. The actual position and size of each band doesn't matter for a rough measurement. The time difference between each band (frame) should be 1/180 = 5.5 ms. Let's say that the camera run at 180 fps as it will make the example a lot easier. If so we will have 180/60 = 3 camera frames for every complete refresh of the screen. We divide the screen into three equal parts and update them. Let's draw a couple of these frames and also mark out the refresh line. HTML: 1 2 3 4 5 6 7 AAAAA DDDDD DDDDD DDDDD GGGGG GGGGG GGGGG BBBBB _EEEEE_ EEEEE EEEEE _HHHHH_ HHHHH HHHHH BBBBB BBBBB EEEEE EEEEE EEEEE HHHHH HHHHH CCCCC CCCCC _FFFFF_ FFFFF FFFFF _IIIII_ IIIII CCCCC CCCCC CCCCC FFFFF FFFFF FFFFF IIIII _DDDDD_ DDDDD DDDDD _GGGGG_ GGGGG GGGGG _JJJJJ_ GGGGG HHHHH IIIII JJJJJ KKKKK LLLLL MMMMM The screen will be updated as the refresh line moves over the screen. As you can see there will not only be three bands of tearing but actually four as the refresh line advance downwards. That tearing is hower moving so fast that it can not be detected by the eye but when taking images with a camera it will be captured. It will take 3 frames from the camera for the monitor to complete update the image. You will also notice that I have added a seventh line below the screen, that is the steering wheel. The steering wheel is our reference to the acual time. The lag in this example is less than in Keikei's case as the space will not permit it to be any longer to fit on the page. Let's say that the steering wheel ingame is displayed on the lower half of the screen, the last three rows. Now we visually detemine the lag of the steering wheel by matching each row in the frame on the screen with the steering wheel. In the first frames 1-3 we do not have any reference that match the position of the steering wheel so they are useless to us. In frame 4 we can match the last row in the frame to the wheel position at frame 1, 3 frames delay (*). In frame 5 it is the same match but now the delay is 4 camera frames. In frame 6 we can match the fourth row with the the steering wheel at frame 3 and the last row with frame 1 but the fifth row the steering wheel is still not within our reference. If we have started the recording earlier we could see that the delay would have been 3, 6, and 5 frames. In frame 7 we have the same problem again giving us either a delay of 5 or 3 frames. Which value should we use for our lag computation? Always taking the lower value will of course make us look good when we are posting our lag score. The answer is that idealy we should score the bands separately. I am pretty sure that the eye can not detect different lag in different parts of the image. The brain will translate the image and make some sort of average number for it as a whole. And that is what I think we should do as well. Take every frame captured and calculate the average of every band. However, it turns out that we only need the min and max values to calculate the average. In the above case the min and max would be 3 and 6 frames giving us an average of 4.5 +/- 1.5 frames, that is 25 +/- 8 ms of lag. (*) As the position of the real steering will probably never match the one displayed on the screen you could do some sort of interpolation the get better precision in the lag value.
Yeah that's the way screen is drawn. However changing alphabets to numbers (A=1, B=2, etc.) could make the example more readable.
Wow, congratulations KeiKei! Thanks for updating us with the new monitor. You are capping the frame rate to 143 fps (why?). Is there a hit in frame rate going from 60 Hz to 144 Hz refresh rate? I think the memory bandwidth shouldn't be a problem, even with tripple screen it's only a couple of GB/s data transfer to the screen. In the middle of the screen shouldn't it be about 0.5/144 = 3.5 ms?
It's because capping the framerate close to monitor refresh rate makes the playback smoother. By capping the framerate frame or two lower than monitor refresh rate puts tearing line into constant movement so it's less distractive that way. Just trying to make test cases similar how people would use it. Hmm actually now that I think of it then if max pre-rendered frames = 1 is doing exactly as it says then the average difference in input lag would be at maximum the length of one frame. With 60 Hz monitors it should be max 16,7 ms (Test 2 shows 14 ms difference by the way), 120 Hz monitors should have max 8,3 ms and 144 Hz max 6,9 ms. Measurements showed 5,5 ms for 144 Hz monitor so it's also close enough compared to theoretical 6,9 ms. Thanks, I'll remove that part from conclusions.
Yes, you have a point there. Have you tested the above? Correcting my answer from last night: Compared to vsync off, vsync on will have the same average input lag on the screen at indentical fps. However, with vsync on you will always have the least lag from refreshing the display at the top of the screen (+0 ms) and the most at the bottom of the screen (+16.7 ms @ 60 Hz and +6.9 ms @ 144 Hz), and the average in the middle of the screen (+8.3 ms @ 60 Hz and +3.5 ms @ 144 Hz). With vsync off you don't know the lag on individual parts of the display as it can vary between extreems on any screen so must calculate with average for all lines.
This should be something you guys are interessted in. http://www.leobodnar.com/shop/index.php?main_page=product_info&cPath=89&products_id=212 Over there at the iRacing forums they have a nice community project starting. They are going to share one in the community and try to put a big database together. Sound good to me. But people have to trust each other. Leo is even giving it for free for the community.
Haven't noticed and basically haven't even monitored. I don't understand how changing refresh rate would have any impact on framerate. Maybe I don't understand the question? That's why I measured the input lag from middle part of the screen and did lots of measurements from every test case and calculated averaged values. But it's still not the absolute truth between synced and non-synced because upper part of the screen for sure has little impact on how the input lag is experienced.
Actually I'm not very interested about it anymore because I know my monitor input lags thanks to tests made by PRAD. But for sure very handy tool for testing monitor input lag.
Refreshing the screen at 144 Hz need almost 2.5 times the bandwidth over 60 Hz to transfer screen data. Every byte of data need to be fetched from graphics memory. However, with 1920x1080 @ 144 Hz it is only a couple of GB/s so it is unlikely that it would hamper a card with over 100 GB/s more than a few fps even if memory is a bottleneck.
Well I don't know how things work inside graphics card but believe changing refresh rate doesn't have any impact on how many frames it's able to calculate. I believe those two processes are separate at hardware level and changing monitor refresh rate doesn't affect to the earlier process where individual frames are created.
They compete over the same memory, so if memory is a bottleneck frame rate will suffer. Display data must be read from memory at the same time as the GPU need to read/wriite it's data. That's why we used to have special dual-ported VRAM graphics memory so the RAMDAC's could read memory independently of the graphics processor. With the introduction of faster SDR technology I belive dual-ported memory disappeared from graphics cards. (VRAM used to mean a special type of dual-ported RAM but nowdays it has taken the meaning of any kind of RAM on a graphics card.) But as I said, display data will only need about 3% of the bandwidth in your case so few fps loss at most is expected.
The only possible effect on the GPU would be that it couldn't keep up with the requirements of the refresh rate of the monitor. For instance if your GPU is only able to run at 70FPS at 60Hz, running at 120Hz is going to kill your GPU, hehe.
No. The card only has so much memory bandwidth. Highest priority will always go to fetching output data to the monitor. When that happens it will block the GPU's access to the memory. The GPU will have to wait until the memory bus is ready and can't do any work in the meantime. Whenever there is a free slot on the memory bus the GPU is able to use the memory again and can continue with its work. The GPU will not die but stall. But as I said the data rate to the monitor is about 3 GB/s of a total of 128 GB/s on the 560Ti. That means that there is roughly a 3% chance of a stall.
