Benchmarking The Ubuntu "Low-Jitter" Linux Kernel

[Sidicas]

And while many also make completely absurd statements and attack what I am doing, I am very happily running what feels like a high performance computer.

The "feels like" is important. It feels like it is high performance because it is more responsive. But the actual amount of computation being done is slightly less so it's technically lower performance.. Think of it this way. Say you've got a display at 60Hz refresh rate. The linux kernel is optimized for performance. That means that when given the choice, when there is a lot of other threads running, the kernel will prefer to render 0 frames for the first half of the second and 30 frames for the second half of the second.. Rather than 29 frames at regular intervals throughout the whole second. Since the render thread is so low CPU usage, if the kernel doesn't come back to it quickly it can cause these responsiveness problems. Same thing is true in Windows, just try playing a game with an anti-virus program in the background, non time sensitive threads seriously gets in the way of threads that are very time-sensitive, often without causing significant drops in FPS. 29FPS vs. 30FPS.

So then it is up to those who have a mind, or simply think this is a good thing to follow. Ultimately it trickles down to the masses aswell I guess. But now you have a chance to trim 10 years on that

Peace Be With You.

I agree with you that real-time kernels are pretty much the mecca for gamers. It is absolutely critical that rendering threads get a tiny slices of CPU time at the exact right times rather than getting offered a big slice of CPU time at the wrong time and no CPU time when it needs it most. You can kind-of avoid the need for real-time kernels by just buying complete overkill hardware as most Windows gamers do, but I don't think this scales well into the future.. Linux desktops these days run a full SQL server, or even 2 as is the case with KDE. On the Windows side there are virus checkers on every PC. Sure, most gamers disable virus checkers as a no-brainer, but it really doesn't have to be this way with a real-time kernel that understands exactly which threads are absolutely time critical for user responsiveness and which threads can sleep for a solid second without the user even "feeling it".

You can boost/lower priority of apps all you want, but in a heavily loaded system running a regular kernel that doesn't actually guarantee anything in terms of responsiveness .. The only thing that can guarantees responsiveness, assuming you have sufficient hardware for the task, is a real-time kernel.

[liam]

Oh God, another thoughput guy. How many times do I have to say this. Framejitter, reduces performance. A high end machine with jitter, acts similarly to a low-end machine.

If jitter reduces ACTUAL frames outputted to screen to 30fps, what are you talking about throughput for?
Don`t confuse SERVER throughput, that needs no graphical environment, to GRAPHICS throughput.

And because of performance, I have said I only look to 0.2ms max latency/jitter. Currently I use the "low latency" desktop, in the rt-patch still, but I may increase the preemption level. Not without reasons, not "loosing performance". Only if it becomes better. No senselessness, only optimality. Don`t worry, and stop the silly "throughput" arguments.

Peace Be With You.

I'm sorry if that bothers you but it is the truth. Go onto the RT kernel mailing list and ask them if, in general, RT increases throughput. The fact that it doesn't, as I said, isn't that important. The "standard" kernel has been designed to maximize throughput to the detriment of responsiveness, hence why it suited to server loads. Attempts have been made to make it better for the desktop. Probably most notably with the various Completely Fair Schedulers.
Throughput, regardless of the context, means work done per unit time. The fact seems to be that the more real time you get the less throughput you can expect. In the case of graphics things are a bit different since we have a coprocessor capable of handling work on its own for brief periods of time (I'm sure someone could give you a more precise number here but it would have to be somewhere beneath 16ms at best). However, since we are talking about changes in frame delivery time we need to include the cpu in the discussion thus how fast it can handle interrupts becomes important. If you want it to reliably handle interrupts (say, from the GPU) as soon as possible you need to go RT. Now, where RT slows us down is when the GPU needs the CPU to handle something (I don't know, create a texture or something) but that work keeps getting interrupted b/c by going RT you've made many signals interruptible (such as syscalls). So, it takes the CPU longer to do the work the GPU is waiting for and thus RT slows things down (again, linux has mostly been concerned with getting work done quickly even if not reliably quickly). Now, the upside, as we both agree, is that you get reliably quick responses and framerates should be a bit more consistent (assuming that the work needed to be done by the cpu is relatively consistent between frames which I realise is a bad assumption).
Anyway, having jitter doesn't mean you end up with less fps over long periods of time it simply means you are more likely to experience a larger degree of variance with frame creation and delivery. So, an RT kernel may give you, reliably, 45fps and rarely go above, while the standard kernel gives you 60 fps but with much larger variance.
BTW, I'm not sure how you came up with this 200us number.

