Solved buildworld and kernel scheduler questions

Thx for reminding me not to blindly set knobs where I have no clue what I'm doing ;) I did some quick research:
Benefits to set kern.hz > 1000:
  1. The timer's resolution is higher => more accurate timing e.g. for multimedia
  2. If you set IRQ polling(4) requires setting kern.hz >= 1000. IRQ polling is advantageous, not only for the typical desktop workload (see manpage).
    This reminds me to fgrep -ri polling /usr/src to check if more devices support it. I'm pretty sure that the manpage is outdated.
the same question here, allways I think if kern.hz was in 200/300 value the hardware response will be faster,so faster response?
my whole universe is upside down :-/

btw I like your loader.conf and sysctl.conf , I give it a try step to step
but is just was a looking for
and with comments in every setting :)
 
I don't know but I strongly guess no. You can avoid or at least mitigate screen tearing with options for your Xorg graphics driver, e.g. for intel: set Option "TearFree" "on" in /usr/local/X11/xorg.conf.d/video.conf. For other GPU please RTFM the respective manpage. Also see xorg.conf(5).
 
Code:
kern.hz="2000"                  # (1000) 2000 for better interactivity (laptop/desktop)
That does not improve interactivity at all.

The main reason why you might want to increase HZ is to improve accuracy when using DUMMYNET (see ipfw(8)), or when using polling mode with certain NICs. However, the default of 1000 is usually sufficient for typical use cases. And even if you increase the HZ value, you will probably only notice a difference in certain corner cases on servers. I would not generally try to tune this on desktop machines. The increased overhead isn’t worth it.

In fact I have decreased HZ on my desktop machine to 600. Why 600? Because it is an integer multiple of common video frame rates (24, 25, 30, 50, 60 Hz), which can help video player processes to be scheduled on time if the CPU has a certain load. (If there is no load, then it doesn’t matter.) Note that it is important that HZ is not a multiple of the stat clock (default 127; there is rarely a reason to change it), otherwise the kernel statistics will suffer from aliasing effects, e.g. you will get weird load values, things that depend on timing statistics (e.g. DUMMYNET) will start misbehaving, and so on.

I think the majority of your other settings are unnecessary and have a placebo effect at best. But I think most of them should not be harmful. ;)
 
[...]
the default of 1000 is usually sufficient for typical use cases. And even if you increase the HZ value, you will probably only notice a difference in certain corner cases on servers. I would not generally try to tune this on desktop machines. The increased overhead isn’t worth it.
There's a note in the Handbook:

Code:
kern.hz=100
I think it should works for other virtualization system too, e.g. VMware. I'm not sure though. So any comments would be appreciated.
 
In fact I have decreased HZ on my desktop machine to 600. Why 600? Because it is an integer multiple of common video frame rates (24, 25, 30, 50, 60 Hz), which can help video player processes to be scheduled on time if the CPU has a certain load.
This is a really interesting idea, will give it a try! BTW, will the precision of things like setitimer(2) and usleep(3) depend on this setting?
 
wolffnx : Please invest a minute to correct the typo in the thread's title: scheluder -> scheduler. It hurts my eyes... ;) Thx.
olli@ : As always, your valuable feedback is greatly appreciated. Calling my settings have an "placebo effect" urges me to add another topic on my todo list:
  1. thoroughly check & research again about all non-default settings,
  2. document research results: links into docs -> journal (log book), and
  3. measure their effect on my typical workload using scientific methods.
  4. Check the data series taken with ministat(1) (what a useful tool!) or a spreadsheet's statistics functions.
  5. Report results here to the forum.
On that kern.hz=600: since I have set polling(7) on my em(4) interface, I'll not go below 1000, but according to your post I'l try 1200 and 1800.
vigole , VMs obviously have their special needs.
 
