[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