[Paradox Uncreated]

Sidicas is on the right track. Later poster is completely wrong.

Indeed it should be easy to understand, that if kernel blocks for 5ms, rather than 0.2ms, timing jitter is going to be present, and alter framejitter, and also 5ms lost of 20ms, to calculate frame.

Peace Be With You.

[Paradox Uncreated]

So I have tuned my local kernel to max, which gives very few clicks at 0.3ms. So I am quite close to where I want to be. I am actually buying a new computer, tuned for low latency, so I will let you know how it goes.

http://paradoxuncreated.com/Blog/wordpress/?p=4045

Peace Be With you.

[gamerk2]

The "feels like" is important. It feels like it is high performance because it is more responsive. But the actual amount of computation being done is slightly less so it's technically lower performance.. Think of it this way. Say you've got a display at 60Hz refresh rate. The linux kernel is optimized for performance. That means that when given the choice, when there is a lot of other threads running, the kernel will prefer to render 0 frames for the first half of the second and 30 frames for the second half of the second.. Rather than 29 frames at regular intervals throughout the whole second. Since the render thread is so low CPU usage, if the kernel doesn't come back to it quickly it can cause these responsiveness problems. Same thing is true in Windows, just try playing a game with an anti-virus program in the background, non time sensitive threads seriously gets in the way of threads that are very time-sensitive, often without causing significant drops in FPS. 29FPS vs. 30FPS.

More or less on the mark, and a point I've been trying to make for over a decade now.

FPS is simply a measure of how many frames are created per second. This has no bearing on how many frames are actually displayed on the screen.

Assuming a 60Hz moniter, one frame will be drawn every 16.67ms. To display 60 different frames over that period requires that one frame be created every 16.67ms.

More often then not, you get periods where you miss that interval, leading to the previous frame being displayed a second time. Worst case, during the following interval, two frames are created, and the first will be dropped. So your frame output looks something like this:

1) Frame #1
2) Frame #1
3) Frame #3 (frame 2 was created, but frame 3 was also created before the screen was ready for a new image, and is thus dropped)

Then people wonder why they get 60FPS when running a SLI config, but the game is laggy. THAT is a latency problem, and something that needs a much more serious look in the future. (Techreport did a VERY good analysis on this not too long ago, fyi)

Now lets look at an OS perspective. Lets assume for a second only a single thread is responsible for doing the rendering (to keep this discussion simple). To create the frame in question, the rendering thread must be undergoing work by the CPU. This relies on the scheduler to ensure that this particular thread be running long enough to finish its job. If you have a scheduler, however, that attempts to reduce overall system latency, what will happen is backgound threads (especially kernel and UI threads) will do a lot of pre-empting, possibly forcing your rendering thread out, in order to reduce SYSTEM latency. As a result, your application takes longer then 16.67 seconds to create the thread, and you skip a frame.

The general rule is that by reducing latency, you typically reduce application throughput as a result. The ONE exception is the case of a system-wide performance bottleneck (which would imply either a REALLY bad scheduler, or a problem within the kernel resulting in ZERO work being done for some period of time, which is very unlikely.)

I agree with you that real-time kernels are pretty much the mecca for gamers. It is absolutely critical that rendering threads get a tiny slices of CPU time at the exact right times rather than getting offered a big slice of CPU time at the wrong time and no CPU time when it needs it most. You can kind-of avoid the need for real-time kernels by just buying complete overkill hardware as most Windows gamers do, but I don't think this scales well into the future.. Linux desktops these days run a full SQL server, or even 2 as is the case with KDE. On the Windows side there are virus checkers on every PC. Sure, most gamers disable virus checkers as a no-brainer, but it really doesn't have to be this way with a real-time kernel that understands exactly which threads are absolutely time critical for user responsiveness and which threads can sleep for a solid second without the user even "feeling it".