This is a really interesting idea, will give it a try! BTW, will the precision of things like setitimer(2) and usleep(3) depend on this setting?
IIUC the kern.hz is mainly used by the CPU runtime scheduler. There are other system clocks to measure timings etc. sysctl -d kern.clockrate && sysctl kern.clockrate
Code:
kern.clockrate=Rate and period of various kernel clocks
kern.clockrate={ hz = 2000, tick = 500, profhz = 8128, stathz = 127 }
EDIT I.e. I strongly guess these functions use the stathz.
 
EDIT I.e. I strongly guess these functions use the stathz.
But THIS would mean even worse precision. The APIs allow to specify microseconds :-/

I'd like to know which precision I could expect in practice, and whether/how it might depend on these clock rates…
 
Note that it is important that HZ is not a multiple of the stat clock (default 127; there is rarely a reason to change it), otherwise the kernel statistics will suffer from aliasing effects, e.g. you will get weird load values, things that depend on timing statistics (e.g. DUMMYNET) will start misbehaving, and so on.
Is this asured in the source code? FMLU it is, but I'd like to read your comment.
Code:
/*
* Clock handling routines.
*
* This code is written to operate with two timers that run independently of
* each other.
*
* The main timer, running hz times per second, is used to trigger interval
* timers, timeouts and rescheduling as needed.
*
* The second timer handles kernel and user profiling,
* and does resource use estimation.  If the second timer is programmable,
* it is randomized to avoid aliasing between the two clocks.  For example,
* the randomization prevents an adversary from always giving up the cpu
* just before its quantum expires.  Otherwise, it would never accumulate
* cpu ticks.  The mean frequency of the second timer is stathz.
*
* If no second timer exists, stathz will be zero; in this case we drive
* profiling and statistics off the main clock.  This WILL NOT be accurate;
* do not do it unless absolutely necessary.
*
* The statistics clock may (or may not) be run at a higher rate while
* profiling.  This profile clock runs at profhz.  We require that profhz
* be an integral multiple of stathz.
*
* If the statistics clock is running fast, it must be divided by the ratio
* profhz/stathz for statistics.  (For profiling, every tick counts.)
*
* Time-of-day is maintained using a "timecounter", which may or may
* not be related to the hardware generating the above mentioned
* interrupts.
*/
EDIT there is some logic that FMLU asures hz != N * stathz for any integer N, but I only took a quick glimpse.
I had actually the same idea (setting it to 1800). The only question is how to measure or evaluate the results?
Good question: how to measure the vage terms interactivity & responsiveness?
My intent was to lower the scheduler's timeslice quantum by decreasing kern.sched.slice (increase #timeslices/interval), so tasks running quasi-parallel get less CPU time but more often, and to quicker allow interactive tasks to force involuntary context switches by increasing kern.sched.preempt_thresh. Additionally, FMLU kern.sched.always_steal=1 will increase CPU throughput? All this is independant from the kernel clock kern.hz, which only determines the clock's accuracy. If s/o can show me the respective equations result in the overhead I added to the scheduler's work outweights the benefits I'm aiming at, or even worse: my naive "tuning" does not achieve what I thought it would, please don't hesitate to do so. I'm in no way a OS (CPU time-) scheduler wizzard.
 
This is a really interesting idea, will give it a try! BTW, will the precision of things like setitimer(2) and usleep(3) depend on this setting?
I was wrong, I just checked: HZ is set to 300 only (I did that via kernel configuration, not via loader.conf(5)). This is both on my desktop and on my home server. My mp3 player has HZ=100.

setitimer(2) and getitimer(2) use “ticks” accuracy (i.e. 1/HZ). Portable applications should not assume any specific resolution; it’s probably best to assume a resolution of 10 ms. If you need more than that, use clock_gettime(2) (see below).

In contrast, usleep(3) is just a wrapper around nanosleep(2), which in turn calls clock_nanosleep(CLOCK_REALTIME), which uses full timer resolution. This is also what clock_gettime(2) uses.

