No announcement yet.

Benchmarking The Ubuntu "Low-Jitter" Linux Kernel

  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    I am wondering why you don't play games on your c64 then.


    • #42
      Originally posted by Paradox Uncreated View Post
      I think I wrote most of the changes I did here:
      I have not found any mention of the kernel config options you used. I can't even find them on the blog. Can you post them somewhere?


      • #43
        Originally posted by Paradox Uncreated View Post
        I post a lot there. Was there anything in specific? I can post the whole .config for 3.6.2 shaved local, which you can take inspiration from. PS, not full distro config.
        (I also did some edits, but they are documented on the blog)
        Thanks at least for this full config.
        Some list of the specific options you think must be set would be nice, e.g. a diff to the distro config.
        Also, I wonder where do you get the CONFIG_HZ_90 option, when vanilla kernel has a 100Hz option. Also I wonder why the lowest value is best, when the kernel config says the highest (1000Hz) option is for low-latency.


        • #44
          My kernels are faster and more responsive ... and energy consumption + my script APM at most 40-60% of standard solutions


          e X t 7 3


          • #45
            Originally posted by YoungManKlaus View Post
            Noob. Beer is very good at preserving itself without any additives and refridgeration, which is exactly why it is not kept in a freezer in the super market. I know because I tried one - even a unfiltered one where the guaranteed time is shorter, but still in the range of months - about two years after that date and it was still good as ever.
            - bottled in glass bottle, not aluminium can (though that should also work), or worst: PET
            - not opened
            - preferably strong (the stronger the better, obviously, as less germs survive)
            - brewer has to know what he was doing

            ... so in short, US beer is out
            The oldest beer I drank was > 20 years old. And it was unpasteurised & unfiltered (a flemish "oud bruin"). It was a little "flat" tasting after so much time, but still tasted okay, and I didn't get sick...

            And the "Abt" trappist ale from West-Vleteren is often at its best at 6-8yo (bottle refermentation and an artisanal brewing process make the result slightly unpredictable, but it's very unlikely it will be bad after 8 years).


            • #46
              Originally posted by Paradox Uncreated View Post
              PS: Even games were made in basic on c64, that had no slowdowns. Imagine interpreted basic, on a 1mhz CPU, can do lower-jitter than a modern pc. (well on many PCs )
              The OS on the C64 didn't support multitasking, so there weren't other processes competing for CPU time. That allows the application/game developer to have complete control over the CPU usage.

              The same was mostly true on a PC with DOS (see all the amazing things people from the demoscene did on that platform).


              • #47
                Originally posted by unix_epoch View Post
                Throughput benchmarks should only be included as an afterthought, if at all. They don't measure the important variable.
                Throughput benchmarking is important too, but mostly to make sure that after confirming that the changes give you low jitter, it doesn't impact throughput too much. You don't want nearly no jitter @ 1 FPS...

                (It's like after finding a new medicine, you want to make sure it doesn't have too many side-effects.)
                Last edited by JanC; 10-20-2012, 02:47 PM.


                • #48
                  Originally posted by Paradox Uncreated View Post
                  Kano, I do, and you should try Mega Apocalypse to get an idea of how fun a low-jitter game can be. And then boot back in to high-level OS paradigms where there is latency, and get an idea of what I think of those.

                  I post a lot there. Was there anything in specific? I can post the whole .config for 3.6.2 shaved local, which you can take inspiration from. PS, not full distro config.

                  Peace Be With you.

                  (I also did some edits, but they are documented on the blog)
                  Could you diff this with a config without your low-jitter changes?
                  Originally posted by Paradox Uncreated View Post
                  infact a setting of 20hz with BFS, will not be noticably different from 10.000 except cpu-usage.
                  I tested exactly this some days ago! I didn't do much testing, just booted with a kernel with 1000 hz and one with 100 hz and uses the same games. Games with slight input lat at 1000 hz had high input lag at 100. Note that this test was done with BFS, but I can't really believe that the result should turn around by using CFS...


                  • #49
                    Originally posted by Paradox Uncreated View Post
                    gamer2k completely misses both the point and the benchmark again, and states an old argument not relevant to this about "latency vs throughput". So if you increase latency on a c64, does it get more throughout? (*laugh here*)
                    Considering the C64 didn't have a pre-empting kernel, no. But in a pre-empting kernel, every time you switch from task "x", "x" is not getting work done. So you decrease system latency, but you increase the time it takes "x" to finish.

                    Hell, I could switch tasks with every tick of the CPU clock if I wanted to. Every system related task would be uber-snappy as a result. Any actual usespace program would run like crap though.

                    Obviously some people think jitter is "disk-io". If you have reduced "disk-io" with there being the same disk i/o, you know jitter is lower. (lol)
                    Do you have any idea how a modern pre-emptive scheduler works? If some thread needs to access the disk, it should be preempted (can not run). No matter how fast you make the rest of the system, you have a bottleneck that exists for that given thread, that you can NOT solve in S/W.

                    You are the worst type of developer: One who makes changes, convinced he is right, without testing every possible outcome. Then when people tells him the downsides to his approach, he ignores them. And when people start to tell him he outright breaks stuff, he laughs at them. Then people like me get paid to clean up the mess you leave behind.


                    • #50
                      Originally posted by Paradox Uncreated View Post

                      Tron OS did realtime in 1984. Was forced off the market by MS.
                      MS sees cp/m, copies it, although it is shit. Sells it to you.
                      MS sees unix windowmanager, copies it, sells it to you as windows, now with extreme latency. The very other end of realtime you might say. (nontime? sleepingbag-time?)
                      MS sees windowsblinds, copies it, another service on top of a poor scheduler and sells it to you.
                      200 things in modern windows OS, can be turned off, leaving a BETTER computer. What are they doing being developed, and included in the price of the product sold to you?
                      MS teaches obscure non-streamlined windows menus, and encourages people to not turn off these things, buying their whole corporate propaganda, and certifies people for this? What do you call that?

                      Linux is open-source, and can be modified by anyone, patches are often made in days, and emails to developers read in minutes.
                      By the time a fix may already be suggested on LKML, you have reached "I need to establish identiy please, I cannot hear you please" on MS support, phone to another country.

                      And that is ofcourse just some of it.

                      And then MS lanches it`s own OS, as a cure for headaches in their current (they did this with 98)

                      It`s mad, and serves no human.

                      Peace Be With You.
                      Any particular reason you aren't using the preempt_rt rather than just the preempt?
                      For what it's worth I think an RTOS is the obvious choice for gaming but you simply can't expect throughput to go up as a result (which you seem to think can happen). Rather, throughput is almost certainly going to go down, but I personally don't think that loss is of great significence for the Desktop market. The potential for increased interactivity and reliable responses is, as you've said, so nice.