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

[deusexmachina]

I think you missed the most important part from that link you posted:


So, 1000 Hz is clearly the best, no matter how you look at it!

OK, but *why* does config_hz = 1000hz consistently increase frame rate? Especially since 250hz shows decreased latency in other benchmarks... It isn't clear to me how it works.

[Linuxxx]

After reading these benchmarks I realize I understand even less about what CONFIG_HZ actually does:

https://passthroughpo.st/config_hz-how-does-it-affect-kvm/

Seems 1000hz isn't necessarily the lowest latency, for example.

I think you missed the most important part from that link you posted:

Overall, 1000Hz nets better minimum framerates.
...
It is advisable to pick 1000Hz over 100Hz or 250Hz in order to receive a small but tangible minimum framerate improvement while gaming.

So, 1000 Hz is clearly the best, no matter how you look at it!

[deusexmachina]

Note that was what I used back then...

Nowadays I just run Ubuntu 18.04 LTS with the "lowlatency" kernel. (Which does have a 1000 Hz timer tick, by the way.)

After reading these benchmarks I realize I understand even less about what CONFIG_HZ actually does:

https://passthroughpo.st/config_hz-how-does-it-affect-kvm/

Seems 1000hz isn't necessarily the lowest latency, for example.

[Linuxxx]

Why not 1000hz?
https://serverfault.com/questions/37...solution-timer

I'll have to check how many of these settings are used in Arch by default...

Note that was what I used back then...

Nowadays I just run Ubuntu 18.04 LTS with the "lowlatency" kernel. (Which does have a 1000 Hz timer tick, by the way.)

[deusexmachina]

Here's how one can achieve real smoothness:

- Use openSUSE Tumbleweed, since it contains the best Linux Kernel config by default. (250Hz tick timer, PREEMPT enabled)

- Use the deadline İO scheduler.

- Use the 'performance' governor.

- Additionally, if stuck on İntel, make sure to set the 'performance-bias' to '0'!

Now enjoy your silky-smooth Linux experience!

Why not 1000hz?

https://serverfault.com/questions/377947/1000-hz-linux-kernel-necessary-if-i-have-tickless-and-high-resolution-timer

I'll have to check how many of these settings are used in Arch by default...

[AndyChow]

If you want the hardware to be in charge, why not use none then?

Because noop does request merges. So it can define sequential requests while it's in queue. It just doesn't schedule anything.

[Paradox Ethereal]

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.

[linuxgeex]

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.

[Linuxxx]

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...

[geearf]

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?