Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 22

Thread: The First NVIDIA GeForce Benchmarks On The SteamOS Beta

  1. #11
    Join Date
    Oct 2013
    Posts
    363

    Default

    Quote Originally Posted by hjhamala View Post
    This is quite understandable because Valve has modified Linux kernel with real time patches. Generally realtime kernel have lower latency but also lower peak performance.

    Hopefully Michael will test SteamOS with unmodified 3.10 kernel. This should reveal what is the effect of the modifications.
    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

  2. #12
    Join Date
    Jun 2011
    Posts
    830

    Default

    Quote Originally Posted by hjhamala View Post
    This is quite understandable because Valve has modified Linux kernel with real time patches. Generally realtime kernel have lower latency but also lower peak performance.

    Hopefully Michael will test SteamOS with unmodified 3.10 kernel. This should reveal what is the effect of the modifications.
    Yes and no / it's probably more complicated than that / won't reveal anything really all that useful.

    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.

  3. #13
    Join Date
    Dec 2013
    Location
    Helsinki, Finland
    Posts
    9

    Default

    Quote Originally Posted by justmy2cents View Post
    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.

  4. #14
    Join Date
    Jul 2012
    Posts
    148

    Default

    Quote Originally Posted by hjhamala View Post
    This is quite understandable because Valve has modified Linux kernel with real time patches.
    It has not. http://pastebin.com/PnEtb1aG

  5. #15
    Join Date
    Jun 2011
    Posts
    830

    Default

    Quote Originally Posted by kwahoo View Post
    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)

  6. #16
    Join Date
    Oct 2013
    Posts
    363

    Default

    Quote Originally Posted by hjhamala View Post
    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.

  7. #17
    Join Date
    Dec 2013
    Location
    Helsinki, Finland
    Posts
    9

    Default

    Quote Originally Posted by justmy2cents View Post
    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.

  8. #18
    Join Date
    Jul 2012
    Posts
    148

    Default

    Quote Originally Posted by ninez View Post
    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?

  9. #19
    Join Date
    Jun 2011
    Posts
    830

    Default

    Quote Originally Posted by kwahoo View Post
    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.

  10. #20
    Join Date
    Dec 2013
    Location
    Helsinki, Finland
    Posts
    9

    Default

    Quote Originally Posted by ninez View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •