[time-nuts] Low-long-term-drift clock for board level integration?

Chris Albertson albertson.chris at gmail.com
Tue Feb 21 01:40:12 UTC 2012


On Mon, Feb 20, 2012 at 12:13 PM, Brooke Clarke <brooke at pacific.net> wrote:

> You may be able to do a similar thing in your receivers.  For example if the
> master node were to send a timing message at known times (say once at the
> top of  every hour) the receivers could use that to determine their local
> clock offset and rate for those cases where the path was the same (or maybe
> even for a list of paths).  The offset and rate numbers can be used to
> correct the measured time to actual time without changing the clock's rate
> using simple math.  You can trade the receiver clock stability for the time
> between the timing messages.


So you are suggesting a very simplified version of NTP.  I doubt you'd
do better than using real-NTP.
It turns out the method works at the millisecond level but not at the
uSec level unless "everyone" is on the same local Ethernet

There is one way to improve timing but it only works if you have
control of all the network equipment.   This means it can't work on
the Internet but it can work on some large networks.  Use "PTP".
This is a little like NTP in that it uses a network for time
distribution but has a slightly different method.   Unlike NTP, for
PTP you need special routers and switches built to support PTP but
then PTP can support uSecond level timing over a wide area and NTP
mostly can't
http://en.wikipedia.org/wiki/Precision_Time_Protocol

Chris Albertson
Redondo Beach, California



More information about the time-nuts mailing list