Jim Cromie wrote:
Richard B. Gilbert wrote:
thanks Richard
Jim Cromie wrote:
<snip>
Let me re-explain what Im after.
I could shutdown ntpd, and let the hardware timer free-run.
Id expect the frequency to go its natural way, so without the correction
under lock,
it would end up with a different time, and I could compute PPM error
from the duration and the diff.
Ntpd already does exactly that. Do you think you could somehow do it
better?
Ive told the clocksource driver that the hardware is a hires timer at
1.000000 Mhz, which is
somewhat inaccurate. I want to add/subtract some tiny amt so that when
the free-running
hardware timer, driven by a crystal, rolls over, its treated as
X+epsilon nanoseconds,
not just X
Id rather not wait 12 hrs to get a reasonably accurate number,
so Id like to take some number (the 'correction') from ntpd itself and
compute the free-run freq
from it. One of the numbers in the ntpd state represents the frequency
correction.
What leads you to believe that the correction is a constant? The
oscillator frequency varies with the temperature, the age of the
crystal, and perhaps other things as well. If the correction were a
constant, nobody would bother to run ntpd; they would just measure the
clock drift, compute the correction and apply it.
Nothing you have said here tells me how you are going to get the number
of nanoseconds to add to "correct" the rollover time of your crystal
clock! You haven't shown anything that will measure nanoseconds!!
Each "tick" of your 1.000000 MHz oscillator is 1000 nanoseconds!!!
Ntpd, with a GPS Timing Receiver as a reference can come close to
microsecond accuracy. The GPS, itself, only guarantees that the leading
edge of it's Pulse Per Second (PPS) output is within +/- 50 nanoseconds
of the top of the second.
Either I totally misunderstand the what and how of what you are trying
to do, or you do!
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
