If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

We can ofcourse discuss the settings, and try to achieve the lowest jitter.

First of all, a kernel with "low latency desktop" enabled. You can edit Kconfig.hz and change 100 to 90. (search/replace).
You can add idle=poll and tick_skew=1 to boot options. And compile a shaved local kernel by doing "make localmodconfig" from a full distro kernel. (Also remember to turn of high_res_timers if enabled, because then hz will be 4016 or atleast high.)

CFS granularity should be set to 1158500nS. (Current setting is a bit high, and may give jitter)
Renice X to -20, to prevent X being a bottleneck.
Remove 60hz limit in doom 3, to avoid timing jitter. http://paradoxuncreated.com/tmp/AutoExec.cfg

A lot of people think SLAB has lower jitter than SLUB etc, aswell, and some tuning with regards to what kernel options execute the least code, least background activity can be done.

Rather than listen to someone moan and not want to realize reality, I`d much more like to see people understanding this, and contributing to an improvement. And I very much appreciate the initiative of the thread. However to really see doom 3 jitter, it must be run at normal speed. So just play through a level. and record those values instead, would be more informative.

Less interrupt triggered = less interruptions = less jitter. Depending on how things is done, if less interrupts means larger data bursts, there may be a sweet spot. I have found 90 hz, to give the least jitter, with 5hz accuracy.

Less interrupt triggered = less interruptions = less jitter. Depending on how things is done, if less interrupts means larger data bursts, there may be a sweet spot. I have found 90 hz, to give the least jitter, with 5hz accuracy.

Also, if Phoronix Test Suite adds frame time graphs, it would be helpful to show the X axis as time for demos that run at a constant speed (i.e. not like Quake 3 timedemos). That way it's easier to tell if a long frame always happens in the same place in a demo.

Also, if Phoronix Test Suite adds frame time graphs, it would be helpful to show the X axis as time for demos that run at a constant speed (i.e. not like Quake 3 timedemos). That way it's easier to tell if a long frame always happens in the same place in a demo.

Also, if Phoronix Test Suite adds frame time graphs, it would be helpful to show the X axis as time for demos that run at a constant speed (i.e. not like Quake 3 timedemos). That way it's easier to tell if a long frame always happens in the same place in a demo.

What would then be measured in the y-range?

I believe that Doom 3 timedemos are frame-for-frame identical across machines, because delays happen always in the same frame. Moreover, timedemos always have the same frame lenght.