NTP + kernel frequency - NTP

This is a discussion on NTP + kernel frequency - NTP ; Hello all and soory for english ... I known now, in the "recen"t 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 ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: NTP + kernel frequency

  1. NTP + kernel frequency

    Hello all and soory for english ...

    I known now, in the "recen"t 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 ?

    thanks for all
    --
    __________________
    / Laurent Archambault \
    |-------------------------------|
    |Gentoo and Mandriva |
    _-----------------------------_

  2. Re: NTP + kernel frequency


    >I known now, in the "recen"t 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.


  3. Re: NTP + kernel frequency

    In article
    hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:
    >
    >>I known now, in the "recen"t 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.)


    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)}'

    Why there isn't a /proc entry or sysctl that gives the frequency
    directly I don't know...

    --Per Hedeland
    per@hedeland.org

  4. Re: NTP + kernel frequency

    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.

    Cheers, Jan

  5. Re: NTP + kernel frequency

    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.


    Found this method:

    # getconf CLK_TCK
    100

    Works on both machines.

  6. Re: NTP + kernel frequency

    In article <47356F94.5080901@skynet.be>,
    Jan Ceuleers wrote:

    > In other words, this method doesn't seem to be entirely reliable,
    > possibly as a side effect of frequency scaling.


    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.

  7. Re: NTP + kernel frequency

    In article <4735707a$0$29249$ba620e4c@news.skynet.be> Jan Ceuleers
    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
    per@hedeland.org

  8. Re: 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.


  9. Re: 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.
    >


  10. Re: 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.
    >


  11. Re: NTP + kernel frequency

    David L. Mills wrote:

    > 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.


    The idea is to have a tickless system. This
    is interesting not only for laptops but for (massively) virtualised
    systems as well. ( Think of dozens of VMs going into galloping horde
    mode to each service their (virtual) timer interrupt.

    This does not mean that if requested a regular timer will not run.

    uwe



  12. Re: NTP + kernel frequency

    On Sat, 10 Nov 2007 00:38:23 +0000, Per Hedeland wrote:

    > In article
    > hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:
    >>
    >>>I known now, in the "recen"t 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.)

    >
    > 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 doesn't work on multi-CPU systems.

    : cat /proc/interrupts |grep timer
    0: 129602418 129428516 IO-APIC-edge timer

    You need to sum across all CPUs. A bit more complex:

    -------------- snip --------------

    #!/usr/bin/perl -w

    $cpus=`grep -c processor /proc/cpuinfo`;

    $_=`grep timer /proc/interrupts`; @prev=split();

    sleep 10;

    $_ =`grep timer /proc/interrupts`; @now =split();

    for (1..$cpus) { $prev+=$prev[$_]; $now+=$now[$_]}

    printf "%dHz\n", int(($now-$prev)/10);

    -------------- snip --------------

    --
    2007/11/13:11:39:48UTC Slackware Linux 2.4.32
    up 29 days, 23:31, 6 users, load average: 2.18, 2.26, 2.25


  13. Re: NTP + kernel frequency

    In article Andrew
    Hood writes:
    >On Sat, 10 Nov 2007 00:38:23 +0000, Per Hedeland wrote:
    >
    >> In article
    >> hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:
    >>>
    >>>>I known now, in the "recen"t 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.)

    >>
    >> 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 doesn't work on multi-CPU systems.


    Actually the system I verified it on (mentioned elsewhere in the thread)
    was dual-CPU...

    >: cat /proc/interrupts |grep timer
    > 0: 129602418 129428516 IO-APIC-edge timer


    ....but you're right of course - it just so happened that all the "timer"
    interrupts were fielded on CPU 0 on the system where I tried it:

    $ cat /proc/interrupts |grep timer
    0: 3845082271 0 IO-APIC-edge timer

    (Probably not a random thing, but I don't know what causes it - there's
    certainly no "end user" config to make it so.)

    >You need to sum across all CPUs. A bit more complex:
    >
    >-------------- snip --------------
    >
    >#!/usr/bin/perl -w


    It's still possible to do with a one-liner awk, just that the line gets
    a tad longer.:-) Left as an exercise etc...

    --Per Hedeland
    per@hedeland.org

  14. Re: 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

  15. Re: 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/kerne...nel/time/ntp.c

+ Reply to Thread