[ntp:questions] NTP + kernel frequency

Per Hedeland per at hedeland.org
Sat Nov 10 12:05:37 UTC 2007

In article <4735707a$0$29249$ba620e4c at news.skynet.be> Jan Ceuleers
<janspam.ceuleers at skynet.be> writes:
>Jan Ceuleers wrote:
>> Per Hedeland wrote:
>>> On Linux, a simpler way can be to look at /proc/interrupts - e.g.
>>> (probably Linux-version- and possibly config-specific):
>>> $ (cat /proc/interrupts; sleep 10; cat /proc/interrupts) | \
>>>   awk '/timer/{prev=now; now=$2} END{printf "%dHz\n", 
>>> int((now-prev)/10)}'
>> This yields 41Hz on my Via C7 machine (which has frequency scaling and 
>> runs a 2.6.22-based kernel) while it's idle, and a higher number (e.g. 
>> 90Hz) while it's doing something. It yields 100Hz on a Soekris 4801 
>> running 2.4.31.
>> In other words, this method doesn't seem to be entirely reliable, 
>> possibly as a side effect of frequency scaling.

Yeah, so add another (rather obvious I think) caveat to the two I
already gave. But unless the system is quite broken, i.e. a 'sleep 10'
doesn't actually last for 10 seconds, it does produce the average number
of clock interrupts per second during those 10 seconds - and as
mentioned elsewhere, if that number varies wildly, ntpd may not be very
happy anyway. FWIW, Hal's method is likely to get a value closer to the
"nominal" or "max" HZ on such a system, as it will keep the CPU/kernel
somewhat busy - maybe firing up a 'while :; do :; done' before running
the above will give a "better" value too.

>Found this method:
># getconf CLK_TCK
>Works on both machines.

Are you sure?:-) It's not universal in any case, here's a typical
semi-recent Linux (FC5 with 2.6.20-mumble):

$ (cat ... ) | awk ...

- which is the correct number, but

$ getconf CLK_TCK                                                     

I wouldn't be surprised if that number is effectively a constant - hm,
no need to guess when strace is around... - yes, that seems about right,
the only thing the program does by way of "active" syscalls is a
readlink() on /usr/libexec/getconf/default.

Actually, what it tells you is not HZ but (as the param name indicates)
the number of "clock ticks" per second - this is an "abstract" number
required for interpretation of the result of a times() call, and need
not be the same as the actual clock interrupt frequency - it obviously
*mustn't* be on a system where the latter varies over time. 100 is the
correct value for the 1000Hz system above - but of no interest to ntpd.

--Per Hedeland
per at hedeland.org

More information about the questions mailing list