You can boost/lower priority of apps all you want, but in a heavily loaded system running a regular kernel that doesn't actually guarantee anything in terms of responsiveness .. The only thing that can guarantees responsiveness, assuming you have sufficient hardware for the task, is a real-time kernel.

Understand, that in a RTOS, the most important variable is TIME, not latency, not performance. TIME. Every task must complete within "X". Which sounds good in theory, until you get into dynamic lighting or some other computation that requires a significant amount of time to finish. Too bad though, your thread is getting moved out so the rest of the system stays responsive. RTOS's make guarantees on TIME, not performance.

Windows, Linux, Unix, BSD, OSX and the like are all general purpose OS's. They make NO attempt whatsoever to act like RTOS's.

[Paradox Uncreated]

Why is gamer2k posting in this thread? To be an example of how much babble can be done, that is not according to simple observation? "It spends time calculating preemption". LOL. The benchmarking even shows some higher numbers, and no other are below 1fps difference. What you do OBSERVE though, is a game that was choppy (low GRAPHICS throughput) to one that runs smoothly at 72fps. HIGHER throughput, when using preemption with graphics. Again, we do not care about theoretical numbers, that say nothing about what is ACTUALLY happening on screen, relating to USER experience. I really hate people who are that far removed from reality.

Peace Be With You.

[Paradox Uncreated]

Here people are even complaining about SMI http://smackerelofopinion.blogspot.n...e-is-evil.html

Don`t tell gamer2k, like services in windows, they should be on, for more lamerput.

Peace Be With You.

[Paradox Uncreated]

I mean this is probably just cool. When he sees those jitters, he bangs his fist in the table, and thinks goddamn, that effect was cool.

[Sidicas]

More often then not, you get periods where you miss that interval, leading to the previous frame being displayed a second time. Worst case, during the following interval, two frames are created, and the first will be dropped. So your frame output looks something like this:

1) Frame #1
2) Frame #1
3) Frame #3 (frame 2 was created, but frame 3 was also created before the screen was ready for a new image, and is thus dropped)

Then people wonder why they get 60FPS when running a SLI config, but the game is laggy. THAT is a latency problem, and something that needs a much more serious look in the future. (Techreport did a VERY good analysis on this not too long ago, fyi)

It's actually worse than that.
The proprietary drivers for both AMD and nVidia will not drop frame #2 by default since it would hurt the "smoothness" of the game.

Rather they will give that to the display instead of frame #3 even though frame#3 is ready.
Frame #3 goes into a waiting area called the triple buffer where it will sit and wait to be displayed on the next refresh cycle. By the time the display finishes with frame #3 and gets to the next refresh cycle, it would hope that frame#4 would be ready by then or you're going to get another frame#3.

The proprietary drivers also have a little "feature" built into them that they will pre-render up to about 4 frames before letting the GPU idle.. Which means you could have up to 4 of the most recent frames sitting in your triple buffer waiting for the screen to refresh and each refresh the user is getting the oldest frame presented to them.. The reason for this is that the drivers expect the game to suddenly stop feeding the graphics card frames. Due to the OS wandering off and doing other things or whatever, I kind of like to think of it as MS Windows having ADD. That way the graphics card has a nice cache of frames that it can present to the user even when it suddenly stops getting frames to process for a prolonged period. Just so it has something to show to the user rather than the same frame. Of course, this does horrible horrible things to the responsiveness of the game, but both AMD and nVidia like to enable it by default because it adds "smoothness" to the video (having lower amounts of difference between frames). It's just another example on the pile of how responsiveness in games isn't being respected as it should be.

Both pre-rendered frames and triple-buffer can typically be disabled in Catalyst control center / nvidia control center. It will help responsiveness, but the game will not be as pretty or fluid.

[Paradox Uncreated]

Yeah max 2 frames render ahead.

edit xorg.conf (gksu gedit /etc/X11/xorg.conf), and add under Section “Device”

Option “RegistryDwords” “OGL_MaxFramesAllowed=0×2; PowerMizerEnable=0×0; PerfLevelSrc=0×2222;”

Only the maxframes if you want powermizerstuff.

Peace Be With You.