Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Nov 1995 18:23:37 +1100
From:      Bruce Evans <bde@zeta.org.au>
To:        gibbs@freefall.freebsd.org, wollman@lcs.mit.edu
Cc:        current@FreeBSD.org, wollman@FreeBSD.org
Subject:   Re: Time problems
Message-ID:  <199511010723.SAA20983@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>Can we do occasional 8254 based sanity checking of the system time to
>either automatically revert to the 8254 on systems that the new code
>yields poor results, or simply to fix up the time occasionally?  I

Reverting to the 8254 early is easy.  Simply don't set pentium_mhz if
the error for truncating to an int would be too large.  Reverting to
it later and keeping the clocks in sync is harder.  There is no way
to tell which of the the 8254 clock and the Pentium clock has drifted
without comparing them both with a external time source, and if you
have such a time source then it should be possible to use it to keep
the Pentium clock in sync.  The 8254 maximum count and pentium_mhz
should be varied to reduce adjustments.

>>a bit hard to diagnose.  For those machines on which the results are
>>reasonable, I expect timekeeping to be rather better than it was.
>>According to xntpd, my machine is within about 3 seconds per day,
>>which is about the same as it was before.  (It's the precision, rather
>>than the accuracy, where this technique gives a benefit.)
>>
>>-GAWollman

>Precision and overhead right?  Why is it that xntpd doesn't either
>complain about my large offset (I started it just after using ntpdate),
>or keep my time in sync?

Perhaps because of the microtime() jitter that I reported in previous
mail - if the accuracy is low then the jitter becomes large when adjtime()
is used to improved the accuracy.  However, I guess xntpd should be
able to handle large jitter.

I confused precision and accuracy a bit in my previous mail.  It isn't
true that the Pentium clock gives more precision in the current
implementation.  If both clocks have _no_ drift but large inaccuracy,
then the precision is proportional by the the inverse of the factor
used to convert from a cycle count to a time.  For the 8254 clock,
the factor is 11932 and for the Pentium clock it is 90.  Thus the
Pentium clock is about 132 times less precise than the 8254 clock
unless someone made a point of making the Pentium clock frequency
an integral number of MHz.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511010723.SAA20983>