NOTICE Notice: This is an old thread and information may be out of date. The last post was 424 days ago. Please consider making a new thread.
Page 1 of 10 12345 ... LastLast
Results 1 to 20 of 193

Thread: Input lag measurements

  1. #1
    KeiKei's Avatar

     rFactor 2 Validated PC Specification 

    Registered
    May 2012
    Location
    Finland

    Input lag measurements

    Introduction

    I was studying my PS3 Eye Camera the other day for head tracking software and found out it could be used to capture video with pretty high framerates. Finally I had tools to do some input lag measurements with different graphics settings. For those who are not familiar of what input lag is I would recommend reading for example:

    http://en.wikipedia.org/wiki/Input_lag

    By term input lag in tests below I mean the total latency from turning real steering wheel and seeing the game react on monitor screen as a rotation of virtual steering wheel. In other words the latency from your hands via simulator to your eyes. This total latency is roughly a sum of following individual latencies:

    • Steering wheel latency (polling rate)
    • Game engine latency caused by calculations (at least physics and graphics engine)
    • Graphics card latency caused by possible image processing etc.
    • Refresh rate latency caused by how screen is drawn (continuous stream of data in serial form)
    • Display latency or lag (=monitor input lag) which is a sum of two individual latencies:
      - Latency from processing display signal and possible post-processings like overdrive etc.
      - Latency from pixel response time (time required from pixel to change it's visible state)


    Having low input lag in simracing is very important because otherwise you're always reacting late; you turn too late, you brake too late, slides are almost impossible to control properly, driving consistent lap times is very difficult, etc. Too much input lag will make you a lot worse driver than you really are.


    Materials and methods

    I tested input lags with two different monitors:



    Note: Based on user manual of Asus VG278HE it may be that the 144 Hz mode only works with some compatible nVidia cards:

    You must select one of the “*” timing for enabling 3D or 144Hz feature with a compatible NVIDIA-GPU graphic card via Dual-link DVI cable connection.

    So I pointed PS3 Eye Camera towards display and set maximum capture setting 187 frames per second. Also lowered seat position for virtual car so that upper part of the virtual steering wheel was closer to the middle of the display vertically (that's where meaningful things happen when driving a car hence should be the area where the input lag is measured from). Then I rotated steering wheel (Logitech G27) about 60 degrees from left to right as fast as I could and examined delay between real and virtual wheel from the captured video with some free video editing software called Avidemux.

    1000 ms divided by 187 frames per second means that one frame of the captured video lasts about 5,3 ms so that's basically the maximum accuracy I could achieve. Tried to calculate the delay from multiple places of the video so that measurement errors could be minimized.


    Results

    First results are from 60 Hz monitor:

    Code:
    First number in second column is how many frames game engine is sending to display.
    Second number inside brackets is the "inner" framerate of the game engine which basically
    means how many frames it could send to display (high values are achieved by lowering
    graphics settings and level of details).
    
    
    #1	178 (200)	Sync Off, Max framerate = 178			26 ms
    
    #2	117 (200)	Sync Off, Max framerate = 117			32 ms
    
    #3	 60 (200)	Sync Off, Max framerate = 60			38 ms
    
    #4	 60 (~65)	Sync Off, Max framerate = 60			59 ms
    
    #5	 59 (200)	Sync Software					27 ms
    
    #6	 59 (~65)	Sync Software					37 ... 64 ms
    
    #7	201      	Sync GPU					27 ms
    
    #8	 61      	Sync GPU					43 ... 54 ms
    
    #9	 60 (200)	Sync Video					113 ms
    
    #10	 60 (~65)	Sync Video					102 ... 112 ms
    
    #11	 60 (200)	Sync Video, Triple buffering			112 ms
    
    #12	 60 (200)	Sync Video, Max pre-rendered frames = 1		80 ms
    
    #13	 60 (~65)	Sync Video, Max pre-rendered frames = 1		75 ms
    
    #14	 60 (200)	Sync Adaptive + Max pre-rendered frames = 1	59 ms
    
    #15	 60 (~65)	Sync Adaptive + Max pre-rendered frames = 1	64 ms
    
    
    Sync Off, Sync Software, Sync GPU and Sync Video are rF2's settings.
    Max framerate is rF2's setting located in file player.plr.
    Triple buffering, Max pre-rendered frames and Adaptive vsync are settings in
    nVidia Control Panel.

    Second results are from later test session carried out with both 60 and 144 Hz monitors. In these tests I tried to improve the analyzation of the captured videos by doing more measurements (~10 for each video) from different parts and calculating averaged values:

    Code:
    Asus VE278Q @ 60 Hz
    
    Test #16: Sync Off, Max framerate = 178
    
    Framerate:			    178 FPS
    Frames produced by game engine:	   ~200 FPS
    Minimum/maximum latency:	  21/43 ms
    Fluctuation:			     22 ms
    Average input lag:		   31,2 ms
    
    Test #17: Sync Off, Max framerate = 60
    
    Framerate:			     60 FPS
    Frames produced by game engine:	    ~70 FPS
    Minimum/maximum latency:	  32/59 ms
    Fluctuation:			     27 ms
    Average input lag:		   47,6 ms
    
    Test #18: Sync Adaptive, Max pre-rendered frames = 1
    
    Framerate:			     60 FPS
    Frames produced by game engine:	    ~70 FPS
    Minimum/maximum latency:	  53/69 ms
    Fluctuation:			     16 ms
    Average input lag:		   61,6 ms
    
    
    
    Asus VG278HE @ 144 Hz
    
    Test #19: Sync Off, Max framerate = 143
    
    Framerate:			    143 FPS
    Frames produced by game engine:	   ~175 FPS
    Minimum/maximum latency:	  21/32 ms
    Fluctuation:			     11 ms
    Average input lag:		   28,4 ms
    
    Test #20: Sync Adaptive, Max pre-rendered frames = 1
    
    Framerate:			    144 FPS
    Frames produced by game engine:	   ~175 FPS
    Minimum/maximum latency:	  32/38 ms
    Fluctuation:			      6 ms
    Average input lag:		   33,9 ms

    Third results contain further test cases with Asus VG278HE 144 Hz at various refresh rates and with better lighting for camera:

    Code:
    Settings: Sync Adaptive, Max pre-rendered frames = 1
    
    Test #21
    
    Refresh rate:			    60 Hz
    Frames produced by game engine:	   ~132 FPS
    Minimum/maximum latency:	  70/80 ms
    Fluctuation:			     10 ms
    Average input lag:		   72,9 ms
    
    Test #22
    
    Refresh rate:			    120 Hz
    Frames produced by game engine:	   ~132 FPS
    Minimum/maximum latency:	  38/48 ms
    Fluctuation:			     10 ms
    Average input lag:		   43,1 ms
    
    Test #23
    
    Refresh rate:			    144 Hz
    Frames produced by game engine:	   ~152 FPS
    Minimum/maximum latency:	  32/38 ms
    Fluctuation:			     6 ms
    Average input lag:		   36,5 ms
    
    Test #24
    
    Additional settings:      Anti-aliasing Off
    Refresh rate:			    144 Hz
    Frames produced by game engine:	   ~190 FPS
    Minimum/maximum latency:	  32/40 ms
    Fluctuation:			     8 ms
    Average input lag:		   36,8 ms

    Fourth results from testing Asus VG278HE @ 120 Hz with LightBoost technology:

    Code:
    Settings: Sync Adaptive, Max pre-rendered frames = 1, LightBoost On
    
    Test #25
    
    Refresh rate:			    120 Hz
    Frames produced by game engine:	   >120 FPS
    Measurements:			     17
    Minimum/maximum latency:	  32/34 ms
    Fluctuation:			      2 ms
    Average input lag:		   32,4 ms

    Conclusions

    Test 1:

    As PRAD stated in it's review it seems like this particular Asus VE278Q 60 Hz monitor has some extra lag because of the overdrive technology it uses. So at least for this monitor low input lag (20-40 ms) can only be achieved by high "inner framerate" which requires some or combination of; powerful hardware, low graphic settings / level of details and/or optimized game/graphics engine. Moderate input lag (40-60 ms) can be achieved multiple ways whichever works best for the hardware and gives smooth playback. High input lag (over 70 ms) should be avoided because it really starts to hurt one's driving and makes it very hard to be able to drive consistently. Oh and it looks like Triple buffering isn't working with DirectX as many have stated at various forums in the past.

    If your main goal is to be as fast as possible and hence want extremely low input lag then try this: Smooth 179 FPS and very low input lag on 60/75 Hz monitors (in expense of details)

    If you prefer eye candy over little extra input lag then I think combining Adaptive vsync, Max pre-rendered frames = 1 and Auto detail framerate = 64 (in case your display is 60 Hz) will give good results - at least with my graphics card it did (nVidia GTX Ti 560 448 Cores, self-overclocked). ATI should have similar Max pre-rendered frames setting called Flip Queue (or something like that) and it should be set to value 0 or 1. For sure ATI users have better knowledge of this so feel free to comment. Don't know if ATI has Adaptive vsync but regular vsync should work almost as good as long as framerate doesn't drop below monitor refresh rate (in my case 60 Hz or FPS). Auto detail framerate setting is located at rF2's player.plr file. It can be changed in-game too but then maximum value is currently 60 FPS.


    Test 2:

    Comparing 60 Hz to 144 Hz by plain input lag value is problematic. Also comparing non-synced and synced results by input lag value at 144 Hz is difficult. I think by using averaged values results represent the reality bit better but it still doesn't tell the whole truth how things are experienced by human eyes/brain.

    If we compare synced and non-synced input lags with 60 Hz monitor (test cases #17 and #18) then we see there's significant 14 ms increase in input lag when adaptive vsync is used. Also if compared to test case #16 which is basically the lowest lag possible with that Asus 60 Hz monitor we see over 30 ms increase in input lag when adaptive vsync is on which is definately affecting negatively to one's driving. So with 60 Hz monitors, at least with that specific Asus VE278Q monitor, using vsync isn't very good thing if one is trying to be fast and consistent.

    However things aren't like that with 144 Hz monitor. First of all framerate is so unbelievable silky smooth that even just a little screen tearing is very much visible. Maybe it's not that visible as a pure tearing line but it's kind of ruining the overall smoothness. Also input lag measurements and driving experience indicate that using adaptive vsync with 144 Hz monitor isn't a problem anymore. Actually I feel very much opposite because without vsync the playback isn't nearly as smooth and therefore is affecting one's driving negatively (fluctuation with adaptive vsync is really low; only 6 ms compared to non-synced 11 ms). Also measurements show that using adaptive vsync combined with max pre-rendered frames = 1 increases input lag by only 5,5 ms so it's very little and nothing like those 14 and 30 ms increases in 60 Hz monitors. So my humble opinion is to actually use adaptive vsync with those high refresh rate monitors. Haven't tested 120 Hz monitors but could imagine it would be the same case with those too.

    144 Hz monitor with adaptive vsync and max pre-rendered frames = 1 is absolutely stunning! Very low input lag combined with unimaginable smooth playback. Of course graphics settings must be lowered so that 144 FPS is achieved but at least for me it's now obvious which one I prefer over other. However with 3-display systems and very high screen resolution the needed high framerate of 144 FPS could be very hard to reach unless there's some extremely powerful hardware or rF2 gets seriously optimized in the future (or is it even possible because of limited bandwidth of signal cable).


    Test 3:

    Third test was to measure input lags at different refresh rates on same monitor (Asus VG278HE 144 Hz). Test case #21 (@ 60 Hz) is basically equal to test case #18. Older 60 Hz monitor has 10 ms lower average lag at similar conditions so probably newer 144 Hz monitor is doing some extra processing at 60 Hz on top of using overdrive technology.

    Test case #22 was made at 120 Hz and test case #23 at 144 Hz (#23 and earlier #20 are basically similar). PRAD's test stated that this monitor does not use overdrive at higher refresh rates like 120 and 144 Hz. There's huge 30 ms drop in lag from 60 to 120 Hz so it seems to be the case. Difference between 120 and 144 Hz was only 6,6 ms. Based on driving tests (C6.R GT2 at LRP) I cannot see difference in smoothness between those two but at 120 Hz there seems to be tiny bit lag when comparing real and virtual steering wheel movements. I had also more confidence at 144 Hz but difference is so small that it could be placebo effect. I'll try to do some blind tests between 120 and 144 Hz to find out if there's a real difference or not.

    Test case #24 was to test if anti-aliasing is causing lag. Conclusion is that if framerate will stay above monitor refresh rate then anti-aliasing is not causing any lag.

    After driving at 144 Hz for some time now there's definately no going back to 60 Hz. Now 60 Hz looks awful - it's like when you're very tired and starting too see everything blurry (almost like double vision). Or those situations when you've had few beers too many. A week ago before my new monitor the old 60 Hz was just fine and with vsync it was perfect and smooth. O tempora, o mores.


    Test 4:

    Surprisingly enabling LightBoost technology gave lowest input lag (32,4 ms) of all cases which were tested with adaptive sync and max pre-rendered frames 1. Also fluctuation was extremely low (2 ms) which I can't explain (perhaps monitor just happened to be in almost perfect sync with game engine during the short measurement). Probably this Asus VG278HE monitor doesn't use any signal processing when LightBoost is in use which would explain the reduced input lag because in theory LightBoost should increase the input lag by few milliseconds at 120 Hz - not reduce it. There's small pale ghosting visible on this particular monitor (probably crosstalking) when darker objects are moving on lighter background but at least in simracing I believe it shouldn't be such a problem. Definately not bothering me too much. Motion clarity is somewhat better with LightBoost at 120 Hz than without it at 144 Hz. However 144 Hz with Trace Free technology looks little bit better because there's basically no ghosting. I guess to each his/her own and it also depends of the monitor. In simracing horizontal panning is rather slow so motion blur shouldn't have so big influence as it probably does on fast first-person shooters, etc.

    So what's my choice then? I have to say it's clearly LightBoost at 120 Hz with adaptive sync on and max pre-rendered frames set to 1. Total input lag is basically lowest possible with this particular monitor so I feel very directly connected to the car. Motion clarity is flawless and playback utterly smooth. LightBoost achieves all that with 120 frames per second from game engine so I'm now able to turn some very nice graphical settings back on (HDR and medium shadows being most important). Only downside is little ghosting probably due to crosstalking caused by 2 ms pixel response time but luckily it's quite negligible during hard racing - at least to me personally. Big thanks to Spinelli for informing us about this new wonderful technology!





    If you have any questions about the test or results please feel free to ask.

    Test rig:
    Input lag testing.jpg
    Last edited by KeiKei; 02-21-13 at 01:24 PM. Reason: Additional tests for 144 Hz monitor

  2. #2
    Golanv's Avatar

     rFactor 2 Validated PC Specification 

    Registered
    Nov 2012
    Location
    Finland
    Excellent work as always. I still havent tried that 179 fps, but its deffinetly on my to do list. Am I gonna be using that as default, I doubt it, because I have a sweet tooth, but I wanna experience the difference myself.
    As soon as ISI optimizes the engine, would be nice to see these results again. Maybe we could get some more fps with candy.

  3. #3
    DrR1pper's Avatar

     rFactor 2 Validated PC Specification 

    Registered
    Apr 2012
    Location
    UK
    wow. Nice one KeiKei.............again.
    "The most incomprehensible thing about the universe is that it is comprehensible" ~ "Practice does not make perfect....perfect practice makes perfect."

  4. #4
    dsuspense's Avatar

     rFactor 2 Validated 

    Registered
    Jan 2013
    Location
    Orlando, FL
    Great stuff!
    One thing I have noticed, rF2 seems to suffer less from vSync input lag than rF1.
    rF1 is basically undriveable with vSync on, but with rF2, it is still responsive, but not as instantaneous as when vSync is off.

  5. #5
    vittorio's Avatar

     PC Specification Where I race 

    Registered
    Jan 2012
    Excellent idea KeiKei! I wanted to measure input lag yesterday and examined all my cameras. All had only 15-30 fps. I totally forgot about my PS3 Eye! Measure the input lag is the way to go.

  6. #6
    Mrslfrsl's Avatar

     rFactor 2 Validated PC Specification LiveRacers Driver Page 

    Registered
    Jul 2012
    Location
    Austria
    @Keikei

    dude, thx for all your testing and writing. yourse stuff was really usefull to mese.

  7. #7
    KeiKei's Avatar

     rFactor 2 Validated PC Specification 

    Registered
    May 2012
    Location
    Finland
    I've wanted to do this for a long time but didn't have proper hardware until now. Pretty surprised PS3 cam turned out to be the hardware for the job! It really isn't difficult at all to measure input lag with those tools so basically everyone with PS3 Eye Cam and adequate PC is able to do it. First you'll need drivers for the camera so it works on PC:

    http://codelaboratories.com/products/eye/driver/

    Note: I had problems with video capturing if both operating system and game didn't have same refresh rate so make sure they are set to same value (for example both 60 Hz).

    Video capturing is done with software CL-Eye Test which is included in the drivers above. From Options menu click Video Capture Pin and change resolution and framerate to 320 x 240 px (24 or 32 bits) @ 187.003 FPS. Then from Capture menu click Set Frame Rate..., tick Use Frame Rate and type 187. From File menu set location for captured file. I stored video files to SSD drive. It's good idea to brighten up your room so that captured video is as clear as possible.

    Launch game, go to track and lower virtual seat position so that upper part of the steering wheel is middle of the screen vertically. Alt+Tab to CL-Eye Test, click Start Capture, Alt+Tab back to game, rotate steering wheel back and forth like a madman for a while, Alt+Tab back to CL-Eye and stop capturing.

    Next thing is to open captured video file with some video playback software able to do frame by frame. I used free software called Avidemux 2.6 which can be downloaded from:

    http://fixounet.free.fr/avidemux/download.html

    It showed captured video upside down but it didn't matter. Play the video to a point where wheel is starting to move fast. Then you can advance one frame at a time with arrow right/left keys. Try to find a point you can use to measure delay between real and virtual wheel. Personally used a point where wheel just starts it's movement back from farthest rotation. Write down time of that point (located at lower left corner near Time button) and then advance frame by frame to a point where virtual wheel is at the same point/phase. Then just subtract the first time from the second and you have input lag in seconds for example 0.064 seconds = 64 milliseconds.

    Avidemux.png
    Last edited by KeiKei; 02-11-13 at 06:13 PM.

  8. #8
    Barf Factor's Avatar

     rFactor 2 Not Validated PC Specification 

    Registered
    Nov 2012
    Location
    Sydney, Australia
    Very interesting, thanks for sharing this!

  9. #9
    Steve Watts's Avatar

     rFactor 2 Validated 

    Newer Member
    Feb 2012
    Nice thanks for sharing

  10. #10
    Gearjammer's Avatar

     rFactor 2 Validated PC Specification @@keirgarth 

    Registered
    Jun 2012
    Location
    FL.
    Thanks for all that work Keikei, I do have a question though. For each of the sync options you show 2 rows. Why? I noticed that with the first sync option you showed the internal capable of rendering 200 then down to ~65. Are you somehow altering the values for that?
    I don't know what I don't know, but I know EVERYTHING else!
    PC System Designer|Student of Graphic Design

  11. #11
    KeiKei's Avatar

     rFactor 2 Validated PC Specification 

    Registered
    May 2012
    Location
    Finland
    Yep those rows with (200) and also first Sync GPU 201 FPS are with low graphic settings / level of details. Game/graphics engine is able to produce around 200 frames per second. Some sync settings allow all those frames to be send to display while others limit the framerate but those additional frames are still created inside the game/graphics engine.

    Rows with (~65) and second Sync GPU 61 FPS are with high graphic settings / level of details. Game/graphics engine is able to produce just over 60 frames per second.

    The reason why I choosed those limits was because I was suspecting those "hidden" extra frames would reduce input lag by a little. And if you compare (200) to (~65) there's definately more input lag in every case-pair except on video and adaptive vsync. So lowering graphic settings / level of details (higher inner framerate) will generally lower input lag except on those two. In cases #3-4, #5-6 and #7-8 input lag is around 20 ms higher when higher graphic settings / level of details are used.

    Like in real-life candy doesn't come without a cost.

  12. #12
    scepak's Avatar
     

    Newer Member
    Jan 2012
    Location
    London
    Thanks for all the effort you put in testing the lag man! It really does make a difference. I was thinking about getting 120Hz screen when I upgrade my PC, what's your opinion on that?

    And sorry for off topic, but did you manage to get this PS3 EYE camera working with head tracking? Did you try face track no ir for it?

  13. #13
    KeiKei's Avatar

     rFactor 2 Validated PC Specification 

    Registered
    May 2012
    Location
    Finland
    I believe 120 Hz display will reduce input lag considerably even when vsync is used. Don't know how smooth it is when framerate is limited for example to 180 FPS and display refresh rate is 120 Hz. I would imagine it to be extremely smooth but haven't had opportunity to test it.

    Did manage to make PS3 Eye Cam work on head tracking but there's some lag in it and also it isn't completely natural because your screen is fixed and doesn't move along with your head. I think forthcoming Oculus Rift will change all of that. Currently I'm dreaming about Oculus Rift but 120 Hz conventional display shouldn't be bad either. I'd wait for customer version of Oculus and then decide whether it's Oculus or 120 Hz conventional display.

  14. #14
    Gearjammer's Avatar

     rFactor 2 Validated PC Specification @@keirgarth 

    Registered
    Jun 2012
    Location
    FL.
    KeiKei, with head tracking if you have triple monitors things are more realistic. You still won't have to turn your head all the way around, but there are adjustments in the software to make it very realistic for tracking and you don't run out of screen as fast
    I don't know what I don't know, but I know EVERYTHING else!
    PC System Designer|Student of Graphic Design

  15. #15
    KeiKei's Avatar

     rFactor 2 Validated PC Specification 

    Registered
    May 2012
    Location
    Finland
    Well yes but triple 27" 120 Hz monitors cost a fortune, needs lots of space and also require supercomputer to reach 120 frames per second! Well if I had the money...

  16. #16
    Spinelli's Avatar

     rFactor 2 Not Validated PC Specification 

    Registered
    Jan 2012
    Location
    Cosmos
    120hz doesnt actually mean you get less input lag. Its definetely more fluid and beautiful, but doesnt affect input lag. Just look on many monitor review sites that do input lag tests. Most of the least input lag monitors are 60hz still, especially the cheap TN panel ones, but there are some low 120hz ones as well. You probably dont want anymore than 8 ms input lag. The samsung PX2370 is one of the lowest I have ever seen at a measured average of 3.3 ms input lag. There are some good Asus ones that I think are in the 5 to 7 ms range. Basically about 16 ms is 1 entire frame when you are running 60fps, and 8 ms is 1 frame when you are running 120 fps, that doesnt really matter either though. Just try to find one no higher than maybe 8ish ms and I am sure you will feel no input lag .

    Other input lag from your controller, your graphics settings, vsync, etc those could all have their own input lag, but in regards to the monitor itself anything under 8ish should be fine.

    I used to play on a beautiful IPS panel, but I could feel the input lag, I couldnt really see it much but I could feel it. I was comming from a CRT display which have ZERO input lag, so this was a BIG difference to me. Felt really bad. I was looking online for widescreen CRTs, I said I will just go CRT until OLED comes out (I heard they will have no input lag), but then I couldnt wait anymore, but I couldnt race competitively like this either, it was a complete joke. Luckily I researched, found out all about input lag (most companies dont give out input lag #s), got a Samsung PX2370 and the difference with that and my first LCD was HUGE. I felt in direct control again, similiar, if not the same as when I had my CRT. The image isnt as beautiful as the IPS panel monitr, but do you think I care about image when I got this monitor to race? Of course not!
    Last edited by Spinelli; 01-23-13 at 12:59 AM.

  17. #17
    KeiKei's Avatar

     rFactor 2 Validated PC Specification 

    Registered
    May 2012
    Location
    Finland
    Thanks for bringing monitors' input lag to the table! It really is very important part of this puzzle. I'm aware of it but for this thread only concentrated on input lag differences between different sync options and how graphics engine's capability of producing more frames than what monitor is able to show has it's impact on input lag too. As you said there are other input lags too for example from steering wheel to physics engine, physics engine to graphics engine, graphics engine to graphics card, graphics card to monitor, etc. Nice thing about measuring input lag with high-speed camera is that it's the total input lag from real steering wheel to driver's eyes and hence the only thing that really matters.

    As you said in the other thread...

    Quote Originally Posted by Spinelli View Post
    Get the least input lag monitor you can find, trust me, it can get pretty bad man. Well not as bad as actual televisions LOL, (30-80 ms input lag hahahaha)
    ...those extremely slow displays like televisions etc. are real bad for simracing. Comparing good computer monitor of 5-8 ms input lag to 30-80 ms... well that's small eternity really!

    If you could point out good reviews about 60 vs 120 Hz monitors with input lag measurements I'd be very thankful and able to check how those measurements were done. I've still this strong intuition that 120 Hz will make a difference to a total input lag compared to 60 Hz when vsync is in use. I believe by doubling the monitor refresh rate will cut vsync processing time to half and hence would lower the total input lag regardless if both 120 and 60 Hz displays had same input lag. But I don't have any proof of it so someone please send me 500 euros or 120 Hz monitor with same input lag as my current 60 Hz one and we'll find out the truth.
    Last edited by KeiKei; 01-23-13 at 10:11 AM.

  18. #18
    KeiKei's Avatar

     rFactor 2 Validated PC Specification 

    Registered
    May 2012
    Location
    Finland
    Quote Originally Posted by KeiKei View Post
    my display (Asus VE278Q @ 60 Hz)
    Found few articles which had measured input lags for this monitor and here's one:

    http://www.digitalversus.com/lcd-mon...0118/test.html

    Average responsiveness (input lag of the monitor) was 7 ms so shouldn't be a problem. Article also said:

    Although it's billed as a 2 ms monitor, meaning it should be suited for gamers, the VE278Q's default configuration didn't convince us of this. You can, however, improve things by using the onscreen menu to adjust the 'Trace Free' option from 0 to 40. Be careful not to go any further, otherwise you might end up with reverse ghosting.
    Lowered the default 60 to 40. Maybe there's some difference but couldn't tell by naked eye and probably immeasurable with 187 FPS camera.

  19. #19
    KeiKei's Avatar

     rFactor 2 Validated PC Specification 

    Registered
    May 2012
    Location
    Finland
    Hmm taking some of my words back. Monitor responsiveness and input lag may not be the exact same thing. Article says about responsiveness graph:

    This graph shows the ghosting time, measured in ms, that the monitor takes to entirely remove the previous frame.
    Input lag may be how long it takes from monitor to process the received image so that it gets shown on screen. Based on this video the input lag with this monitor seems very low though:

    http://www.youtube.com/watch?v=cJ2ybrdffkQ

    Sometimes it's at the same phase with lagless monitor and sometimes one frame behind so probably input lag is well under 10 ms.

  20. #20
    Spinelli's Avatar

     rFactor 2 Not Validated PC Specification 

    Registered
    Jan 2012
    Location
    Cosmos

    Input lag measurements

    Response time has nothing to do with input lag, 2 completely different things
    GFX settings to make ISI / RFactor engine based games BEAUTIFUL --> AMD - NVIDIA

Page 1 of 10 12345 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •