Linux 11-minute mode (RTC update) - NTP

This is a discussion on Linux 11-minute mode (RTC update) - NTP ; On Tuesday, April 8, 2008 at 10:01:59 +0200, Noob wrote: > 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 ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 56

Thread: Linux 11-minute mode (RTC update)

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

    On Tuesday, April 8, 2008 at 10:01:59 +0200, Noob wrote:

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


    Yes and no. This offset is mainly due to the RTC oscillator restarting
    a little bit late, ie the difference between the 500 ms in data sheets
    and reality. This value (and its jitter) is specific to a given RTC
    chip. Yours is quite low. I typically see between -1.7 and -2.3 ms,
    affected by 30 to 200 Ás of jitter, depending on RTC brand and model.

    It is *not* a problem, because the recent hwclocks include a feedback
    scheme measuring and compensating any write error, including this one.
    This feedback makes the few Ás accuracy available to hwclock, adjtimex,
    and any other RTC reading tools supporting the /etc/adjtime file.

    However you may like to precompensate the mean part of this delay when
    writing. For that, call once:

    | # hwclock --utc --systohc --cpupriority=99 --correct=+0.001233

    Following --systohc calls will remember and apply the same
    precorrection (you were using -0.000028).


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


    There is a problem though: hwclock is not aware that the kernel is
    patched. You will have to patch hwclock too. :-(

    = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
    --- hwclock/hwclock.c Sun Sep 21 22:24:03 2003
    +++ hwclock/hwclock.c Sun Mar 21 10:41:48 2004
    @@ -426,4 +426,5 @@ eleven_minute_mode(void) {
    if (debug)
    printf("Kernel %s in 11 minute mode\n", retval ? "IS" : "IS NOT");
    + retval = 0; /* Force no eleven mode (disabled in kernel) */
    return retval;
    }
    = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =


    > hwclock 2.30


    Better upgrade to hwclock 2.32, which includes several important
    improvements to accuracy.


    Cordialement, Serge.
    --
    Serge point Bets arobase laposte point net

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

    It shouldn't be forgot that the RTC can only be set and read with a
    granularity of seconds only. The 11-minute scheme doesn't synchronize
    the RTC to the exact second and when read, even waiting for up to a
    second for the read to change, it lacks accuracy. All this in
    addition to thermal drifting of the reference crystal frequency.

    The bottom line is that the RTC is just a little better than inputing
    the time manually whenever the system comes up. Of course, this is
    fine if time synchronization and discipline is soon taken over by NTP.

    HTH

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

    Hello Evandro,

    On Tuesday, April 8, 2008 at 8:13:18 -0700, Evandro Menezes wrote:

    > It shouldn't be forgot that the RTC can only be set and read with a
    > granularity of seconds only. The 11-minute scheme doesn't synchronize
    > the RTC to the exact second


    Granted, the eleven-minutes mode is bad. But not *so* bad. It sets the
    RTC tick in sync with real seconds, with a random error of maximum
    7 milliseconds.

    That's just that hwclock 2.32 does the same with a max error of
    10 microseconds, ie. almost 3 orders of magnitude better.


    Serge.
    --
    Serge point Bets arobase laposte point net

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

    On Monday, April 7, 2008 at 17:46:21 +0000, Unruh wrote:

    > if it is true that the hwclock routine sets/reads the system clock
    > better than does the kernel


    Well, neglecting drift, hwclock is already way more accurate than the
    kernel (several orders of magnitude better). And the kernel doesn't
    handle RTC drift. Check if you doubt.


    > that is up to 100PPM difference in the RTC between on and off.


    Aren't you drawing a general rule from a single out of bounds maybe
    dying example? I can provide a counter-example then. One Intel chipset
    RTC here drifts at:

    +77.269 PPM powered-off during the night
    +78.531 PPM runtime at day

    Which shows only 1.262 PPM variation between extreme conditions. That's
    the most stable I could find, of course. Don't draw conclusions from it.


    Serge.
    --
    Serge point Bets arobase laposte point net

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

    Serge Bets writes:

    > On Monday, April 7, 2008 at 17:46:21 +0000, Unruh wrote:


    >> if it is true that the hwclock routine sets/reads the system clock
    >> better than does the kernel


    >Well, neglecting drift, hwclock is already way more accurate than the
    >kernel (several orders of magnitude better). And the kernel doesn't
    >handle RTC drift. Check if you doubt.



    >> that is up to 100PPM difference in the RTC between on and off.


    >Aren't you drawing a general rule from a single out of bounds maybe
    >dying example? I can provide a counter-example then. One Intel chipset
    >RTC here drifts at:


    > +77.269 PPM powered-off during the night
    > +78.531 PPM runtime at day


    >Which shows only 1.262 PPM variation between extreme conditions. That's
    >the most stable I could find, of course. Don't draw conclusions from it.


    But when one is advising someone, one must assume that they have at least
    the typical if not the worst condition, unless one also tells one how to
    check it. (How in the world did you the power off drift to 5 significant
    figures? Even the poser on drift is not that accurate-- it wanders around
    much more than 1PPB (part per billion)



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


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

    On Wed, 9 Apr 2008, Serge Bets wrote:

    > Granted, the eleven-minutes mode is bad. But not *so* bad. It sets the
    > RTC tick in sync with real seconds, with a random error of maximum
    > 7 milliseconds.


    The worst problem with the automatic RTC update happens on some Linux
    platforms that use the RTC periodic interrupt as the source of the system
    timer interrupt. Updating the RTC causes a considerable disruption of the
    interrupt -- the next one after the update is shifted by an amount of time
    corresponding to the offset between the moment the timer interrupt to
    trigger the update happens and the moment the half of a second of calendar
    time falls -- breaking the accuracy of timekeeping badly.

    Of course the same happens on these systems when `hwclock --systohc' is
    called, but that at least can be controlled by the system administrator
    and for example run only on shutdown of the affected systems when the
    rough accuracy is perfectly fine.

    Maciej

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

    "Maciej W. Rozycki" writes:

    >On Wed, 9 Apr 2008, Serge Bets wrote:


    >> Granted, the eleven-minutes mode is bad. But not *so* bad. It sets the
    >> RTC tick in sync with real seconds, with a random error of maximum
    >> 7 milliseconds.


    > The worst problem with the automatic RTC update happens on some Linux
    >platforms that use the RTC periodic interrupt as the source of the system
    >timer interrupt. Updating the RTC causes a considerable disruption of the
    >interrupt -- the next one after the update is shifted by an amount of time
    >corresponding to the offset between the moment the timer interrupt to
    >trigger the update happens and the moment the half of a second of calendar
    >time falls -- breaking the accuracy of timekeeping badly.


    WHAT? What linux platform uses the "1 interrupt per second" of the rtc
    clock as the timer interrupt? (never mind that the latest motherboards do
    not have an rtc at all, and use the HPET in poll mode to mimic an rtc).



    > Of course the same happens on these systems when `hwclock --systohc' is
    >called, but that at least can be controlled by the system administrator
    >and for example run only on shutdown of the affected systems when the
    >rough accuracy is perfectly fine.


    > Maciej


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

    Hello Maciej,

    On Wednesday, April 9, 2008 at 21:19:55 +0100, Maciej W. Rozycki wrote:

    > on some Linux platforms that use the RTC periodic interrupt as the
    > source of the system timer interrupt. Updating the RTC causes a
    > considerable disruption of the interrupt


    I guess this problem is due to the reset of the RTC oscillator, right?
    Then a solution could be to use an alternative method to set the RTC,
    not using reset, but holding the clock during a fraction of second,
    until ticks are in sync. Deliciously hackish, and surely illegal.
    Instead of normal:

    -1) wait for the next real half second
    -2) freeze clock
    -3) reset oscillator
    -4) write time
    -5) release clock
    -6) release oscillator

    Alternatively do:

    -1) wait for an RTC tick
    -2) freeze clock
    -3) write time + 1 second
    -4) wait for the next real second
    -5) release clock

    This holds the clock for up to a second, producing no more update nor
    alarm interrupts. But the oscillator still oscillates, so periodic
    interrupts should be undisturbed, during and after this procedure.
    Interrupts have to be enabled during step #4 of course.

    I'm not aware of any tool using this method. What are those PIE-timer
    platforms? Do you have one?


    Serge.
    --
    Serge point Bets arobase laposte point net

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

    On Wed, 9 Apr 2008, Unruh wrote:

    > WHAT? What linux platform uses the "1 interrupt per second" of the rtc
    > clock as the timer interrupt? (never mind that the latest motherboards do
    > not have an rtc at all, and use the HPET in poll mode to mimic an rtc).


    A number of DEC platforms have their RTC chip (a Dallas 1287A typically)
    as the only source of the timer interrupt. The rate is configurable in
    powers of two between 2Hz and 8192Hz, with 128Hz and 1024Hz being the
    commonest with Linux (and elsewhere). You must be confusing the
    update-ended interrupt (which is indeed 1Hz) here with the periodic
    interrupt which may be set to the desired rate.

    Maciej

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

    On Apr 10, 7:50 am, Serge Bets
    wrote:
    >
    > I'm not aware of any tool using this method. What are those PIE-timer
    > platforms? Do you have one?


    Why not go straight to the horse's mouth at
    http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2680/t/do ?

    HTH

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

    Hello Serge,

    > I guess this problem is due to the reset of the RTC oscillator, right?


    Correct.

    > This holds the clock for up to a second, producing no more update nor
    > alarm interrupts. But the oscillator still oscillates, so periodic
    > interrupts should be undisturbed, during and after this procedure.
    > Interrupts have to be enabled during step #4 of course.


    I am not sure what you mean -- according to the datasheet there is no way
    to prevent the update from being scheduled exactly 500ms after 010 (the
    pattern that enables normal operation of the RTC) has been written to the
    divider configuration bits of Register A and the periodic interrupt is
    synchronised to that as far as I know. The only other patterns that do
    not reset the oscillator are 110 and 111, but they still do reset the
    countdown chain. This is at least with the Dallas DS1287A chip used on
    the affected platforms.

    Besides it would be harmful if the timer tick was held off for a second
    as it is used for process scheduling (and some networking stuff too).

    > I'm not aware of any tool using this method. What are those PIE-timer
    > platforms? Do you have one?


    A number of DEC platforms have the RTC chip as their lone source of
    periodic interrupts available. They include systems based on the VAX,
    MIPS and Alpha processors and I have a number of them (and try to support
    under Linux, time permitting).

    FYI, I had a look at NTP statistics a while ago when I worked on adding
    HPT support for some of these platforms that provide a high-resolution
    free-running counter in the chipset and it turned out these Dallas chips
    (as well as the piece of chipset in question), if left undisturbed by the
    11-minute update, have a pretty darn good precise oscillator. I do not
    remember the exact numbers anymore, but I was quite astonished by the low
    value of dispersion reached.

    Maciej

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

    "Maciej W. Rozycki" writes:

    >On Wed, 9 Apr 2008, Unruh wrote:


    >> WHAT? What linux platform uses the "1 interrupt per second" of the rtc
    >> clock as the timer interrupt? (never mind that the latest motherboards do
    >> not have an rtc at all, and use the HPET in poll mode to mimic an rtc).


    > A number of DEC platforms have their RTC chip (a Dallas 1287A typically)
    >as the only source of the timer interrupt. The rate is configurable in
    >powers of two between 2Hz and 8192Hz, with 128Hz and 1024Hz being the
    >commonest with Linux (and elsewhere). You must be confusing the
    >update-ended interrupt (which is indeed 1Hz) here with the periodic
    >interrupt which may be set to the desired rate.


    OK, if you say so. I am used to the CPU timer being very different from the
    rtc, but I am only used to PCs. It sounds really weird to have the rtc and
    the cpu timer being coupled like that. I would expect the timer to just
    keep going, and not to be dependent on the actual value that one stuck into
    the rtc.

    > Maciej


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

    On Thu, 10 Apr 2008, Unruh wrote:

    > OK, if you say so. I am used to the CPU timer being very different from the
    > rtc, but I am only used to PCs. It sounds really weird to have the rtc and
    > the cpu timer being coupled like that. I would expect the timer to just
    > keep going, and not to be dependent on the actual value that one stuck into
    > the rtc.


    Well, I cannot see a specific reason not to use an RTC as the source of
    the timer interrupt if such a chip has been designed into a system since
    the beginning -- which is the case with these DEC machines. With the IBM
    PC architecture the reason of using the 8253 and later on the 8254 for the
    timer interrupt is certainly historical as an RTC was not included in the
    design before the PC/AT. Therefore some other chip had to be used.

    Another matter is they used the two other channels of the 8253/8254 to
    drive memory refresh and the speaker respectively so the PIT was meant to
    be there already, but if the RTC was available from the beginning, it
    would have probably been the obvious choice for the timer interrupt
    regardless and the remaining channel of the 8253/8254 could have been used
    for something else, such as a watchdog.

    I am told there is a piece of operating system software that uses the RTC
    as the source of the timer interrupt on the PC anyway.

    Maciej

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

    On Thursday, April 10, 2008 at 18:02:38 +0100, Maciej W. Rozycki wrote:

    >> This holds the clock for up to a second

    > I am not sure what you mean


    Anyway I experimented a little: This doesn't seem to work as I hoped.
    And it can even lock the clock, requiring a oscillator reset. :-(

    The idea was about the RTC_SET flag (bit #7 of register B). It suspends
    clock updates, without any effect on the oscillator nor PIE. I was
    hoping it would delay next updates by as long as it was asserted. But
    no: the next update is either skipped, or happens at the usual time.


    Serge.
    --
    Serge point Bets arobase laposte point net

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

    On Wednesday, April 9, 2008 at 18:18:15 +0000, Unruh wrote:

    > But when one is advising someone, one must assume that they have at
    > least the typical if not the worst condition


    That's not false...


    > How in the world did you the power off drift to 5 significant figures?


    With two hwclock --systohc and awk over one real night, from halt to
    soon after restart. I can't guarantee the 3rd decimal, though. Each
    night has its own temperature.


    Serge.
    --
    Serge point Bets arobase laposte point net

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

    On Sat, 12 Apr 2008, Serge Bets wrote:

    > The idea was about the RTC_SET flag (bit #7 of register B). It suspends
    > clock updates, without any effect on the oscillator nor PIE. I was
    > hoping it would delay next updates by as long as it was asserted. But
    > no: the next update is either skipped, or happens at the usual time.


    This bit does not affect the countdown chain, so it does not let you
    modify the time stored with a subsecond resolution, which is required
    here. In other words the next update after this bit has been cleared will
    happen at the very same moment one would if the bit was not set in the
    first place.

    Maciej

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

    Serge,

    Serge Bets wrote:
    > On Thursday, April 10, 2008 at 18:02:38 +0100, Maciej W. Rozycki wrote:
    >
    >>> This holds the clock for up to a second

    >> I am not sure what you mean

    >
    > Anyway I experimented a little: This doesn't seem to work as I hoped.
    > And it can even lock the clock, requiring a oscillator reset. :-(
    >
    > The idea was about the RTC_SET flag (bit #7 of register B). It suspends
    > clock updates, without any effect on the oscillator nor PIE. I was
    > hoping it would delay next updates by as long as it was asserted. But
    > no: the next update is either skipped, or happens at the usual time.


    About 20 years ago I worked with the same same RTC type which was controlled
    by a microcontroller.

    IIRC we changed the clock rate of the counter chain to the highest rate for
    a certain interval in order to compensate the 500 ms offset which was
    introduced when the RTC was set to a new time.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

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

    Noob writes:

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


    So they enhanced the old code (that worked) ;-)

    [...]

    Regards,
    Ulrich

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

    Bill Unruh writes:

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


    What real men actually want is: Independent on how you set the clock, the
    expectation is that after reboot or power cycle the clock is as good as
    possible.

    IMHO the idea to update the RTC during shutdown is broken, because if the
    system crashes, the RTC time may be wrong. Likewise the concept of a user
    program getting the system time from the RTC during boot is broken. The kernel
    needs correct time as early as possible.

    Regards,
    Ulrich

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

    Hello Ulrich,

    On Friday, May 2, 2008 at 16:16:53 +0200, Ulrich Windl wrote:

    > Bill Unruh writes:
    >>>> Real men don't want the eleven-minutes mode.


    The words you attribute to Bill are mine.


    > IMHO the idea to update the RTC during shutdown is broken, because if
    > the system crashes, the RTC time may be wrong.


    The RTC has been good the last time it was written, but has drifted
    since then. Only hwclock can compensate this drift at best. Eleven-mode
    and kernel initialisation alone can't.

    Under normal conditions without crash, the hwclock method clearly wins,
    by very very far. It permits to reboot and stay at some tens of
    microseconds of UTC; halt for the night and stay at some milliseconds...
    Eleven-minutes mode does almost 1000 times less good.

    In case of crash, the hwclock method still wins, though much less
    clearly. It compensates the drift since the previous clean shutdown,
    counting that the RTC drifted at a fixed rate. But the rate really
    can vary. That's why a good evaluation of the rate is so important. And
    that's why an hwclock-in-cron is a good optional addition to
    hwclock-in-shutdown.

    Conclusion: crash or no-crash, with cron or without, instant reboot or
    halt for the night, a well used hwclock always wins.


    > Likewise the concept of a user program getting the system time from
    > the RTC during boot is broken. The kernel needs correct time as early
    > as possible.


    The kernel initialisation already reads the RTC once at startup. Hwclock
    rereads the RTC a little later, in the startup scripts. Hwclock is
    extremely more accurate at that. And hwclock compensates drift; the
    kernel doesn't.

    So what you say is very true. But is not an argument against hwclock;
    It is an argument to call hwclock at the earliest.


    Please note that I'm talking about the latest hwclock 2.32 from BJH,
    whose accuracy has been considerably improved across the years. The
    version forked for util-linux is far behind, somewhere between 200 and
    500 times less good.

    Also note that the eleven-minutes mode and hwclock are incompatible:
    the former perturbates the later. To use hwclock well, you have to
    disable the eleven-minutes mode.


    Serge.
    --
    Serge point Bets arobase laposte point net

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