The First NVIDIA GeForce Benchmarks On The SteamOS Beta

[kwahoo]

They probably use RT kernel because of video capturing ability. They don't want to have huge spikes when video captring is stoped. RT gives more predictable change in performance.

The Valve's use of rt kernel is great news because the developers were just looking to drop it https://lwn.net/Articles/572740/

Now valve could pick up maintaining rt branch and mainline it eventualy.

But Valve does not use rt kernel. See previous post.

[gnufreex]

They probably use RT kernel because of video capturing ability. They don't want to have huge spikes when video captring is stoped. RT gives more predictable change in performance.

The Valve's use of rt kernel is great news because the developers were just looking to drop it https://lwn.net/Articles/572740/

Now valve could pick up maintaining rt branch and mainline it eventualy.

[hjhamala]

You are assuming i am running SteamOS (with your uname -r comment). I'm not, only took a look through their source code to see if there was anything of interest....

Thanks for clarifying the debian packaging, however, the assumption that because their beta ISO is using a generic kernel, that it automatically means their product will, may or may not be a good assumption to make... For example, If you want to be a senior software engineer at Valve; you *must* have knowledge / be able to solve problems on both non-realtime PCs *and* Realtime PCs. ~ note: it doesn't say realtime SoC<like in a peripheral or something like that, they say *PC*. (and neither MacOSX nor Windows are considered "realtime operating systems on PCs". (from their job postings); http://www.valvesoftware.com/job-SenSoftEngineer.html

anyway, I'm not saying you're wrong (or that i am right), as a lot of this stuff is still up in the air, afaict. Maybe someone from Valve can clear that up.

According to real time linux how to there is way to check is the kernel real time patched:
https://rt.wiki.kernel.org/index.php...ing_the_Kernel
Well I tried to test it. The results are:

• Uname -a doesnt have RT string
• Dmesg doesnt have string "Real-Time Preemption Support (C) 2004-2006 Ingo Molnar"
• There is no kernel threads as [IRQ 7]
• Proc interrupts doesnt look like Figure 9

I think that this probably means that Valve is not using realtime patched kernel.

[ninez]

And? It's a part of the regular Debian kernel package. SteamOS does not use those patches. What is uname -r output? 3.10-3-amd64 instead 3.10-3-rt-amd64?

You are assuming i am running SteamOS (with your uname -r comment). I'm not, only took a look through their source code to see if there was anything of interest....

Thanks for clarifying the debian packaging, however, the assumption that because their beta ISO is using a generic kernel, that it automatically means their product will, may or may not be a good assumption to make... For example, If you want to be a senior software engineer at Valve; you *must* have knowledge / be able to solve problems on both non-realtime PCs *and* Realtime PCs. ~ note: it doesn't say realtime SoC<like in a peripheral or something like that, they say *PC*. (and neither MacOSX nor Windows are considered "realtime operating systems on PCs". (from their job postings); http://www.valvesoftware.com/job-SenSoftEngineer.html

anyway, I'm not saying you're wrong (or that i am right), as a lot of this stuff is still up in the air, afaict. Maybe someone from Valve can clear that up.

[kwahoo]

You should probably look a little deeper in their packages... They ship a config for both PREEMPT_RT_FULL and non_rt;

(from llinux-source-3.10_3.10.11-1+steamos5+bsos1_all.deb)

/usr/src/linux-config-3.10/config.amd64_none_amd64.xz <- Generic
/usr/src/linux-config-3.10/config.amd64_rt_amd64.xz <- PREEMPT_RT_FULL

and;

/usr/src/linux-source-3.10.tar.xz <- mainline kernel sources
/usr/src/linux-patch-3.10-rt.patch.xz <- PREEMPT_RT_FULL patch

...

IME, this is typical of any company that i have ever encountered who is using linux-rt patchset in their product... You include both, but usually in production, you are using RT with the vast majority of kernel debugging disabled, etc...

...and (again) in linux_3.10.11-1+steamos5.debian.tar.xz;

.../patches/features/all/rt (contains linux-rt 3.10 patch, but broken down to individual commits/patches. 282 patches)

And? It's a part of the regular Debian kernel package. SteamOS does not use those patches. What is uname -r output? 3.10-3-amd64 instead 3.10-3-rt-amd64?

