[email protected] said: > The VXCO quality hardly matters for an NTP server. As long as it does not > gain out loose more then 1 uSecond per second. In other words one part per > million is fine for NTP. The goal is not to produce a 10MHz GDPDO. Clients > using this server over the Ethernet are happy to keep time ti 1 millisecond.
This is time nuts. It's always fair game to discuss how good things are and/or how to make them better. :) The reference NTP package goes to a lot of work to figure out how far off the clock is and tell the kernel so it can keep (much) better time. In many systems, that's a pretty good thermometer. Another thing the reference package tries to do is stretch out the polling interval to minimize load on the network and servers. It's trying to find the bottom of the ADEV curve. The default range is 64-1024 seconds. It keeps track of it on disk to PPB. That doesn't work very well if the temperature/frequency isn't stable. The temperature swing with load change has probably gotten worse with newer machines. It would be interesting to see what ntpd would do on a system with a very good clock and/or what you could do to the code/heuristics to take advantage of a stable clock. > Most (almost all) NTP servers use a TTL can oscillator. Are you sure? Or what's the current practice? A while ago (several/many years?) it was common for Intel boxes to have a clock generator chip. They ran off the standard 14.xxx MHz crystal and generated clocks for the CPU, PCI, USB, ... It usually included the spread spectrum hack. The ARM SOC chips I've worked with had similar stuff on chip. You connect up a crystal. It has an amplifier to make an oscillator and PLLs to make whatever clocks are needed. -- These are my opinions. I hate spam. _______________________________________________ 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.
