I have been reading the documentation for hwclock, and the 11 minute
mode (turned on automatically by ntpd) which updates the system clock
from the hardware clock every 11 minutes. Also, you can call hwclock
--adjust, for example from cron to periodically adjust for know drift.
It even calculates the drift for you automatically based on the times
of the last two times you called hwclock --set. I would imagine with a
few tricks, you could create a how-to that would allow a person to
achieve even 1 second per week with small temperature swings, in the
absense of ntp. They would have to have a know good time source and
call hwclock --set a week apart to set the drift, then hwclock
--adjust from cron, and finally, adjtimex to smoothly adjust the
system clock at the same time.
Also, I assume the resolution of gettimeofday() can also be fixed to
do the interpolation trick. That would reduce the complexity of my
code and at the same time eliminate hardware specific code.
Don.
On 4/18/06, Jesse Off <> wrote:
>
> > This time next year I expect gettimeofday() to work as we
> > would like it, and I expect the system time to be at least as
> accurate
> > as the crystal, hopefully, typically less than 1 second drift per day
> > at room temperature, maximum 2 seconds.
>
> I just wanted to warn you that this probably won't be any different in
> a year on the default flash load, despite what you may expect. We may
> however have a new product based on another CPU in a year that doesn't
> exhibit this behavior.
>
> These boards have already been released and this issue with Linux has
> been known for well over a year already. Moving the tick rate from
> something other than 100Hz is not something casually changed. There
> are too many people with products in the field for us to change this
> now-- this isn't a simple "bugfix"-- its an unfortunate side effect of
> the Linux design as it applys to this processor.
>
> While changing the clock to 64Hz may please you in the short term, it
> could possibly affect other people's designs by exposing latent race
> conditions or other serious bugs since the timing of all process'
> would be subtly affected. You probably would best either 1) lobby the
> developers doing Linux 2.6 for a fix and be prepared to update boards
> manually to 2.6, or 2) change the 2.4 (or pay someone to change) 100HZ
> clock to 64Hz yourself, or 3) use a different operating system than
> Linux that does not have this issue.
>
> //Jesse Off
>
>
>
>
>
>
>
> ________________________________
> YAHOO! GROUPS LINKS
>
>
> Visit your group "ts-7000" on the web.
>
> To unsubscribe from this group, send an email to:
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
> ________________________________
>
--
Dr. Don W. Carr
J. G. Montenegro 2258
Guadalajara, Mexico
+52-333-630-0704
+52-333-836-4500 ext 2930
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|