Announcement

Collapse
No announcement yet.

Benchmarking Ubuntu's Low-Latency Kernel & Liquorix Post-Meltdown

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

  • #21
    Neat, with systemd services. I like that.

    Originally posted by Linuxxx View Post
    For BFQ, you need to add as well:
    Code:
    scsi_mod.use_blk_mq=1 elevator=bfq
    You're welcome!
    For kernels that have BFQ compiled in (not as a module) like most decent ones after 4.12, elevator=bfq does not work. The scsi_mod.use_blk_mq=1 is still required as a kernel commandline.
    You must create a udev config file like for example 20-block.rules in /etc/udev/rules.d with the below in it and it will set BFQ as default during boot.

    ACTION=="add|change", SUBSYSTEM=="block", ATTR{queue/scheduler}="bfq"

    https://bfq.teambelgium.net/

    Comment


    • #22
      Originally posted by starshipeleven View Post
      Neat, with systemd services. I like that.

      For kernels that have BFQ compiled in (not as a module) like most decent ones after 4.12, elevator=bfq does not work. The scsi_mod.use_blk_mq=1 is still required as a kernel commandline.
      You must create a udev config file like for example 20-block.rules in /etc/udev/rules.d with the below in it and it will set BFQ as default during boot.

      ACTION=="add|change", SUBSYSTEM=="block", ATTR{queue/scheduler}="bfq"

      https://bfq.teambelgium.net/
      Just tried to activate BFQ "my way" with GRUB on openSUSE Tumbleweed with Linux Kernel 4.14.

      Output of dmesg | grep scheduler:
      Code:
      [    2.081113] io scheduler noop registered
      [    2.081114] io scheduler deadline registered
      [    2.081126] io scheduler cfq registered
      [    2.081127] io scheduler mq-deadline registered
      [    2.081127] io scheduler kyber registered
      [    2.081135] io scheduler bfq registered (default)
      So yeah, seems to work...

      BTW, in my very limited testing of BFQ so far, things look quite promising!
      It's just that I thought blk-mq wasn't ready yet...

      Comment


      • #23
        Originally posted by Linuxxx View Post
        For the first 2, if you get cpupower already autostarted, you can do it all in its config file, which to me seems cleaner, as that way you easily know what to look for in a year or 10 when you want to change things.

        Comment


        • #24
          Originally posted by starshipeleven View Post
          Damn son, what is this, XDA?

          I'll just say BFQ beats Deadline by a long shot when under moderate/heavy I/O, and it's only going to get better.
          Until BFQ crashes or hard-locks their system and watch them crawl back to CFQ or Deadline.

          Comment


          • #25
            Originally posted by Rallos Zek View Post

            Until BFQ crashes or hard-locks their system and watch them crawl back to CFQ or Deadline.
            Link? I'm not saying it's not possible but it helps to have actual issues reported.

            Comment


            • #26
              These days, noop is probably the best scheduler, if you're seeking overall performance. SSDs have all sorts of internal algorithms which we know nothing about. noop just serves it and lets the hardware decide. Yes, if you're interested in "smooth" performance, you can try to mess things up with another scheduler, but if you're a cli, emacs type of person, go noop all the way. FIFO and let the hardware do it's magic.

              Comment


              • #27
                Originally posted by AndyChow View Post
                These days, noop is probably the best scheduler, if you're seeking overall performance. SSDs have all sorts of internal algorithms which we know nothing about. noop just serves it and lets the hardware decide. Yes, if you're interested in "smooth" performance, you can try to mess things up with another scheduler, but if you're a cli, emacs type of person, go noop all the way. FIFO and let the hardware do it's magic.
                If you want the hardware to be in charge, why not use none then?

                Comment


                • #28
                  Originally posted by Rallos Zek View Post

                  Until BFQ crashes or hard-locks their system and watch them crawl back to CFQ or Deadline.
                  True, had that happen to me already!

                  So, just like I thought, BFQ and/or blk-mq still isn't ready for prime-time just yet...

                  Comment


                  • #29
                    Originally posted by HenryM View Post
                    I'm surprised Liquorix topped any tests, as I'm pretty sure it is tuned for UX and low latency rather than throughput (which is why I use it).

                    Sure would be interesting if somebody could measure actual input latency in say CS:GO with a variety of hardware and software. I can't find anything like that online, other than someone testing the Dolphin emu on windows.
                    If you care about input lag: disable wait for VBL, disable triple/double buffering in your app and in Xorg, and use a VGA CRT monitor.

                    Comment


                    • #30
                      1000hz tick? You should go the other way. I did minimal jitter config a few years ago, and found 90hz to be the best. Another critical aspect is renicing X to -15.

                      With a good minimal jitter kernel config, and OS tweaks, I got the peak jitter below 200 microseconds. And that was a few years ago! Extremely smooth graphics, and responsive OS.
                      Last edited by Paradox Ethereal; 17 January 2018, 08:25 PM.

                      Comment

                      Working...
                      X