[time-nuts] Low-long-term-drift clock for board level integration?
paulswedb at gmail.com
Tue Feb 21 01:44:37 UTC 2012
Even if the path is mapped the ques in the switches can change. Say your
packet is first and the next trip its the 50th. Just depends on the overall
This has been tried many times and there is the ability to get a feel on
the timing. But not like GPS.
On Mon, Feb 20, 2012 at 8:40 PM, Chris Albertson
<albertson.chris at gmail.com>wrote:
> On Mon, Feb 20, 2012 at 12:13 PM, Brooke Clarke <brooke at pacific.net>
> > You may be able to do a similar thing in your receivers. For example if
> > 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
> > 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
> > using simple math. You can trade the receiver clock stability for the
> > 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
> Chris Albertson
> Redondo Beach, California
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> and follow the instructions there.
More information about the time-nuts