On Jul 28, 2004, at 2:17 PM, sigsegv@rambler.ru wrote:
> roman$ sysctl kern.clockrate
> kern.clockrate: tick = 1000, tickadj = 4, hz = 1000, profhz = 1000, 
> stathz = 1000
>
> Does anyone know the mystery behind "sysctl kern.clockrate" values, 
> i.e. what they do and how they affect performance/responsiveness of 
> the system?

Sure.  Basicly, the operating system configures a device (the i8254) 
which generates an interrupt on a regular basis.  When you set HZ=1000, 
the clock rate is 1 millisecond, which is also known as the scheduler 
quantum.  Every time that interrupt fires, the system does a context 
switch from the process it is running, evaluates the list of runnable 
processes and their priorities, and figures out which process to run 
next, so as to share CPU amoung all of the tasks which the system wants 
to run.  This is called "preemptive multitasking".

I think tick * hz = 1000000-- ie, 1 second in microseconds, and the 
profhz and stathz have something to do with the Pentium CPU debugging 
and profiling mechanisms governed by the DE (Debugging Extensions) and 
TSC (Time Stamp Counter) features.

Hmm, you also asked about how HZ affects performance and 
responsiveness.  Let me dig up a related thread about changing HZ from 
100 to 1000 from a FreeBSD list:

	------

Poul-Henning Kamp wrote:
[ ... ]
> Most of my systems run with HZ=1000 already, but that is hardly
> ground for changes to the default.  What we need is some pro et
> contra arguments, including benchmarks.

You're right.  Back around 1990, Avie Tenavian spent some brainpower 
figuring out the preemptive scheduling overhead for Mach, and 
determined that a 25MHz 68040 machine took up to about 0.5 ms to handle 
a timer interrupt and run through the scheduler, which meant that the 
system lost about 5% overhead when using a 10ms scheduler quantum (or 
HZ=100, whatever).

While I think have some idea as to the time it takes a Pentium to do a 
context switch (300 clocks?), I don't know enough about the way the 
clock timer is managed under FreeBSD, nor do I know how much other 
stuff is glommed onto the periodic timer interrupt.  Mach used kernel 
threads and a messaging paradigm from day one, so it's scheduler was 
fairly simple-- less worrying about a queue of pending callbacks along 
the lines of libevent and kqueue.

Anyway, I suspect that the default scheduler quantum might be better 
chosen based on the scheduling overhead of each machine: set HZ as fast 
as the local system will deal with without exceeding a single-digit 
percent overhead...

	------

Let me also suggest you take a look at this document:

http://www.dragonflybsd.org/docs/nanosleep/

I wonder if NetBSD also has problems with nanosleep() and the tvtohz 
function (in kern/kern_clock.c)?  Give the wakeup_latency.c program a 
trial run or two at different HZ values, and see for yourself.

-- 
-Chuck