[time-nuts] An embedded NTP server
Hal Murray
hmurray at megapathdsl.net
Thu Dec 27 09:36:36 UTC 2012
albertson.chris at gmail.com 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.
More information about the time-nuts
mailing list