Hi! I have installed this kernel in my dedicated server(stated by the "Welcome to Ubuntu 16.04.6 LTS (GNU/Linux 5.2.0-9.1-liquorix-amd64 x86_64)" after ssh login) and i have run this command to know the timer frequency: "grep 'CONFIG_HZ' /boot/config-5.2.0-9.1-liquorix-amd64" and the results are:




I have read here([link]) that this kernel had it set to 1000 mhz. Is the output of the command correct?
Back to top

Why Liquorix is set to a periodic timer of 250hz is a long story.

Ideally, I would prefer running 1000hz with tickless idle, but MuQSS exhibits unusual timekeeping behavior that has unwanted side-effects. The two most noticeable side-effects are:

1) CPU usage in top and other related tools doesn't seem quite right when idle.
2) CPU frequency governors don't have enough information to know they can ramp down the frequency, thus without information about the CPU being idle, the governors always thing the CPU is busy, thus ramping the frequency up.

To fix this, I had to run Liquorix on a periodic timer instead of tickless idle. This had another huge side-effect, old systems would generate coil whine from the high tick frequency. Modern laptops would idle very badly and pull far more power than necessary while doing nothing.

The compromise is running 250hz periodic. This gives the CPU governors ondemand and intel-pstate enough information at a regular basis to downclock the CPU when idle, and the reduce tick frequency lets Intel CPUs idle in their C6/C7 states more efficiently, drastically reducing power usage.

I've tried 100hz but time accounting seems broken there as well, so 250hz is as coarse as I'm willing to go. Fortunately, MuQSS completely sidesteps the poor time accounting with high resolution timers (currently set at 2ms granularity), so for the most part, most problems with low tick frequency have been mitigated.

Hopefully that explains what happened and why Liquorix is configured so differently than most distributions stock kernel and linux-zen itself.

EDIT: Looks like the time accounting bug previously affecting MuQSS has been fixed. I restored 1000hz tick rate + tickless idle: github.com/damentz/liquorix-package/commit/c74763b72d8eaa30c873a52801de4ead0ef3a415

< Edited by damentz :: Dec 16, 19, 19:33 >
Back to top

This other thread claims it is using 1000hz:
https://techpatterns.com/forums/about2415.html&highlight=confighz

What's the current setting of the zen kernel? And is Liquorix's kernel the same as "the official zen kernel" in this regard?
Thanks.
Back to top

damentz is zen which is liquorix, thus, he already answered your question.
Back to top

@zenbuddhist, your timing is impeccable. I just restored 1000 hz + tickless idle the day after you posted due to a question about the tick rate here: github.com/damentz/liquorix-package/issues/22

Turns out that the bug that broke time accounting for cpufreq and cpu monitoring tools got fixed some time after I switched Liquorix to 250hz.
Back to top

Thanks! This might be of interest too: https://passthroughpo.st/config_hz-how-does-it-affect-kvm/

It isn't entirely clear how config_hz relates to overall system latency, but it definitely doesn't seem analogous to the polling rate of a USB device (i.e. 125hz vs 1000hz).
Back to top

That's a useful article, and it does confirm my suspicion. All the tick rate does is increase the spin frequency for certain operations in the kernel.

I know one important feature is that the tickrate is used to calculate the cpufreq ondemand sample rate. The higher your tick rate, the more chances you get per second to update time accounting, therefore you have more data to compute the correct frequency to run your processor at.

The two most revealing benchmarks are latencymon and Rainbox Six Siege, the latency was measurably reduced, which may impact applications that depend on it. The second is the minimum FPS, which impacts the "feel" of the game. Almost all benchmark channels on YouTube include this information because it's well understood that 0.1% frame rates impact stutter, jitter, and the general feel of the game.

And last, just hearing feedback, when I was forced to reduce tick rate to a constant 250hz due to time accounting bugs, one person mentioned it increased their underruns in their audio applications. What this sounds like to me is a deviation of up to 3-4ms is enough to impact low latency audio applications. What this also tells me is it sounds like there's a market for certain applications where you run above 1000hz, but that would need to be a standalone kernel! Con Kolivas has experimented with this but it was deemed useless, and many drivers exhibit bugs over 1000hz, so you'd need a special use case with very particular hardware so you can use the high tick rate without any of the trade offs.
Back to top

Would be nice for developers to know more about how it works. For example, what's so special/specific about 1000hz that over it causes these bugs & by what threshold? For example, on a graph of bugs as y axis and hz as x axis from 0 -> 2000hz - does the graph of bugs basically start directly @ 1000hz? This doesn't make sense to me.

Thanks again for your thoughtful reply.
Back to top