[time-nuts] Testing frequency using NTP
sar10538 at gmail.com
Thu Oct 2 01:39:40 EDT 2008
That's exactly what I was thinking too. Indeed, if I had a decent freq
std I'd use that to measure my oxco. Guess I'm just bouncing ideas
around here and looking for any input.
2008/10/2 Jim Palfreyman <jim77742 at gmail.com>:
> But wouldn't, over time, all this ntp/OS/network "noise" average away
> because ultimately the whole system is being locked to an atomic clock? I
> know any given measurement will have errors in the order of milliseconds,
> but the long term average ought to be good. Ought it?
> You could test it by giving the linux box the 1PPS from a Thunderbolt
> (instead of your OCXO) and seeing what the results are with time.
> But I suppose you don't have one of those otherwise you'd use it to measure
> your OCXO...
> 2008/10/2 Scott McGrath <scmcgrath at gmail.com>
>> It depends on how accurately you want to measure the oscillator
>> frequency with your approach short term you probably would not be able
>> to measure the oscillator offset any better than a few parts in 10-5
>> longer term probably a few parts in 10-7 might be possible as you
>> could compute the allen deviation and fit a curve through the median
>> NTP from a stratum 3 clock is only going to be precise to a few
>> milliseconds and for meaningful accuracy you need another order of
>> magnitude. This is part of the function of the drift file in xntpd
>> in which the daemon attempts to compensate for the drift and offset
>> inherent in cheap oscillators used in computer applications.
>> - Fellow nuts am I all wet here or have I missed a technique
>> On Wed, Oct 1, 2008 at 8:07 PM, Steve Rooke <sar10538 at gmail.com> wrote:
>> > I'm wondering about the possibility of checking the frequency of my
>> > oscillator by using a NTP synced RT Linux system. What I'm thinking of
>> > doing is building a long chain of dividers feeding a standard freq
>> > counter in totallise mode such that I can count the number of cycled
>> > over a long time period. What I would then do is to gate this with the
>> > Linux system to measure the number of cycles over that period. I
>> > figure that although the exact point of gate switching would not be
>> > very accurate, due to clock jitter and uncertain delays in the OS,
>> > this error could be made insignificant, in terms of the possible
>> > stability of the oxco, when the sampling period is large. Even
>> > watching the NTP stats on my workstation, OpenSUSE 11, it seems to
>> > remain stable within a few ms, now that it has been stabilised for
>> > months, and on a dedicated real time Linux system I should be able to
>> > switch the gate within ms of the correct time so these errors should
>> > only affect the least significant bits of the counting chain. If I
>> > make the sampling period long, say hours, this should push those
>> > errors well down the ppm.
>> > Anyone have comments on this approach please? Feel free to blow holes in
>> > Thanks,
>> > Steve
>> > --
>> > Steve Rooke - ZL3TUV & G8KVD
>> > Omnium finis imminet
>> > _______________________________________________
>> > time-nuts mailing list -- time-nuts at febo.com
>> > To unsubscribe, go to
>> > and follow the instructions there.
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to
>> and follow the instructions there.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
Steve Rooke - ZL3TUV & G8KVD
Omnium finis imminet
More information about the time-nuts