[hjhamala]

thanks on link

PREEMPT RT enabled:
- larger average
- larger minimum
+ smaller maximum
+ more consistent

please do correct me if i'm wrong, but i can't help my self but to see nothing but positive here, determinism simply could not exist without taking some toll. but, when you look at graph minimum didn't suffer much, maximum on the other hand did. as i see it input is constant small job that must be fitted to run constantly during larger processes and rt kernel seems to serve exactly that. i personally prefer predictable consistence.. worst case for game to be unplayable is that your input stutters like it did on some ps3 games i played where bluetooth 100ms lag was already norm. but, as i already said... i'm guessing here and i'd also say valve know why they decided on this one.

Yes, I do agree with you. If this means much more constant experience for example in controller latency I will happily sacrifice some fps. Maybe also streaming from other computer will also benefit from this. Changing the kernel to the non-rt kernel should be also possible if these changes are not good for some one. This is Linux after all.

[justmy2cents]

According to these slides (Sony employee):
http://elinux.org/images/5/51/Elce11_rowand.pdf
We might expect next effects using realtime kernel (these are copied from the slides)
- Variance of real-time task latency decreased
+ Maximum real-time task latency decreased
- Average real-time task latency may be increased
- Throughput decreased.

thanks on link

PREEMPT RT enabled:
- larger average
- larger minimum
+ smaller maximum
+ more consistent

please do correct me if i'm wrong, but i can't help my self but to see nothing but positive here, determinism simply could not exist without taking some toll. but, when you look at graph minimum didn't suffer much, maximum on the other hand did. as i see it input is constant small job that must be fitted to run constantly during larger processes and rt kernel seems to serve exactly that. i personally prefer predictable consistence.. worst case for game to be unplayable is that your input stutters like it did on some ps3 games i played where bluetooth 100ms lag was already norm. but, as i already said... i'm guessing here and i'd also say valve know why they decided on this one.

[ninez]

It has not. http://pastebin.com/PnEtb1aG

You should probably look a little deeper in their packages... They ship a config for both PREEMPT_RT_FULL and non_rt;

(from llinux-source-3.10_3.10.11-1+steamos5+bsos1_all.deb)

/usr/src/linux-config-3.10/config.amd64_none_amd64.xz <- Generic
/usr/src/linux-config-3.10/config.amd64_rt_amd64.xz <- PREEMPT_RT_FULL

and;

/usr/src/linux-source-3.10.tar.xz <- mainline kernel sources
/usr/src/linux-patch-3.10-rt.patch.xz <- PREEMPT_RT_FULL patch

...

IME, this is typical of any company that i have ever encountered who is using linux-rt patchset in their product... You include both, but usually in production, you are using RT with the vast majority of kernel debugging disabled, etc...

...and (again) in linux_3.10.11-1+steamos5.debian.tar.xz;

.../patches/features/all/rt (contains linux-rt 3.10 patch, but broken down to individual commits/patches. 282 patches)

[kwahoo]

This is quite understandable because Valve has modified Linux kernel with real time patches.

It has not. http://pastebin.com/PnEtb1aG

[hjhamala]

i might be wrong here, but big part of why they use modified kernel would probably be other reasons like input latency and sound (maybe graphics too, i trully don't know as this is just my guessing). sometimes games run visually fine and dandy, but when you try playing input lag is insufferable. killzone 2 prepatch on ps3 for example run steady (and damn beautiful) 30fps, but when you tried to shoot... lag. when you see this you kinda wish graphics would stutter instead of input. as long as game can provide 30fps, input latency will become defining factor on how playable it is. and it was not only killzone 2 on ps3. the bluetooth adding its own toll forced me to use my controller as wired in whole lot of games just to prevent my self from throwing them into trashbin. and with time, i never went back to unplugged version same as i'll never buy wireless controller again.

but, hey that is just me

According to these slides (Sony employee):
http://elinux.org/images/5/51/Elce11_rowand.pdf
We might expect next effects using realtime kernel (these are copied from the slides)
- Variance of real-time task latency decreased
+ Maximum real-time task latency decreased
- Average real-time task latency may be increased
- Throughput decreased.