We are losing about 15 seconds per 86400 seconds = 0.0001736. I
suppose that is the error we can expect based on the crystal they are
using and the algorithm to give the system 100 tics per second. My
preference would be to figure out how to patch the kernal to correctly
compensate the system time so that it is the same acuracy as the
crystal, hopefully less than 1 second per day error. Individual
programmers should not have to write non-portable code to keep the
system time correct.
Don.
On 4/18/06, Markus Peuhkuri <> wrote:
>
> Don W. Carr wrote:
> > I don't think the solution is ntp when it is over 15 seconds per day.
> > You use ntp once per day to maintain within 1 second. I like to have a
>
> If you measure the clock skew, you should be able to find out that it is
> constant once our system load and temperature are quite stable.
> The idea is to use ntp to determine the correct cofficient for clock skew.
>
>
>
>
> ________________________________
> 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/
|