Announcement

Collapse
No announcement yet.

Benchmarking The Ubuntu "Low-Jitter" Linux Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    Originally posted by Kano View Post
    @Paradox Uncreated

    You completely disable composite in your instructions on your page. I don't think that will help any u unity user. KDE would still work that way but basically it is enough when you run off the effects when you play games or videos. Basically your nick is somehow "right", what you do is really "paradox". Your tuning efforts are completely out of control. It is impossible that you can get rid of disk io related issues with just increasing the priority for X. Where should the new data magically appear? If you play games that buffers everything at level start then you don't see that effect of course. When you look at rage - which can be run with wine as well (use: winetricks xact_jun2010 directx9) you will see an example that loads all the time textures from hd. Best get yourself a ssd and try it without your hacks. Next time you say when you run a copy process in the background that you can not play correctly. I personally think that your hacks for doom3/prey are overkill for most gfx cards - until you get really fast ones and should be never used.
    I am actually using IceWM here, Kano. When you are working with jitter also, you don`t want to enable anything that might obscure data. You again say it is impossible to get rid of "disk io", yet I am running without such interruptions from "disk i/o". So "disk i/o" isn`t "disk i/o" is simply is jitter, that can one can be rid of, by tightening up some timers, and scheduling policies.

    Actually what I want to do, is get an older computer, and continue tweaking, because jitter is so hard to see on this computer, lol.

    Peace Be With You.

    Comment


    • #52
      Did you ever play rage? I mean for doom3/prey in single player mode it is completely unimportant - you will never die because of a small lag - you can save everywhere and you could even use god mode.

      Comment


      • #53
        Wine isn`t the main focus for what I am doing. But wine also runs much better. I did play HL2 in it, and it runs close to my optimized windows install (100 threads). Some more jitter, but it is a compatibility layer after all. I have not tried Rage. Actually John Carmack says that doom 3 is more complex, doing rendering in three passes, so it is more sensitive to jitter.

        If you want to play Rage, rather install windows XP, and do these tweaks to get low-jitter on windows. http://paradoxuncreated.com/Blog/wordpress/?p=1783

        HL2 on windows plays perfectly then, and pro audiocards can do 1ms latency. However jitter sensitive games like doom 3 still run better on my low-jitter linux kernel.

        Peace Be With You.

        Comment


        • #54
          You can be sure that it is possible to play rage with wine. And in case you want to play it on win you need absolutely no tweaks! Just use a 64 bit os, then you have got at least 4gb for the app (not 3 on a 32 bit one). Whats your stupid purpose to use xp for new games? You own a dx10 card, ok, for opengl that would not matter, but xp is restricted to dx9. If there is something that you could do wrong, you do it wrong.

          Comment


          • #55
            I think you are missing the entire point Kano. And so are many. However even if asked "do you really not see jitter" the last guy says "oh, the disk-io", after claiming not seeing jitter.
            Last edited by Paradox Ethereal; 27 October 2017, 06:17 PM.

            Comment


            • #56
              Originally posted by Paradox Uncreated View Post
              Well a lot of people believe that and maybe even an SSD helps. But what would you say if I am running completely without those lost frames?

              Peace Be With You.
              Excuse me while I call out BS. Since you have yet to measure frame LATENCY, you can't make that claim. Sure, SLI/CF can spit out hundreds of FPS, but frames get dropped ALL THE TIME. (see: http://techreport.com/review/21516/i...e-benchmarking)

              Secondly, any modern scheduler should be smart enough to do something else while the HDD is busy with I/O (heck, any I/O operation is reason enough to preempt the current thread, since its going to be waiting for several thousand CPU cycles anyways...).

              Finally, you simply can't "remove" the time it takes to go to the HDD, get the necessary data, load it into RAM, then get it to the CPU, simply by changing a few numbers in the kernel. You can reduce the latency of getting your thread back running again somewhat, but thats about it.

              Finally, I note that if you turn every non-essential service off (no matter how useful), latency will naturally decrease. I wonder how well your kernel works when attempting to do multiple heavy-workload tasks at once. I would wager that all the extra context-switching would significantly increase the execution time of most all tasks.

              Comment


              • #57
                Obviously there is a lot of people out there that doesn`t get the point with jitter. Thank God, there is also a lot that DO.

                I think what I am trying to convey with referances to c64 1mhz no-jitter instant audio, should really go through and shatter some programming paradigms. And even if you want everything high-level there are ways of doing that, which reduces jitter, and as I say, I care only to 0.2ms max jitter/latency.

                EOF
                Peace Be With You.

                Comment


                • #58
                  PS: Intel is doing work with low-latency trading, and networking. So I probably don`t have to talk much about this anyway, and few need to understand

                  When you see low-latency traders talk about 800nS (nanosecond) latency, I am atleast happy for the latency developments.

                  That means development on low-latency/low-jitter is fully on-going..



                  Peace Be With You.
                  Last edited by Paradox Ethereal; 27 October 2017, 06:19 PM.

                  Comment


                  • #59
                    Originally posted by Paradox Uncreated View Post
                    PS: Intel is doing work with low-latency trading, and networking. So I probably don`t have to talk much about this anyway, and few need to understand

                    When you see low-latency traders talk about 800nS (nanosecond) latency, I am atleast happy.

                    That means development on low-latency/low-jitter is fully on-going and without the need for a lot of nutjobs calling it "BS" or whatever.

                    They should go back to their jittering desktops, and I don`t know.. not quite be present. I actually had an uncle like this. While on vacation once, everyone complained about flies, and mosquitobites. No, but he didn`t feel a thing.

                    It`s like thousand tweakapps on windows, and the arguments and work on BFS, that inspired CFS is about the same. But this uncle is 1 out of 10 I guess on a vacation, but that makes quite a few thousand online.

                    Peace Be With You.
                    Except trades are RIDICULOUSLY low-throughput intensive tasks. The lower you make the latency, the less throughput you are going to have.

                    Comment


                    • #60
                      So how do we benchmark this feature?

                      Since the article's benchmarks don't show anything (and the full set on openbenchmarking aren't showing anything either), how do you know there is a reduction in jitter?

                      Once you know that jitter is better, how can you measure it with a tool (preferably automated)?

                      If you can't measure it (or measure with reasonable accuracy), then how can we ever know if we're getting better at reducing it, or if we've gotten worse?

                      Comment

                      Working...
                      X