Hi Jim, 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.
Cheers, Steve 2008/10/2 Jim Palfreyman <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]> > >> 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 <[EMAIL PROTECTED]> 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 -- [email protected] >> > To unsubscribe, go to >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> > and follow the instructions there. >> > >> >> _______________________________________________ >> time-nuts mailing list -- [email protected] >> To unsubscribe, go to >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> > _______________________________________________ > time-nuts mailing list -- [email protected] > 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 _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
