Thanks alot Niels very interesting.

So what is the conclusion of all of this - how can one decrease the lag between steering wheel and ingame wheel, what are the important settings to keep the lag as low as possible?

Quote from Niels Heusinkveld :

Thankfully the 'techy' threads on the LFS forum about physics etc are proof that there is a lot of sanity as well but sometimes when I'm looking at overclock / pc hardware forums I don't know if I should laugh or cry..

The best I've ever seen was a guy who got a new screen, said the colours were too dark in some areas of the screen and then posted a screenshot to show what he meant.

Interesting thread BTW, including the Xbit article.

I definately noticed, before seeing this data, that rfactor and RBR quickly become undriveable at low frame rates but I had never thought about it in terms of input lag but more in terms of a low physics frame rate. In LFS you can drive just as fast at 25 fps as you can at 60 fps once you get used to it. I think that this difference in the way physics/input/graphics loops relate to each other might be the reason why the shape of the graphs in the second table can clearly be divided into two groups: LFS/NASCAR and NKP/RBR/rFactor.

Oh, and why didn't you include DR? Seems unlikely you would have forgotten it.

I almost lost a partition a while ago. DR was lost and I haven't searched / tried to download it yet.. It was interesting as I talked about lag with Eero; I was lucky to be driving it before it went 'public', and he adressed the lag. Curious to see if 'render ahead' settings still affect DR..

I have no time soon to redo all the tests I'm afraid, some 'real life stuff' needs to be prioritized..

Georg, I have to redo the tests with a different setting. As the graphs show, using VSYNC often gives slightly slower response compared to running at high framerates.

It seems that if you use a program like Rivatuner, setting the 'max render ahead' frames to 0, you'll get the best performance, but I only tried that with rFactor. I'm quite sure this will affect RBR and NKpro but not sure how much LFS, N2003 and GPL will be affected.

Thats good to hear. The difference between the Wheel and the Ingame Wheel is very important. The Physics in a Sim can be as good as they want but only to a certain point when the input is lagging.
Most of the lag will be from the Hardware, wonder if the Wheel producers have improved there Hard and Software to keep the lag as low as possible.

Woah you dug this old thread up Leo! Thanks for the insight.. Not all games 'poll' the controller at the framerate per se.

What does help a lot is that 'render ahead' tweak (set to zero) in various ATI or Nvidia 'tray tools' type things. Roughly made the rFactor lag go from ~0.25 to ~0.125s, including all measurment lags. There is a distinct difference from sim to sim though.

Input lag should be a priority, at 0.25 seconds, although an extreme example (some games at ~30fps) you simply are not driving the car.. It is more like telling someone what you want them to do with the controls..

Hmm, I'm curious. Is the USB report queue also an issue when using DirectInput?

DirectInput allows an application to specify the polling rate for a device and also supplies device state data in either buffered or immediate mode. In immediate mode, the device state at the time the device is polled is returned and other device events are discarded. In buffered mode, device states are stored in a buffer until the application retrieves them.

Is the USB report queue overlaid on top of this? i.e. when a device is polled in immediate mode, is the first entry in the report queue returned or is the actual device state at the time the device is polled returned?

Quote from lbodnar :

I don't know how game designers handle this but I know that default buffer length is 8 reports in W2000 and 32 reports in XP. [snip] kept this [email protected] for the spambots :haha:

Would this explain how I felt the LFS force feedback very much differet in Windows Me and Windows XP (SP1)?

And those 'USB "overclock" utilities' that are out? I think they change a windows DLL or SYS file, you can set USB polling to 125 (std), up to 1000hz.. Would that be an improvement or does it increase the buffer length..

url for util: http://www.softpedia.com/get/T ... -Mouserate-switcher.shtml

Quote from Niels Heusinkveld :

And those 'USB "overclock" utilities' that are out? I think they change a windows DLL or SYS file, you can set USB polling to 125 (std), up to 1000hz.. Would that be an improvement or does it increase the buffer length..

url for util: http://www.softpedia.com/get/T ... -Mouserate-switcher.shtml

From what I've read after googleing that program, not all USB periphrials support that high of a frequency.

I tried it ages ago and my keyboard/mouse/Plasma Lite game controller didn't mind it.. It would not so much help input lag but perhaps it might help FF 'speed'.. Not that I use that..

good idea measuring this stuff.

but to be pedantic, it's latency, not lag. lag is variable (you can catch up again after falling off the pace). latency is fixed (pace is matched, but delayed by a fixed amount).