On Mon, 17 Apr 2006, Yan Seiner wrote:
> --- In "Don W. Carr" <> wrote:
> >
> > Ok, I am going to check the accuracy of the battery-backed clock
> and
> > the system clock. I have an atomic clock that syncs every night
> and is
> > always within 1 second.
> >
> > If the battery backed clock is more accurate, it might make sense
> for
> > my application to call the following every 24 hours:
> >
> > hwclock --hctosys
> >
>
> Also check into ntpdate or ntpd... ISTR that ntpd can use a local
> clock reference to keep the kernel clock in sync. hwclock is not
> recommended because it causes a big discontinous jump in the system
> clock... While ntpd gently nudges the clock in the right
> direction....
>
> Theory only, I don't have a TC RTC to play with... But I will need
> it, so this is of great interest to me.
>
also check the adjtimex[1] command which can fine tune the linux system
clock. I get about 1 sec per 3 days or better for longterm accuracy in a
fairly stable environment (so temp fluctuations don't affect the crystal).
Jim
[1] this function may not built into the busybox version supplied in the
flash image. I rebuilt busybox to add this and other useful functions
that were missing in the TS busybox build.
For what its worth my time setup uses rdate (another function I added to
my busybox rebuild) to a server that runs ntp sych to reputable sources,
and then sets an adjustment factor to the system clock...
rdate time.wf32df
adjtimex -f 1392566
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/
|