In message <[EMAIL PROTECTED]>, "Tom Van Baak" writes: >Drift rate specifications can be made per day or month >or year. These are not specs of how the oscillator must >perform or will perform; they are often guaranteed limits >on how bad the oscillator will perform. > >You can measure the actual daily drift rate by taking >a month of data and dividing by 30. But if you do this >my guess is you will be amazed how much the daily >drift rate varies from day to day, or hour to hour.
I can confirm this. For a set of NTP servers I constructed I were lucky that ISOTemp allowed me to piggyback an order for 10 OCXO's to another customers order which had specs I could use. The best of these ten OCXO's I received is just about stunning when it comes to drift: there is none. The "worst" has changed sign on the drift five times in one year, twice in sharp corners and three times in soft parabolas. The two sharp corners _may_ correspond to mechanical vibrations from work in the next rack over. All ten are firmly inside spec (but since the spec is -40 - +70 C and my devices run at A/C temps, that doesn't really say much). At this point in time I view the frequency drift estimate as merely an interesting distraction, it does not contribute to the quality of the timekeeping at all. For drift compensation to make sense you have to have totally eliminated environmentals (temp/vibration/air pressure) and have extended hold-over periods before it will help your timekeeping. I think in the past it made more sense, frequency drift is one of the parameters which have been improved a lot in recent years. With a larger drift value than what I'm seeing, things would come out differently. For an insteresting case of drift compensation, I belive that the RAFS-III used in GPS sats these days are steered with a theoretical aging model which takes lamp darkening into account. The reason this works is that there are no environmentals up there at all. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ time-nuts mailing list [email protected] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
