Linux 11-minute mode (RTC update) - NTP

This is a discussion on Linux 11-minute mode (RTC update) - NTP ; Serge Bets writes: > 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 ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 56 of 56

Thread: Linux 11-minute mode (RTC update)

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

    Serge Bets writes:

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


    You'll have to count the '>' characters...

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


    How does hwclock know when the RTC was updated last?

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


    IMHO exchanging systemtime with the RTC by a user-program is broken.

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


    Did you consider that on Multi-Boot systems a different OS might have run that
    also updates the RTC? In these cases hwclock kills the correct time.

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


    hwclock is unnecessary if NTP is used and the kernel handles the RTC properly
    (IMHO).

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


    I may be stupid, but how does hwclock know the drift? Asuming it has exclusive
    ownership of the RTC?

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


    My opinion still is to disable hwclock and fix the kernel. Sorry.

    Regards,
    Ulrich

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

    Hello Ulrich,

    On Friday, May 9, 2008 at 10:21:44 +0200, Ulrich Windl wrote:

    > How does hwclock know when the RTC was updated last? [...] how does
    > hwclock know the drift? Asuming it has exclusive ownership of the RTC?


    Yes. More exactly assuming exclusive write access to both the RTC and
    a small adjtime file, where hwclock records the last setting epoch and
    its estimate of the drift rate.


    > Did you consider that on Multi-Boot systems a different OS might have
    > run that also updates the RTC?


    That's indeed a problem, but not unsolvable. Sometimes it's possible to
    share the adjfile between the different OSes, and then hwclock can work
    nearly as well as on single-boot. Sometimes adjfile sharing poses some
    difficulties, or hwclock just can't run (MS Windows comes to mind). Then
    it's a real problem: drift can't be well corrected.

    But the pure kernel method still doesn't do any better. Halt a Linux-box
    in the evening, multiboot it on Windows next morning: The time at
    startup will also be wrong.


    > IMHO exchanging systemtime with the RTC by a user-program is broken.


    This user-program is 1000 times more accurate in most practical usage
    cases. And not worse even in the most uncomfortable corner cases.


    > hwclock is unnecessary if NTP is used and the kernel handles the RTC
    > properly (IMHO).


    The problem is that the kernel handles the RTC quite poorly. The day
    when kernels will be able to read and write the hardware clock down to
    some microseconds, and manage its drift, you might become right. That's
    not today.


    Serge.
    --
    Serge point Bets arobase laposte point net

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

    Serge Bets writes:

    > Hello Ulrich,
    >
    > On Friday, May 9, 2008 at 10:21:44 +0200, Ulrich Windl wrote:
    >
    >> How does hwclock know when the RTC was updated last? [...] how does
    >> hwclock know the drift? Asuming it has exclusive ownership of the RTC?

    >
    > Yes. More exactly assuming exclusive write access to both the RTC and
    > a small adjtime file, where hwclock records the last setting epoch and
    > its estimate of the drift rate.


    I was talking about ownership: "exclusive write access" for how long? For the
    time of the update? If not, how do you ensure nobody else does update the RTC?

    >
    >
    >> Did you consider that on Multi-Boot systems a different OS might have
    >> run that also updates the RTC?

    >
    > That's indeed a problem, but not unsolvable. Sometimes it's possible to
    > share the adjfile between the different OSes, and then hwclock can work
    > nearly as well as on single-boot. Sometimes adjfile sharing poses some
    > difficulties, or hwclock just can't run (MS Windows comes to mind). Then
    > it's a real problem: drift can't be well corrected.


    In my experience adjtime de-adjusted the clock in more cases severely than id
    did adjust it in a useful way.

    >
    > But the pure kernel method still doesn't do any better. Halt a Linux-box
    > in the evening, multiboot it on Windows next morning: The time at
    > startup will also be wrong.


    Why? The RTC will be the time Windows has set last. Trying to improve the RTC
    without knowing what time it is seems a stupid idea to me.

    >
    >
    >> IMHO exchanging systemtime with the RTC by a user-program is broken.

    >
    > This user-program is 1000 times more accurate in most practical usage
    > cases. And not worse even in the most uncomfortable corner cases.


    Can you explain why a user process has more accurate timing then a kernel task
    in general? It sounds like a strange concept...

    >
    >
    >> hwclock is unnecessary if NTP is used and the kernel handles the RTC
    >> properly (IMHO).

    >
    > The problem is that the kernel handles the RTC quite poorly. The day
    > when kernels will be able to read and write the hardware clock down to
    > some microseconds, and manage its drift, you might become right. That's
    > not today.


    OK, I agree that the update may be wrong up to one timer tick. The easy and
    obvious solution involving busy waiting is a no-no in the kernel. Maybe this
    answers the question above as well.

    Regards,
    Ulrich

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

    Hello Ulrich,

    On Wednesday, July 9, 2008 at 15:53:57 +0200, Ulrich Windl wrote:

    [when hwclock updates the RTC]
    > I was talking about ownership: "exclusive write access" for how long?
    > For the time of the update? If not, how do you ensure nobody else does
    > update the RTC?


    In order to work perfectly, hwclock has to be the only one to ever set
    the RTC, for all of the times long. Nothing enforces that: One can well
    choose to use another utility, activate the kernel eleven-minutes mode,
    or boot Windows. Then hwclock can still work, but in a degraded mode
    where drift correction, beeing impossible, is just disabled. This
    degraded mode is either enabled automatically when possible (rarely),
    or has to be forced via the hwclock --nodrift option.


    [multiboot MS Windows]
    > In my experience adjtime de-adjusted the clock in more cases severely
    > than id did adjust it in a useful way.


    Maybe you didn't use the --nodrift option for the hwclock --hctosys
    invoked during the Linux bootup following Windows. This can indeed
    lead to inappropriately apply a big drift "correction" to a clock that
    was good and had not yet drifted much.

    The interesting question is whether it could be possible to
    automatically boot with --nodrift after a Windows run, but without after
    a Linux run. I suppose that sophisticated boot managers may have
    features helping this, but I never looked closely.


    > The RTC will be the time Windows has set last. Trying to improve the
    > RTC without knowing what time it is seems a stupid idea to me.


    Windows has set the RTC. The RTC then drifts. Hwclock cannot possibly
    correct this drift. There is indeed no point in trying. In this case
    hwclock provides you only its better instant accuracy. The result is not
    perfect, but is optimal in those conditions, and is better than the
    result of the kernel alone.


    > Can you explain why a user process has more accurate timing then a
    > kernel task in general? It sounds like a strange concept...


    I cannot explain in general. But for RTC steering, the difference is
    gigantic, and is rather easy to explain: hwclock does absolutely
    everything for accuracy, at all costs. The kernel doesn't. Hwclock 2.33
    goes quite far for top accuracy:

    - Sets the clock at the exact good moment, intending down to the
    microsecond. At the expense of wallclock time and processor cycles.

    - Evaluates and corrects various machine-dependant constant delays.

    - Does feedback: measures its own write error in order to compensate it
    on-the-fly when reading.

    - Measures its own execution time, and counts it where necessary.

    - And of course there are many cases where the RTC drift can be
    calculated. And then hwclock compensates it.


    >> the kernel handles the RTC quite poorly.

    > OK, I agree that the update may be wrong up to one timer tick.


    Yes: the eleven-minutes mode sets the RTC with an error typically
    anywhere in the range from -7 to +3 milliseconds, at HZ=100.
    Hwclock 2.33 sets the RTC with typically a maximum error of
    10 microseconds, and is able to read it with the same accuracy.


    > The easy and obvious solution involving busy waiting is a no-no in the
    > kernel.


    We agree on that. Note that hwclock doesn't purely busywait until the
    target time: hwclock begins sleeping the biggest part of the delay, then
    busywaits only during the very last milliseconds. Maximum accuracy, but
    not too much processor cycles wasted.


    Serge.
    --
    Serge point Bets arobase laposte point net

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

    Serge Bets writes:

    >Hello Ulrich,


    > On Wednesday, July 9, 2008 at 15:53:57 +0200, Ulrich Windl wrote:


    > [when hwclock updates the RTC]
    >> I was talking about ownership: "exclusive write access" for how long?
    >> For the time of the update? If not, how do you ensure nobody else does
    >> update the RTC?


    >In order to work perfectly, hwclock has to be the only one to ever set
    >the RTC, for all of the times long. Nothing enforces that: One can well
    >choose to use another utility, activate the kernel eleven-minutes mode,
    >or boot Windows. Then hwclock can still work, but in a degraded mode
    >where drift correction, beeing impossible, is just disabled. This
    >degraded mode is either enabled automatically when possible (rarely),
    >or has to be forced via the hwclock --nodrift option.



    > [multiboot MS Windows]
    >> In my experience adjtime de-adjusted the clock in more cases severely
    >> than id did adjust it in a useful way.


    >Maybe you didn't use the --nodrift option for the hwclock --hctosys
    >invoked during the Linux bootup following Windows. This can indeed
    >lead to inappropriately apply a big drift "correction" to a clock that
    >was good and had not yet drifted much.


    >The interesting question is whether it could be possible to
    >automatically boot with --nodrift after a Windows run, but without after
    >a Linux run. I suppose that sophisticated boot managers may have
    >features helping this, but I never looked closely.



    >> The RTC will be the time Windows has set last. Trying to improve the
    >> RTC without knowing what time it is seems a stupid idea to me.


    >Windows has set the RTC. The RTC then drifts. Hwclock cannot possibly
    >correct this drift. There is indeed no point in trying. In this case


    The drift is easy to correct. What is hard to correct is the random jump to
    the time Windows applied to get what it thought was the right time (
    espcially a problem if your linux clock is on utc)

    >hwclock provides you only its better instant accuracy. The result is not
    >perfect, but is optimal in those conditions, and is better than the
    >result of the kernel alone.



    >> Can you explain why a user process has more accurate timing then a
    >> kernel task in general? It sounds like a strange concept...


    >I cannot explain in general. But for RTC steering, the difference is
    >gigantic, and is rather easy to explain: hwclock does absolutely
    >everything for accuracy, at all costs. The kernel doesn't. Hwclock 2.33
    >goes quite far for top accuracy:


    > - Sets the clock at the exact good moment, intending down to the
    >microsecond. At the expense of wallclock time and processor cycles.


    Well, not really. The problem is that most versions of linux these days
    have a badly damaged rtc. The whole hpet thing has thrown the rtc
    timekeeping back to the stone age ( hpet steals all of the rtc interrupts).
    Added to that is the problem that until yesterday, there was a bug in the
    rtc code so that an attept to use the UIE interrupt ( interrupt when the
    rtc turns over the seconds counter) would return immediately rather than on
    the seconds turnover on the first read. Ie, the system would think that it
    was exactly on the second, when it was really at some random time.



    > - Evaluates and corrects various machine-dependant constant delays.


    > - Does feedback: measures its own write error in order to compensate it
    >on-the-fly when reading.


    > - Measures its own execution time, and counts it where necessary.


    > - And of course there are many cases where the RTC drift can be
    >calculated. And then hwclock compensates it.



    >>> the kernel handles the RTC quite poorly.

    >> OK, I agree that the update may be wrong up to one timer tick.


    One timer tick of the rtc is one second.


    >Yes: the eleven-minutes mode sets the RTC with an error typically
    >anywhere in the range from -7 to +3 milliseconds, at HZ=100.
    >Hwclock 2.33 sets the RTC with typically a maximum error of
    >10 microseconds, and is able to read it with the same accuracy.



    >> The easy and obvious solution involving busy waiting is a no-no in the
    >> kernel.


    >We agree on that. Note that hwclock doesn't purely busywait until the
    >target time: hwclock begins sleeping the biggest part of the delay, then
    >busywaits only during the very last milliseconds. Maximum accuracy, but
    >not too much processor cycles wasted.



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


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

    Serge Bets wrote:

    > anywhere in the range from -7 to +3 milliseconds, at HZ=100.
    > Hwclock 2.33 sets the RTC with typically a maximum error of
    > 10 microseconds, and is able to read it with the same accuracy.


    That would only be possible if the RTC's counter was updated on both
    phases of the 32kHz clock, which I rather doubt.

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

    Hello David,

    On Tuesday, July 22, 2008 at 7:45:06 +0100, David Woolley wrote:

    > Serge Bets wrote:
    >> Hwclock 2.33 sets the RTC with typically a maximum error of
    >> 10 microseconds

    > That would only be possible if the RTC's counter was updated on both
    > phases of the 32kHz clock, which I rather doubt.


    Excellent example, Dave! The source 32K crystal period being 30 Ás, you
    point the finger at a real issue. An issue that has been squashed some
    time ago by hwclock's feedback mechanism. Not a problem anymore.

    For simplification, I'll assume everything else is instant and perfect,
    and will neglect RTC restart delay. When we set the RTC, the last crystal
    pulse happened between 0 and 30 Ás ago. Let's pick 18 Ás for the
    example. This last pulse becomes the start of this RTC second, the next
    second will start 32768 pulses later, and so on. Result: the RTC is in
    advance by +18 microseconds. Problem.

    However the feedback mechanism measures this +18 Ás offset, and corrects
    future readouts by -18. Final result: nothing less than perfection. :-)


    Serge.
    --
    Serge point Bets arobase laposte point net

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

    Hello Bill,

    On Monday, July 21, 2008 at 23:30:12 +0000, Unruh wrote:

    [multiboot MS Windows]
    > Serge Bets writes:
    >> Windows has set the RTC. The RTC then drifts. Hwclock cannot possibly
    >> correct this drift.

    > The drift is easy to correct.


    How?? Hwclock has no way to determine when Windows has set the RTC.
    This could be 30 seconds or 4 days ago. The drift rate is known, but not
    the amount of drift accumulated during such unknown period.


    > What is hard to correct is the random jump to the time Windows applied


    Indeed! :-(


    > espcially a problem if your linux clock is on utc


    But I'm not sure there is any sane way to make an RTC on UTC cooperate
    well with Windows. I tried the registry trick about
    HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInfo rmation\RealTimeIsUniversal,
    but got inconsistent results. Worse results than with an RTC on
    localtime, where at least the problems happen *only* twice a year.


    > until yesterday, there was a bug in the [Linux kernel] rtc code so
    > that an attept to use the UIE interrupt ( interrupt when the rtc turns
    > over the seconds counter) would return immediately rather than on the
    > seconds turnover on the first read.


    Wait a minute: I'm aware of several flavours of such early returning
    read(/dev/rtc) driver bug. Hwclock implements a pair of workarounds
    against this. One is a minimal waiting threshold. The other involves
    analysis of the data read(): if the UIE flag 0x80 is lit then it's
    assumed to be a real interrupt. Are those workarounds effective against
    the bug you're talking about?

    I fear not: Usual early returns give data=0, while your report shows
    data=0x190, which is a normal value for one UIE interrupt.


    >> On Wednesday, July 9, 2008 at 15:53:57 +0200, Ulrich Windl wrote:
    >>> OK, I agree that the update may be wrong up to one timer tick.

    > One timer tick of the rtc is one second.


    Well to the contrary: Ulrich was talking about the jiffies of a
    non-tickless kernel (10 ms at HZ=100). His reasoning was right, and
    confirmed by measures.


    Serge.
    --
    Serge point Bets arobase laposte point net

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

    Serge Bets wrote:
    > Hello David,
    >
    > On Tuesday, July 22, 2008 at 7:45:06 +0100, David Woolley wrote:
    >
    >
    >>Serge Bets wrote:
    >>
    >>>Hwclock 2.33 sets the RTC with typically a maximum error of
    >>>10 microseconds

    >>
    >>That would only be possible if the RTC's counter was updated on both
    >>phases of the 32kHz clock, which I rather doubt.

    >
    >
    > Excellent example, Dave! The source 32K crystal period being 30 Ás, you
    > point the finger at a real issue. An issue that has been squashed some
    > time ago by hwclock's feedback mechanism. Not a problem anymore.
    >
    > For simplification, I'll assume everything else is instant and perfect,
    > and will neglect RTC restart delay. When we set the RTC, the last crystal
    > pulse happened between 0 and 30 Ás ago. Let's pick 18 Ás for the
    > example. This last pulse becomes the start of this RTC second, the next
    > second will start 32768 pulses later, and so on. Result: the RTC is in
    > advance by +18 microseconds. Problem.
    >
    > However the feedback mechanism measures this +18 Ás offset, and corrects
    > future readouts by -18. Final result: nothing less than perfection. :-)
    >
    >
    > Serge.


    If you fix the RTC time in the ISR for the "second tick" you have a
    deterministic relation from edge to (update) action.

    IF you take in the same ISR the value of one of the high resolution
    counters you can establish over time a relation between RTC and CPU clocks.
    ( even independent of any external time source )

    Some years ago I did something similar with the DCF77 signal and
    the cpu clock of a data aquisition system. Both informations were
    stored in 10ms Dataframes.

    uwe

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

    Serge Bets writes:

    >Hello Bill,


    > On Monday, July 21, 2008 at 23:30:12 +0000, Unruh wrote:


    > [multiboot MS Windows]
    >> Serge Bets writes:
    >>> Windows has set the RTC. The RTC then drifts. Hwclock cannot possibly
    >>> correct this drift.

    >> The drift is easy to correct.


    >How?? Hwclock has no way to determine when Windows has set the RTC.


    That is not a drift. That is a step function change. It is a change to the
    phase, not the frequency to use ntp language. The drift is the change due
    to the frequency difference. That is easy to correct. The discrete phase
    changes due to Windows are not so easy to correct.

    >This could be 30 seconds or 4 days ago. The drift rate is known, but not
    >the amount of drift accumulated during such unknown period.


    When Windows reset the clock ( assuming that the reset was some reasonably
    small fraction of the total time difference) does not matter in correcting
    the drift.




    >> What is hard to correct is the random jump to the time Windows applied


    >Indeed! :-(



    >> espcially a problem if your linux clock is on utc


    >But I'm not sure there is any sane way to make an RTC on UTC cooperate


    That was what I meant. Windows will simply reset the clock by 9 hours (
    where I am), which is problematic.


    >well with Windows. I tried the registry trick about
    >HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInfo rmation\RealTimeIsUniversal,
    >but got inconsistent results. Worse results than with an RTC on
    >localtime, where at least the problems happen *only* twice a year.



    >> until yesterday, there was a bug in the [Linux kernel] rtc code so
    >> that an attept to use the UIE interrupt ( interrupt when the rtc turns
    >> over the seconds counter) would return immediately rather than on the
    >> seconds turnover on the first read.


    >Wait a minute: I'm aware of several flavours of such early returning
    >read(/dev/rtc) driver bug. Hwclock implements a pair of workarounds
    >against this. One is a minimal waiting threshold. The other involves
    >analysis of the data read(): if the UIE flag 0x80 is lit then it's
    >assumed to be a real interrupt. Are those workarounds effective against
    >the bug you're talking about?


    I do not think so since the UIE flag IS set on that early return.
    The early return results from not clearing old info in the interrupt return
    functions, and perhaps some weird behaviour of the system under hpet
    control.

    On old systems without hpet the returns seems to be fine. On hpet systems,
    they are not.

    Note that sometimes hpet also returns millisec off the right time ( often
    early) for a UIE interrupt return.

    See the code I put into the bugzilla.kernel.org bug report 11112 corrected
    by David Brownell (I did not correct for negative usec in the time
    difference) which you can use to test the read return, and see if it
    misbehaving. It also returns the read() result so you can check the flags.



    >I fear not: Usual early returns give data=0, while your report shows
    >data=0x190, which is a normal value for one UIE interrupt.



    >>> On Wednesday, July 9, 2008 at 15:53:57 +0200, Ulrich Windl wrote:
    >>>> OK, I agree that the update may be wrong up to one timer tick.

    >> One timer tick of the rtc is one second.


    >Well to the contrary: Ulrich was talking about the jiffies of a
    >non-tickless kernel (10 ms at HZ=100). His reasoning was right, and
    >confirmed by measures.



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


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

    Uwe Klein writes:

    >Serge Bets wrote:
    >> Hello David,
    >>
    >> On Tuesday, July 22, 2008 at 7:45:06 +0100, David Woolley wrote:
    >>
    >>
    >>>Serge Bets wrote:
    >>>
    >>>>Hwclock 2.33 sets the RTC with typically a maximum error of
    >>>>10 microseconds
    >>>
    >>>That would only be possible if the RTC's counter was updated on both
    >>>phases of the 32kHz clock, which I rather doubt.

    >>
    >>
    >> Excellent example, Dave! The source 32K crystal period being 30 Ás, you
    >> point the finger at a real issue. An issue that has been squashed some
    >> time ago by hwclock's feedback mechanism. Not a problem anymore.
    >>
    >> For simplification, I'll assume everything else is instant and perfect,
    >> and will neglect RTC restart delay. When we set the RTC, the last crystal
    >> pulse happened between 0 and 30 Ás ago. Let's pick 18 Ás for the
    >> example. This last pulse becomes the start of this RTC second, the next
    >> second will start 32768 pulses later, and so on. Result: the RTC is in
    >> advance by +18 microseconds. Problem.
    >>
    >> However the feedback mechanism measures this +18 Ás offset, and corrects
    >> future readouts by -18. Final result: nothing less than perfection. :-)
    >>
    >>
    >> Serge.


    >If you fix the RTC time in the ISR for the "second tick" you have a
    >deterministic relation from edge to (update) action.



    It seems that things are even worse than I suspected with the Linux kernel
    and the machines which have HPET. Apparently the HPET disables the rtc
    interrupts and takes them over. But it operates on a 64 Hz clock and only
    interrupts on that clock tick. Ie, the interrupt from the rtc is likely to
    out by many msec from the true turnover of the rtc clock (This is according
    to Dave Burnel the rtc-cmos maintainer). But worse than that the HPET rtc
    can get itself into a totally horrible state, where the interrupts are way
    out ( 50-500ms)

    No amount of care in the hwclock program can get around this kind of
    nonesense.

    See kernel bug 11153.

    It seems that if you have any desire to have good time, use the
    nohpet
    option to the kernel.


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

    On Tuesday, July 22, 2008 at 20:33:59 +0000, Unruh wrote:

    > The drift is the change due to the frequency difference. That is easy
    > to correct.


    Again: how?


    > When Windows reset the clock ( assuming that the reset was some
    > reasonably small fraction of the total time difference) does not
    > matter in correcting the drift.


    Of course it matters. The epoch at which the RTC was last written is the
    point of origin of drift. To calculate the drift, you need to know its
    rate, and its point of origin. In ntp terms, the drift rate is the
    frequency. A frequency that is both wrong and not adjustable. This
    produces a constantly growing offset. During readouts you can only
    calculate the offset then reached, and compensate it.

    The fact that Windows writes the RTC rather poorly is another problem.
    Problem also hard to solve. Fortunately the error is rarely greater than
    1/3 of a second, and is not constantly growing.


    > Windows will simply reset the clock by 9 hours ( where I am), which is
    > problematic.


    Windows will probably not warp so an RTC on localtime, this being the
    recommended setting.


    [/dev/rtc interrupt]
    >> Are those workarounds effective against the bug you're talking about?

    > I do not think so since the UIE flag IS set on that early return.


    So that's really annoying. I can imagine no other reasonable workaround.
    Reading 2 update interrupts and trusting only the second one is not a
    good solution, because it will cost one full second to innocent people.
    We can be grateful that you reported this bug and got it to be fixed
    right in the Linux kernel. Much thanks to you, Bill! :-)


    Serge.
    --
    Serge point Bets arobase laposte point net

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

    On Thursday, July 24, 2008 at 1:48:40 +0000, Bill Unruh wrote:

    > Apparently the HPET disables the rtc interrupts and takes them over.


    Those HPET emulated RTC interrupts indeed seem to be nothing else than
    unusable rubbish, by design. They introduce an unacceptable level of
    error in the measures. Error 4 orders of magnitude greater than what's
    reasonably expectable from proper RTC interrupts.


    > No amount of care in the hwclock program can get around this kind of
    > nonesense.


    Exactly. Disabling HPET seems the only solution to have proper RTC
    interrupts. Alternatively tell hwclock to *not* use interrupts, via
    either the --directisa or --nointerrupt options. This is less elegant,
    and costs many processor cycles. But accuracy should be good.


    Serge.
    --
    Serge point Bets arobase laposte point net

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

    Serge Bets writes:

    > On Thursday, July 24, 2008 at 1:48:40 +0000, Bill Unruh wrote:


    >> Apparently the HPET disables the rtc interrupts and takes them over.


    >Those HPET emulated RTC interrupts indeed seem to be nothing else than
    >unusable rubbish, by design. They introduce an unacceptable level of
    >error in the measures. Error 4 orders of magnitude greater than what's
    >reasonably expectable from proper RTC interrupts.


    The problem is a balance between uacceptable number of interrupts vs
    accuracy. Having100KHz interrupt rate just to impliment UIE would be
    unacceptable.



    >> No amount of care in the hwclock program can get around this kind of
    >> nonesense.


    >Exactly. Disabling HPET seems the only solution to have proper RTC
    >interrupts. Alternatively tell hwclock to *not* use interrupts, via
    >either the --directisa or --nointerrupt options. This is less elegant,
    >and costs many processor cycles. But accuracy should be good.



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


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

    Serge Bets writes:

    > On Thursday, July 24, 2008 at 1:48:40 +0000, Bill Unruh wrote:


    >> Apparently the HPET disables the rtc interrupts and takes them over.


    >Those HPET emulated RTC interrupts indeed seem to be nothing else than
    >unusable rubbish, by design. They introduce an unacceptable level of
    >error in the measures. Error 4 orders of magnitude greater than what's
    >reasonably expectable from proper RTC interrupts.


    Three orders. (avg 8ms vs about 20usec) but yes, that is pretty terrible.




    >> No amount of care in the hwclock program can get around this kind of
    >> nonesense.


    >Exactly. Disabling HPET seems the only solution to have proper RTC
    >interrupts. Alternatively tell hwclock to *not* use interrupts, via
    >either the --directisa or --nointerrupt options. This is less elegant,
    >and costs many processor cycles. But accuracy should be good.



    Reading the HPET spec and the hpet.c code in the kernel it would seem to me
    that you could disable the legacy behaviour while keeping the hpet for high
    speed timing/cpu clock/tickless operation.


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


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

    On Thursday, July 24, 2008 at 18:51:03 +0000, Unruh wrote:

    > Three orders. (avg 8ms vs about 20usec) but yes, that is pretty
    > terrible.


    How do you count 20 Ás of average error in timestamping an RTC update
    interrupt? This seems quite high to me. A quick statistical check here
    gave me 3.3 Ás on my old and slow machine, and I naively imagined that
    a modern machine like yours can only do better.


    > Reading the HPET spec and the hpet.c code in the kernel it would seem
    > to me that you could disable the legacy behaviour while keeping the
    > hpet for high speed timing/cpu clock/tickless operation.


    Then HPET and RTC would probably both work fine. However those who know
    seem to say that this would be very difficult or impossible to do
    uniformly on all concerned motherboards. :-(


    Serge.
    --
    Serge point Bets arobase laposte point net

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