[time-nuts] Low-long-term-drift clock for board level integration?
lists at rtty.us
Tue Feb 21 02:11:41 UTC 2012
Even on good networks, getting below 1 ms with NTP is problematic. Yes indeed I have a heard of servers that will go below one us on a local LAN. That all breaks down pretty fast ( like under a dozen hops ) once you are on the Internet. 10 to 100 us is only going to work on NTP with local nets and symmetric routing.
On Feb 20, 2012, at 8:44 PM, paul swed <paulswedb at gmail.com> wrote:
> 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
> network loading.
> 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.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
More information about the time-nuts