[time-nuts] Testing frequency using NTP

[Jim Palfreyman]

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...

Jim


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
> values.
>
> 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
> it.
> >
> > Thanks,
> > Steve
> > --
> > Steve Rooke - ZL3TUV & G8KVD
> > Omnium finis imminet
> >
> > _______________________________________________
> > 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.
> >
>
> _______________________________________________
> 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.
>