Linux 11-minute mode (RTC update) - NTP

This is a discussion on Linux 11-minute mode (RTC update) - NTP ; Hello everyone, I run Linux kernel 2.6.22.1-rt9 and ntpd 4.2.4p0 # adjtimex --print mode: 0 offset: 77 frequency: -1309904 maxerror: 493576 esterror: 50 status: 1 time_constant: 6 precision: 1 tolerance: 33554432 tick: 10000 raw time: 1207230744s 183249us = 1207230744.183249 In ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 56

Thread: Linux 11-minute mode (RTC update)

  1. Linux 11-minute mode (RTC update)

    Hello everyone,

    I run Linux kernel 2.6.22.1-rt9 and ntpd 4.2.4p0

    # adjtimex --print
    mode: 0
    offset: 77
    frequency: -1309904
    maxerror: 493576
    esterror: 50
    status: 1
    time_constant: 6
    precision: 1
    tolerance: 33554432
    tick: 10000
    raw time: 1207230744s 183249us = 1207230744.183249

    In my setup, STA_UNSYNC (0x0040, clock unsynchronized) is 0.

    Thus, ntp_synced() returns 1.

    Thus the kernel should write the system time to the RTC every
    11 minutes; but it does not.

    The relevant code is in sync_cmos_clock()

    http://lxr.linux.no/linux/kernel/time/ntp.c#L188

    I've added several printk() to this function, and it appears
    that it is never called.

    The relevant timer is defined with the following macro.

    static DEFINE_TIMER(sync_cmos_timer, sync_cmos_clock, 0, 0);

    which expands to

    static struct timer_list sync_cmos_timer =
    {
    .function = sync_cmos_clock,
    .expires = 0,
    .data = 0,
    .base = &boot_tvec_bases
    };

    The problem seems to be that this timer is never armed, to bootstrap
    the process. It seems there should be a call to mod_timer() somewhere.

    do_adjtimex() calls notify_cmos_timer() unconditionally.

    static void notify_cmos_timer(void)
    {
    if (no_sync_cmos_clock)
    mod_timer(&sync_cmos_timer, jiffies + 1);
    }

    What are the semantics of notify_cmos_timer?
    What is it supposed to do?

    And what is 'no_sync_cmos_clock' supposed to mean?
    /* Disable the cmos update - used by virtualization and embedded */
    int no_sync_cmos_clock __read_mostly;
    Why would we (re)arm the timer when 'no_sync_cmos_clock' is true?

    I'd be grateful for anyone sharing their knowledge.

    Regards.

  2. Re: Linux 11-minute mode (RTC update)

    Hello,

    On Thursday, April 3, 2008 at 16:25:17 +0200, Noob wrote:

    > STA_UNSYNC (0x0040, clock unsynchronized) is 0. [...] Thus the kernel
    > should write the system time to the RTC every 11 minutes; but it does
    > not.


    Fine! Don't touch anything, happy man, or it might well "tomber en
    marche". Real men don't want the eleven-minutes mode. It is not only
    extremely inaccurate by itself, but it also steps on the toes of those
    tools that are able to manage the RTC properly.

    I previously posted some figures, comparing the accuracy of writing the
    RTC (not counting drift). Mean offset and dispersion:

    - eleven-minutes mode: -2150 Ás +-5000
    - hwclock util-linux-ng 2.13.1: -2500 Ás +-170
    - hwclock 2.32 from BJH: 0 Ás +-10

    Furthermore both hwclocks are able to evaluate and compensate the drift
    of the RTC. The eleven-minutes mode cannot do that, and instead it can
    perturbate hwclock's calculations.


    Serge.
    --
    Serge point Bets arobase laposte point net

  3. Re: Linux 11-minute mode (RTC update)

    Serge Bets wrote:

    > Noob wrote:
    >
    >> STA_UNSYNC (0x0040, clock unsynchronized) is 0. [...] Thus the kernel
    >> should write the system time to the RTC every 11 minutes; but it does
    >> not.

    >
    > Fine! Don't touch anything, happy man, or it might well "tomber en
    > marche".


    Hello Serge, I was hoping you'd comment!

    If I don't want the kernel to update the RTC, I can always undef
    CONFIG_GENERIC_CMOS_UPDATE.

    > Real men don't want the eleven-minutes mode.


    :-)

    > It is not only extremely inaccurate by itself, but it also steps on
    > the toes of those tools that are able to manage the RTC properly.


    Our equipment is supposed to run 24/7 for months / years.
    I need to keep the RTC synchronized, in case of power failure.

    Do you believe that running hwclock --systohc periodically is better
    than using the kernel's 11-minute mode?

    > I previously posted some figures, comparing the accuracy of writing the
    > RTC (not counting drift). Mean offset and dispersion:
    >
    > - eleven-minutes mode: -2150 Ás +-5000
    > - hwclock util-linux-ng 2.13.1: -2500 Ás +-170
    > - hwclock 2.32 from BJH: 0 Ás +-10


    Point taken.

    ( I use http://giraffe-data.com/software/about_hwclock.html )

    If I use hwclock to update the RTC, how often should I do it?

    What do you think about the following script?

    while true
    do
    sleep 660 # or some other value?
    hwclock --utc --systohc
    done

    > Furthermore both hwclocks are able to evaluate and compensate the drift
    > of the RTC. The eleven-minutes mode cannot do that, and instead it can
    > perturbate hwclock's calculations.


    Is the crystal of the RTC supposed to be more stable than the crystal
    of the CPU?

    Regards.

  4. Re: Linux 11-minute mode (RTC update)

    Noob wrote:

    >
    > Is the crystal of the RTC supposed to be more stable than the crystal of
    > the CPU?
    >


    Neither is supposed to be particularly stable, although the RTC crystal
    may be a watch crystal, so may keep reasonably good time if maintained
    at wrist temperature.

  5. Re: Linux 11-minute mode (RTC update)

    Noob writes:

    >Serge Bets wrote:


    >> Noob wrote:
    >>
    >>> STA_UNSYNC (0x0040, clock unsynchronized) is 0. [...] Thus the kernel
    >>> should write the system time to the RTC every 11 minutes; but it does
    >>> not.

    >>
    >> Fine! Don't touch anything, happy man, or it might well "tomber en
    >> marche".


    >Hello Serge, I was hoping you'd comment!


    >If I don't want the kernel to update the RTC, I can always undef
    >CONFIG_GENERIC_CMOS_UPDATE.


    >> Real men don't want the eleven-minutes mode.


    >:-)


    >> It is not only extremely inaccurate by itself, but it also steps on
    >> the toes of those tools that are able to manage the RTC properly.


    >Our equipment is supposed to run 24/7 for months / years.
    >I need to keep the RTC synchronized, in case of power failure.


    >Do you believe that running hwclock --systohc periodically is better
    >than using the kernel's 11-minute mode?


    >> I previously posted some figures, comparing the accuracy of writing the
    >> RTC (not counting drift). Mean offset and dispersion:
    >>
    >> - eleven-minutes mode: -2150 Ás +-5000
    >> - hwclock util-linux-ng 2.13.1: -2500 Ás +-170
    >> - hwclock 2.32 from BJH: 0 Ás +-10


    >Point taken.


    >( I use http://giraffe-data.com/software/about_hwclock.html )


    >If I use hwclock to update the RTC, how often should I do it?


    >What do you think about the following script?


    >while true
    >do
    > sleep 660 # or some other value?
    > hwclock --utc --systohc
    >done


    >> Furthermore both hwclocks are able to evaluate and compensate the drift
    >> of the RTC. The eleven-minutes mode cannot do that, and instead it can
    >> perturbate hwclock's calculations.


    >Is the crystal of the RTC supposed to be more stable than the crystal
    >of the CPU?


    Nope. It is less stable. But what you really want is the drift rate of the
    crystal when the computer is shut off ( ie cooling or cold) and all you can
    measure is the drift rate when it is on (warm and constant)
    The sensitivity of the rtc crystal to temp can be up to 10 times worse than
    the cpu clock's sensitivity.
    (www.theory.physics.ubc.ca/chrony/chrony.html)

    However, even a crude drift compensation is probably better than none. Just
    don't expect any miracles from the RTC.




    >Regards.


  6. Re: Linux 11-minute mode (RTC update)


    >Fine! Don't touch anything, happy man, or it might well "tomber en
    >marche". Real men don't want the eleven-minutes mode. It is not only
    >extremely inaccurate by itself, but it also steps on the toes of those
    >tools that are able to manage the RTC properly.


    Would somebody please collect this info on a wiki page.


    From my view, it's dumb for the kernel to write to the RTC
    since I can do that from user land. Why add clutter to the
    kernel?

    On the other hand, the kernel probably wants to read the clock
    early in the boot sequence so that the time is close. I don't
    want the kernel cluttered up with code to correct the raw
    hardware reading (besides, the file with the info in it may not
    be mounted yet), so writing out the correct time occasionally
    seems like a reasonable idea. I'd be thinking of hours or days
    rather than 11 minutes, and I can do that from a cron job.


    --
    These are my opinions, not necessarily my employer's. I hate spam.


  7. Re: Linux 11-minute mode (RTC update)

    "Noob" wrote in message
    news:47f61e28$0$21694$426a34cc@news.free.fr...
    [...]
    > What do you think about the following script?
    >
    > while true
    > do
    > sleep 660 # or some other value?
    > hwclock --utc --systohc
    > done


    That, apart from the sleep, it would make a nice cron job.

    Groetjes,
    Maarten Wiltink



  8. Re: Linux 11-minute mode (RTC update)

    "Maarten Wiltink" writes:

    >"Noob" wrote in message
    >news:47f61e28$0$21694$426a34cc@news.free.fr...
    >[...]
    >> What do you think about the following script?
    >>
    >> while true
    >> do
    >> sleep 660 # or some other value?
    >> hwclock --utc --systohc
    >> done


    >That, apart from the sleep, it would make a nice cron job.


    Well, also without the while loop. Ie, just the hwclock line.
    As many have said, every 11 min seems a bit often.

    >Groetjes,
    >Maarten Wiltink




  9. Re: Linux 11-minute mode (RTC update)

    On Friday, April 4, 2008 at 14:25:12 +0200, Noob wrote:

    > If I don't want the kernel to update the RTC, I can always undef
    > CONFIG_GENERIC_CMOS_UPDATE.


    Ah thanks! I wasn't aware of this new switch. I hope Dean is reading, he
    was after an easy solution.


    > Do you believe that running hwclock --systohc periodically is better
    > than using the kernel's 11-minute mode?


    There is a cost: eleven-minutes mode is extra-light on processor cycles.
    Depending on the mode of operation, hwclock consumes either much more,
    or enormously more cycles. OTOH its drift compensation allows sparser
    usage. And the accuracy is way better, and well worth the cost IMHO.


    > I use http://giraffe-data.com/software/about_hwclock.html


    Good: that's the best version.


    > If I use hwclock to update the RTC, how often should I do it?


    It depends on your expectations. As Hal said, once per hour or once per
    day seem quite sufficient. I used to use a daily cron job, with
    excellent results. Stopped it only because I don't manage any 24/7
    machine anymore.

    Let's compare: The eleven-minutes mode needs to write the RTC every
    11 minutes because its drift is not compensated, and will very quickly
    degrade future reads. Example an RTC with a 100 PPM drift rate. After
    10 minutes there is already a 60 ms offset. Just then happen 20 minutes
    of power outage. When power comes back, the RTC has accumulated 180 ms
    of drift. During bootup the kernel clock initialises with this offset,
    that ntpd will have to step.

    During bootup, hwclock --hctosys compensates the drift since the last
    write by hwclock --systohc. This last write happened either during a
    clean shutdown, or in a cron job some hours before a power failure.
    Example: same 100 PPM rate, same 20 minutes of outage, but happening
    23 hours after the daily cron job. At restart, the RTC has accumulated
    8.4 seconds of drift. But during bootup hwclock compensates this
    entirely, and the kernel clock is hopefully initialised "perfect", or
    rather at some low milliseconds of the One True Time.

    Conclusion: an hwclock once per day is already better that an
    eleven-minutes mode 130 times per day.


    > What do you think about the following script?


    - Sleep 55 minutes minimum (otherwise drift rate is not reevaluated).
    - Call hwclock only when the kernel clock is synced.
    - Better resist to system load with --cpupriority=99

    | while true
    | do
    | sleep 86398
    | if adjtimex --print | grep -q " return value = 5"
    | then
    | honk --db=130 --cucaracha
    | else
    | hwclock --utc --systohc --cpupriority=99
    | fi
    | done


    > Is the crystal of the RTC supposed to be more stable than the crystal
    > of the CPU?


    No. And the RTC has to run in a much wider temperature range. Typical
    kernel clock can vary by one or two PPM. Typical RTC by 12 PPM. Unless
    in an always-on machine, where the RTC variation may stay similar, one
    or two PPM.

    In the 24/7 situation, with power outage of maximum 20 minutes, the
    bootup hwclock needs to compensate the RTC drift accumulated during
    a mixed period of 0 to 24 hours of power-on plus 0 to 20 minutes of
    power-off. Those 20 minutes are barely sufficient for a complete
    cooling. So let's pretend it's all power-on drift, and let hwclock
    evaluate it. Just what happens every day with the above script.

    If the expected power outages can reach 2 hours, or 2 days, then it's
    another story.


    Serge.
    --
    Serge point Bets arobase laposte point net

  10. Re: Linux 11-minute mode (RTC update)

    Hello Bill,

    On Friday, April 4, 2008 at 16:16:22 +0000, Bill Unruh wrote:

    > what you really want is the drift rate of the crystal when the
    > computer is shut off ( ie cooling or cold)


    That's very true for workstations halted each evening; much less for
    Spoon's 24/7 servers.


    > all you can measure is the drift rate when it is on (warm and
    > constant)


    One can easely measure the power-off RTC drift rate at room temperature:
    Just shutdown the machine during some hours between two well synced
    invocations of hwclock --systohc, and then:

    | $ awk '{printf "%+.3f ppm", -$1 / 0.0864; exit}' /etc/adjtime
    | +12.345 ppm


    Serge.
    --
    Serge point Bets arobase laposte point net

  11. Re: Linux 11-minute mode (RTC update)

    Serge Bets writes:

    > On Friday, April 4, 2008 at 14:25:12 +0200, Noob wrote:


    >> If I don't want the kernel to update the RTC, I can always undef
    >> CONFIG_GENERIC_CMOS_UPDATE.


    >Ah thanks! I wasn't aware of this new switch. I hope Dean is reading, he
    >was after an easy solution.



    >> Do you believe that running hwclock --systohc periodically is better
    >> than using the kernel's 11-minute mode?


    >There is a cost: eleven-minutes mode is extra-light on processor cycles.
    >Depending on the mode of operation, hwclock consumes either much more,
    >or enormously more cycles. OTOH its drift compensation allows sparser
    >usage. And the accuracy is way better, and well worth the cost IMHO.


    By enourmously more you mean 100 rather than 10 cycles? Ie, I cannot
    believe that hwclock run once an hour would even be noticed on a quiet
    machine running nothing else, never mind a machine doing something.

    Note that the advantage of recording the rate as well as offset of the rtc
    may be illusionary. The rate is
    determined when the machine is hot. The rate of the rtc is important when
    the machine is off (cold) The rate of the rtc crystal as a function of temp
    can be attrocious ( one of my machines has an rtc clock that varies from
    0PPM to 100PPM with a few degree temp change-- I think the rtc may be
    dying.)It is usually much worse than the temp dependence of the computer
    crystal.





    >> I use http://giraffe-data.com/software/about_hwclock.html


    >Good: that's the best version.



    >> If I use hwclock to update the RTC, how often should I do it?


    >It depends on your expectations. As Hal said, once per hour or once per
    >day seem quite sufficient. I used to use a daily cron job, with
    >excellent results. Stopped it only because I don't manage any 24/7
    >machine anymore.


    >Let's compare: The eleven-minutes mode needs to write the RTC every
    >11 minutes because its drift is not compensated, and will very quickly
    >degrade future reads. Example an RTC with a 100 PPM drift rate. After
    >10 minutes there is already a 60 ms offset. Just then happen 20 minutes
    >of power outage. When power comes back, the RTC has accumulated 180 ms
    >of drift. During bootup the kernel clock initialises with this offset,
    >that ntpd will have to step.


    >During bootup, hwclock --hctosys compensates the drift since the last
    >write by hwclock --systohc. This last write happened either during a
    >clean shutdown, or in a cron job some hours before a power failure.
    >Example: same 100 PPM rate, same 20 minutes of outage, but happening
    >23 hours after the daily cron job. At restart, the RTC has accumulated
    >8.4 seconds of drift. But during bootup hwclock compensates this
    >entirely, and the kernel clock is hopefully initialised "perfect", or
    >rather at some low milliseconds of the One True Time.


    >Conclusion: an hwclock once per day is already better that an
    >eleven-minutes mode 130 times per day.



    >> What do you think about the following script?


    > - Sleep 55 minutes minimum (otherwise drift rate is not reevaluated).
    > - Call hwclock only when the kernel clock is synced.
    > - Better resist to system load with --cpupriority=99


    >| while true
    >| do
    >| sleep 86398
    >| if adjtimex --print | grep -q " return value = 5"
    >| then
    >| honk --db=130 --cucaracha
    >| else
    >| hwclock --utc --systohc --cpupriority=99
    >| fi
    >| done



    >> Is the crystal of the RTC supposed to be more stable than the crystal
    >> of the CPU?


    >No. And the RTC has to run in a much wider temperature range. Typical
    >kernel clock can vary by one or two PPM. Typical RTC by 12 PPM. Unless
    >in an always-on machine, where the RTC variation may stay similar, one
    >or two PPM.


    >In the 24/7 situation, with power outage of maximum 20 minutes, the
    >bootup hwclock needs to compensate the RTC drift accumulated during
    >a mixed period of 0 to 24 hours of power-on plus 0 to 20 minutes of
    >power-off. Those 20 minutes are barely sufficient for a complete
    >cooling. So let's pretend it's all power-on drift, and let hwclock
    >evaluate it. Just what happens every day with the above script.


    >If the expected power outages can reach 2 hours, or 2 days, then it's
    >another story.



    >Serge.
    >--
    >Serge point Bets arobase laposte point net


  12. Re: Linux 11-minute mode (RTC update)

    Serge Bets writes:

    >Hello Bill,


    > On Friday, April 4, 2008 at 16:16:22 +0000, Bill Unruh wrote:


    >> what you really want is the drift rate of the crystal when the
    >> computer is shut off ( ie cooling or cold)


    >That's very true for workstations halted each evening; much less for
    >Spoon's 24/7 servers.



    >> all you can measure is the drift rate when it is on (warm and
    >> constant)


    >One can easely measure the power-off RTC drift rate at room temperature:
    >Just shutdown the machine during some hours between two well synced
    >invocations of hwclock --systohc, and then:


    >| $ awk '{printf "%+.3f ppm", -$1 / 0.0864; exit}' /etc/adjtime
    >| +12.345 ppm


    Sure, and you can also do it with a lab full of equipment and a good time
    source. That is not the question under discussion. The question is whether
    or not the drift compensation in hwclock is worthwhile. I would say a bit,
    but much less than you might think.



    >Serge.
    >--
    >Serge point Bets arobase laposte point net


  13. Re: Linux 11-minute mode (RTC update)

    Maarten Wiltink wrote:

    > Noob wrote:
    >
    >> What do you think about the following script?
    >>
    >> while true
    >> do
    >> sleep 660 # or some other value?
    >> hwclock --utc --systohc
    >> done

    >
    > That, apart from the sleep, it would make a nice cron job.


    Using cron is a possibility.

    I was considering a script because we use a custom distribution
    (of which cron is not currently a part of) and we have limited
    space (only 40 MB IIRC).

    Regards.

  14. Re: Linux 11-minute mode (RTC update)

    On Saturday, April 5, 2008 at 18:27:37 +0000, Unruh wrote:

    > Serge Bets writes:
    >> Depending on the mode of operation, hwclock consumes either much
    >> more, or enormously more cycles.

    > By enourmously more you mean 100 rather than 10 cycles?


    I don't have the exact timings at hand, but it's yet more. The
    eleven-minutes write takes some tens of microseconds; normal hwclock
    some tens of milliseconds; hwclock --nointerrupt some plain seconds.


    > The rate of the rtc is important when the machine is off (cold)


    Again, what you say is true in the general case. Not at all, or less, in
    the OP case (24/7 servers rarely and shortly off).


    > one of my machines has an rtc clock that varies from 0PPM to 100PPM
    > with a few degree temp change-- I think the rtc may be dying.


    Aouch! Indeed totally out of bounds.


    Serge.
    --
    Serge point Bets arobase laposte point net

  15. Re: Linux 11-minute mode (RTC update)

    On Saturday, April 5, 2008 at 18:31:11 +0000, Unruh wrote:

    > That is not the question under discussion. The question is [...]


    "Beware: Who wanders your threads, will soon wander your clocks." ;-)


    > whether or not the drift compensation in hwclock is worthwhile.
    > I would say a bit, but much less than you might think.


    I'm quite excited in front of a half full glass, and you come revealing
    me it is half empty. That hurts, Bill... We'll see what results the OP
    obtains: I promised him "some low ms" of offset at restart, before ntpd
    takes control.


    Serge.
    --
    Serge point Bets arobase laposte point net

  16. Re: Linux 11-minute mode (RTC update)

    Serge Bets writes:

    > On Saturday, April 5, 2008 at 18:27:37 +0000, Unruh wrote:


    >> Serge Bets writes:
    >>> Depending on the mode of operation, hwclock consumes either much
    >>> more, or enormously more cycles.

    >> By enourmously more you mean 100 rather than 10 cycles?


    >I don't have the exact timings at hand, but it's yet more. The
    >eleven-minutes write takes some tens of microseconds; normal hwclock
    >some tens of milliseconds; hwclock --nointerrupt some plain seconds.


    To write the rtc properly takes at least a second. The rtc ONLY reports
    once a second and is set to the time you supply when you write it. Thus you
    have to make sure that you write at exactly the right time or the rtc will
    be out by up to a second.



    >> The rate of the rtc is important when the machine is off (cold)


    >Again, what you say is true in the general case. Not at all, or less, in
    >the OP case (24/7 servers rarely and shortly off).


    In the case the machine comes up again in a few seconds, the rate
    correction is irrelevant anyway. And if the system reads the clock badly it
    will be out by about a second anyway.




    >> one of my machines has an rtc clock that varies from 0PPM to 100PPM
    >> with a few degree temp change-- I think the rtc may be dying.


    >Aouch! Indeed totally out of bounds.


    I agree. Not sure what is happening.



    >Serge.
    >--
    >Serge point Bets arobase laposte point net


  17. Re: Linux 11-minute mode (RTC update)


    > > If I don't want the kernel to update the RTC, I can always undef
    > > CONFIG_GENERIC_CMOS_UPDATE.

    >
    > Ah thanks! I wasn't aware of this new switch. I hope Dean is reading, he
    > was after an easy solution.


    I am. Thanks Serge.

    Dean

  18. Re: Linux 11-minute mode (RTC update)

    On Sunday, April 6, 2008 at 19:36:40 +0000, Unruh wrote:

    > Serge Bets writes:
    >> The eleven-minutes write takes some tens of microseconds; normal
    >> hwclock some tens of milliseconds; hwclock --nointerrupt some plain
    >> seconds.

    > To write the rtc properly takes at least a second.


    I was talking about processor time consumed. As for wall clock time
    elapsed, indeed a background cron job mostly sleeping or waiting for an
    interrupt during one or two seconds is rather harmless.


    > In the case the machine comes up again in a few seconds, the rate
    > correction is irrelevant anyway.


    Drift compensation is important even for a stop and go: maybe the stop
    was a crash, and the RTC was last written hours ago. But the point was
    more that as long as the downtime stays short, the temperature of the
    RTC, and thus its instant drift rate, does not vary too much from the
    mean runtime values. Therefore it makes sense to pick the runtime rate
    for compensation. Only in this specific 24/7 case.


    > And if the system reads the clock badly it will be out by about a
    > second anyway.


    This never happens on a proper setup: hwclock --hctosys syncs on the RTC
    down to a few microseconds.


    Serge.
    --
    Serge point Bets arobase laposte point net

  19. Re: Linux 11-minute mode (RTC update)

    Serge Bets writes:

    > On Sunday, April 6, 2008 at 19:36:40 +0000, Unruh wrote:


    >> Serge Bets writes:
    >>> The eleven-minutes write takes some tens of microseconds; normal
    >>> hwclock some tens of milliseconds; hwclock --nointerrupt some plain
    >>> seconds.

    >> To write the rtc properly takes at least a second.


    >I was talking about processor time consumed. As for wall clock time
    >elapsed, indeed a background cron job mostly sleeping or waiting for an
    >interrupt during one or two seconds is rather harmless.



    >> In the case the machine comes up again in a few seconds, the rate
    >> correction is irrelevant anyway.


    >Drift compensation is important even for a stop and go: maybe the stop
    >was a crash, and the RTC was last written hours ago. But the point was
    >more that as long as the downtime stays short, the temperature of the
    >RTC, and thus its instant drift rate, does not vary too much from the
    >mean runtime values. Therefore it makes sense to pick the runtime rate
    >for compensation. Only in this specific 24/7 case.



    We are discussing the hwclock vs the 11 min rule. Thus the last time the
    rtc was corrected ( perhaps badly if the rtc correction in the kernel is
    badly implimented) was a max of 11 min ago. Even at 100PPM drift that is
    "only" 60ms.

    Thus, if it is true that the hwclock routine sets/reads the system clock
    better than does the kernel, and if your drift rate is that high, then it
    is probably better to do the hwclock route.

    Note as I pointed out, the temp dependence of the rtc can be huge ( and is
    typically much larger than the temp dependence of the cpu crystal.) The
    insides cool off rapidly if the system shuts down. The temp sensitivity of
    a bunch of computers I run have a 4-20 x more sensitivity for the rtc than
    for the onboard clock. Thus if the cpu is say .5PPM/deg, the RTC will be up
    to 10PPM/deg. Since the computer cools of by at least 10 deg very rapidly,
    that is up to 100PPM difference in the RTC between on and off.

    If the server goes off for 10-30 min ( not unusual for example with a disk
    failure, or with response time of the person) that is 100s of msec.
    difference.

    It would I admit be interesting to actually do some experiments to see how
    much worst the rtc is cooled than warm.
    And also whether or not the Linux kernel actually does a decent job of
    setting the rtc.





    >> And if the system reads the clock badly it will be out by about a
    >> second anyway.


    >This never happens on a proper setup: hwclock --hctosys syncs on the RTC
    >down to a few microseconds.



    >Serge.
    >--
    >Serge point Bets arobase laposte point net


  20. Re: Linux 11-minute mode (RTC update)

    Serge Bets wrote:

    > This never happens on a proper setup: hwclock --hctosys syncs on the RTC
    > down to a few microseconds.


    I have a question regarding hwclock --systohc (the other way around).

    After setting the RTC, hwclock reports:
    Hardware clock ended up -0.001261 seconds from intended set time.

    And this "offset" is always approximately -1.25 ms
    What is the problem here? Is it even a problem?

    NB: even though hwclock thinks the kernel is in 11-minute mode,
    I've removed the code where the kernel writes to the RTC.


    Full dump:

    # hwclock --utc --systohc --cpupriority=99 --debug
    hwclock 2.30
    Kernel IS in 11 minute mode
    WARNING from hwclock: The clock was in 11 minute mode, which normally
    means that something else, possibly an NTP daemon, has been setting
    the hardware clock. Setting the clock with hwclock turns off 11
    minute mode. See hwclock documentation.
    User did not specify a clock access method. Searching for one...
    Found RTC device special file '/dev/rtc'
    Using rtc ioctl interface to clock via file '/dev/rtc'.
    Adjtime file contents:
    drift factor = 0.000000, missed in last set = 0.000000
    LOCAL (0 seconds west of GMT), epoch = 1900
    Last drift adjustment done Thu Jan 1 00:00:00 1970 (Time 0) +
    0.000000 secs
    Last calibration done Thu Jan 1 00:00:00 1970 (Time 0)
    Correction: -0.000028
    Assuming hardware clock's zero year is 1900
    Assuming hardware clock is kept in UTC time.
    Setting absolute priority to 99
    At 1207641420.196823, waiting for clock tick...
    Waiting for interrupt...
    ....got clock tick at system time 1207641420.603735
    Raw time read from Hardware Clock: Y=2008 M=4 D=8 07:56:59
    mktime_tz: TZ environment variable is not set.
    mktime_tz: temporarily setting TZ to HWCLOCK_TEMP +00:00
    Hw clock time : Tue Apr 8 07:56:59 2008 = 1207641419 seconds since
    1969 UTC
    Restoring absolute priority to 0
    Reference time for clock setting is 1207641420.604020
    Setting absolute priority to 99
    Time elapsed since reference time has been 0.000052 seconds.
    Will set the clock at 1207641421.500028
    localtime_tz: TZ environment variable is not set.
    mktime_tz: temporarily setting TZ to HWCLOCK_TEMP +00:00
    Will set Hardware Clock to 07:57:01(+.5) with timezone offset 0
    seconds, which is 1207641421 (+.5) seconds since 1969 UTC
    Waiting for Time 1207641421.500028 - the next odd half-second
    Sleeping for 0.875895 seconds. Good night everybody!
    ioctl(RTC_SET_TIME) was successful.
    Restoring absolute priority to 0
    Hardware Clock has been set.
    Now wait for next clock tick (should be 500 ms).
    Setting absolute priority to 99
    At 1207641421.500223, waiting for clock tick...
    Waiting for interrupt...
    ....got clock tick at system time 1207641422.001261
    Raw time read from Hardware Clock: Y=2008 M=4 D=8 07:57:02
    mktime_tz: TZ environment variable is not set.
    mktime_tz: temporarily setting TZ to HWCLOCK_TEMP +00:00
    Hw clock time : Tue Apr 8 07:57:02 2008 = 1207641422 seconds since
    1969 UTC
    Restoring absolute priority to 0
    It is now 1.397241 seconds since reference time.
    Hardware clock ended up -0.001261 seconds from intended set time.
    Not adjusting drift factor because of -nodrift optionor 11 minute
    modenew timezone offset for hardware clock is 0

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast