Re: [ntp:questions] NTP + kernel frequency
David L. Mills wrote: Hal Murray wrote: There is a lot of work going on in the Linux kernel to avoid unnecessary timer interrupts in order to save power on laptops and other systems running off batteries. Any work on the Linux kernel to avoid timer interrupts is incompatible with NTP. This is not a bad or good judgement, just and engineering constraint. If timer interrupts are disabled, disable NTP. On the issue about timer interrupts at frequencies other than 100 Hz, this is easy to fix. The nanokernel code that left here uses a constant SHIFT_PLL that must be scaled inversely as the timer interrupt frequency. It does not need to be exact, but close. I don't know how or even whether this code is mangled in the Linux kernel, but there you have it. If provisions to fix this are not in the Linux kernel and the timer frequency is other than 100 Hz, then the Linux build and install process should not include ntpd; alternatively, the kernel discipline must be disabled. One can browse the Linux kernel NTP implementation here: http://lxr.linux.no/source/kernel/time/ntp.c The entire time directory might be of interest: http://lxr.linux.no/source/kernel/time/ The NTP_INTERVAL_FREQ macro is defined as: #ifdef CONFIG_NO_HZ #define NTP_INTERVAL_FREQ (2) #else #define NTP_INTERVAL_FREQ (HZ) #endif ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP + kernel frequency
David Woolley wrote: I'm not familiar with frequency scaling, but I would suggest that if the kernel interrupt rates are not constant, ntpd also won't be entirely reliable. Dave Mills complains from time to time that the Linux kernel doesn't adjust the kernel PLL parameters correctly when the clock rate is varied from 100 Hz to another fixed rate, so I very much doubt that the kernel PLL code has been correctly modified to cope with a dynamically variable interrupt rate. There is also an issue that the fixed speed code rounds things in a way that only certain rates are safe. The kernel interrupt rate is a better indication of what really matters (except that it will read low if you are losing interrupts) than HZ, if there is any systematic difference between them. If a developer for that code doesn't raise their head here, now, I think it pretty much safe to assume that the machine is not suitable for ntpd use for anything except a pure client with low time quality expectations. Basically, if the developers are not monitoring this news group, it is almost certain that they not properly taken into account ntpd's needs. As a user of ntpd on Linux, I find it disheartening to hear that Linux kernel hackers do not work more closely with NTP hackers. (It'd be nice to have PPS support in the vanilla kernel.) The latest patches to kernel/time/ntp.c can be seen here: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=history;f=kernel/time/ntp.c ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP + kernel frequency
Hal,
Ooop; sorry for the runt that escaped here.
Any work on the Linux kernel to avoid timer interrupts is incompatible
with NTP. This is not a bad or good judgement, just and engineering
constraint. If timer interrupts are disabled, disable NTP.
ON the issue about timer interrupts at frequencies other than 100 Hz,
this is easy to fix. The nanokernel code that left here uses a constant
SHIFT_PLL that must be scaled inversely as the timer interrupt
frequency. It does not need to be exact, but close. I don't know how or
even whether this code is mangled in the Linux kernel, but there you
have it. If provisions to fix this are not in the Linux kernel and the
timer frequency is other than 100 Hz, then the Linux build and install
process should not include ntpd; alternatively, the kernel discipline
must be disabled.
Dave
Hal Murray 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.
There is a lot of work going on in the Linux kernel to avoid
unnecessary timer interrupts in order to save power on laptops
and other systems running off batteries.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP + kernel frequency
Hal Murray 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.
There is a lot of work going on in the Linux kernel to avoid
unnecessary timer interrupts in order to save power on laptops
and other systems running off batteries.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP + kernel frequency
In article [EMAIL PROTECTED] Jan Ceuleers
[EMAIL PROTECTED] 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
100
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 ...
1000Hz
- which is the correct number, but
$ getconf CLK_TCK
100
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
[EMAIL PROTECTED]
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP + kernel frequency
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.
There is a lot of work going on in the Linux kernel to avoid
unnecessary timer interrupts in order to save power on laptops
and other systems running off batteries.
--
These are my opinions, not necessarily my employer's. I hate spam.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP + kernel frequency
I known now, in the recent kernel the internal frequency will be to 250 Mhz... With my gentoo it's not a problem for me because i make myself my kernel ... but if i take Mandriva or a another distribution how find this values ? I assume you mean the scheduling clock which would be 250 Hz rather than MHz. One way is to look in the kernel souces. Another way is to measure it. Write a program that usleeps for a microsecond and see how long it really takes. (Do it in a loop for 1000 tries and print out a histogram.) There is often a double roundup. Some code rounds the 1 uSec to 1 tick, and the next layer adds another tick since you are already partway through the current tick. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
