but, hey that is just me
but, hey that is just me
By default on -rt, most of your (threaded) IRQs are going to have a default rtprio of 50FF(fifo) - hence why 'rtirq' was made and/or people set those threads manually... All IRQs defaulting to 50FF isn't suitable at all and i doubt Valve would leave them as such (since that would have a negative impact on performance).... i also doubt Michael changed any of these settings - otherwise he would have mentioned it... Also, I am not sure how many HZ Ubuntu's kernel sets the kernel's tick too? (I believe Archlinux does 300HZ by defualt, while mine on RT is 1000HZ)...
if Ubuntu's is set to 300HZ, that may explain some of the difference, as SteamOS is set to 250HZ in it's kernel configuration file.
I think the only good way to reveal differences between their kernel and an unmodified, would be to have a SteamBox (which would be 'ideally configured' by Valve) and do the comparison there. (or if Michael can get some info on tuning his machine, as they would / get some useful pointers - then you might be able to get closer performance/accuracy)... I've been through all of SteamOS's kernel sources, kernel configs, etc. I've 1. diff'd their linux-rt patch against upstream 2. compared modified steam kernel (without RT applied, but with aufs and other bits applied) to Vanilla 3.10 and 3. inspected their debian source packages, as well.
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.
/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
/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)
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.
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.
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.