The Tech Report has been trying to do some awesome things in the way of benchmarking video cards. To put it in very laymens terms, that FPS averages simply don't give the full picture of frame fluidity and to get a true sense you have to go inside the second.

To that end they have requested the following:

Quote from The Tech Report :

It would be very helpful to have an API from the major GPU makers that exposes the true timing of the frame-buffer flips that happen at the display. I don't think we have anything like that now, or at least nothing that yields results as accurate as those produced by FCAT. With such an API, we could collect end-of-pipeline data much easier and use frame captures sparingly, for sanity checks and deeper analysis of images. Second, in a perfect world, game developers would expose an API that reveals the internal simulation timing of the game engine for each frame of animation. That would allow us to do away with grabbing the Present() time via Fraps and end any debate about the accuracy of those numbers. We'd then have the data we need to correlate with precision the beginning and ending of the pipeline and to analyze smoothness—or, well, for someone who's smarter than us about the tricky math of a rate-match problem and the perceptual thresholds for smooth animation to do so.

I think it would be awesome for LFS to provide that second part for them. They even had something interesting to say about frame timing effecting engine timing.

Quote from The Tech Report :

However—and this is a huge caveat—we have some trepidation about declaring even this one particular example a definitive triumph for Fraps-based measurements. You see, like most folks who test gaming performance, we've removed the built-in frame rate cap in Skyrim. We already know that doing so causes some funky timing quirks for things like the game's AI, but it may also modify the game's fundamental timekeeping method for all of its physical simulation work. (The variable we've modified in order to "uncap" Skyrim is called "iPresentInterval", and we've changed it from "1" to "0." You may recall that Fraps measures when the game calls Present(). Hmm.) If our uncapping effort has changed the way time is kept in the game, it may have created the possibility of frame-to-frame timing issues that one would usually not see with the game engine's default timing method. This thought occurred to me on an airplane, on the way out to GDC, so I haven't been able to dig deeper into this issue yet. I definitely think it merits further investigation, and the frame-by-frame playback and analysis possible with the FCAT tool set should be a big help when the time comes.

I find to be extremely insightful to the way the Skyrim engine works and I wonder what effects the LFS engine would have it if could not run at the stated 2kHz.

You can find the article I'm referring to and quoted from here.

http://techreport.com/review/2 ... vidia-frame-capture-tools


You should also catch up on their original article here.

http://techreport.com/review/2 ... look-at-game-benchmarking

Fraps-based stuff does seem to be.. ambiguous. I've been recording frame latencies for AC for a while now. Shame that the ini files have some value for the physics rate, but changing it doesn't do anything

http://i.imgur.com/fZUdRny.jpg (2 laps around Magione).