The actual resolution is hardware-dependent (and portable programs should not rely on it). To find out what you have, look at the kern.timecounter.hardware sysctl. It tells you which one of the various hardware clocks were selected for the kernel’s time counter base. Then you can look up its frequency with the kern.timecounter.tc.<name>.frequency sysctl.
For example, the system that I’m sitting in front of right now has this:
Code:
olli@ryzen:~ > COUNTER=$(sysctl -n kern.timecounter.hardware)
olli@ryzen:~ > echo $COUNTER
TSC-low
olli@ryzen:~ > FREQ=$(sysctl -n sysctl kern.timecounter.tc.$COUNTER.frequency)
olli@ryzen:~ > echo $FREQ
1597043936
olli@ryzen:~ > awk "BEGIN {print 1000^3 / $FREQ}"
0.626157
So, the resolution would be roughly 0.626 ns in this case (0.000626 µs).

Of course, that’s only the theoretical maximum resolution. FreeBSD is not a real-time OS (and it can’t be, because typical PC hardware is not real-time capable). For example, at any time, the scheduler may decide to put another process on the CPU and suspend your own process, so the time value that you just fetched may be moot. Not even rtprio(1) gives you any kind of guarantee. Also keep in mind that calls to usleep(3) and nanosleep(2) may return prematurely when a signal is delivered to the process.
 
Thanks, this is a really complete description! I could have needed that once when I wrote a simulation for a system with a lot of AVR µcs, maybe I should bookmark that posting :) For now, gotta remember setitimer(2) indeed depends on the HZ setting and there might be better ways.
 
Good question: how to measure the vage terms interactivity & responsiveness?
My intent was to lower the scheduler's timeslice quantum by decreasing kern.sched.slice (increase #timeslices/interval), so tasks running quasi-parallel get less CPU time but more often, and to quicker allow interactive tasks to force involuntary context switches by increasing kern.sched.preempt_thresh. Additionally, FMLU kern.sched.always_steal=1 will increase CPU throughput? All this is independant from the kernel clock kern.hz, which only determines the clock's accuracy. If s/o can show me the respective equations result in the overhead I added to the scheduler's work outweights the benefits I'm aiming at, or even worse: my naive "tuning" does not achieve what I thought it would, please don't hesitate to do so. I'm in no way a OS (CPU time-) scheduler wizzard.
I did some experiments with sysctl kern.sched.slice values from 1 up to default value 12 and measured the graphics performance with benchmarks/glmark2. Did not find any clear pattern or optimal value. I am aware that glmark2 measures only GPU performance and not responsiveness. Also, it does not even consume all CPU. It is a long test and running it several times over does give different values. My conclusion was that there is no difference in this case.

In the other hand, higher glmark2 values mean better GUI responsiveness. When I replace the GPU with less powerful model, naturally the glmark2 gives lower reading and the system also feels slower.
 
In fact I have decreased HZ on my desktop machine to 600. Why 600? Because it is an integer multiple of common video frame rates (24, 25, 30, 50, 60 Hz), which can help video player processes to be scheduled on time if the CPU has a certain load. (If there is no load, then it doesn’t matter.)
FTR: I followed your advice & was perfectly happy for ~2 weeks with kern.hz="300". Until today I connected an external Bluetooth speaker box to charge it through USB & had weird flickering that didn't even go away when I disconnected that box. Now with kern.hz="600" I have no flicker anymore, while the speaker box is beeing charged & my neighbours get a reminder that I'm still alive & kickin' (that small beast makes LOUD...).
I think the majority of your other settings are unnecessary and have a placebo effect at best. But I think most of them should not be harmful. ;)
I insist @least on dev.pcm.*.bitperfect=1 because it SOUNDS so superior :p
BTW maybe even more important for a pleasant multimedia experience are the respective application's knobs, e.g. caching. I had interrupts in the music playback when opening some config dialog or switching to another app's window when enjoying music videos with multimedia/mplayer. These were vastly mitigated once I enabled the 2 MB (default preset) cache for the media stream.
 
Back
Top