[time-nuts] Timing on Ethernet
magnus at rubidium.dyndns.org
Sun Aug 5 17:59:27 EDT 2007
From: "Bill Hawkins" <bill at iaxs.net>
Subject: Re: [time-nuts] Timing on Ethernet
Date: Sun, 5 Aug 2007 16:25:36 -0500
Message-ID: <000a01c7d7a7$2a591560$021ba8c0 at cyrus>
> There are many replies to this thread. I have not read them all,
> but I sense some diversion from the truth.
> Ethernet is inherently imprecise. Once a message is started, it
> runs to completion, taking chunks of time as it goes. This delays
> other messages, such as time.
Yes, but... you missed out the fine-grained point. You can measure each package
with high-grained resolution just like a carrier-phase measure and then
transfer that to the receiver side (on a direct cable-delay only link) where
the same thing was measured and then use that as a basis for a two-way time
transfer link. You can measure any feature you like as long as you get a low
jitter value each time. The trick is to measure at the output of the buffer
rather than the input, so you have stable clock-count delays and cable delays.
If there is a lack of messages, just toss one into the buffer and you have
something to measure. The only thing you need is to be able to push in your
measurements into the stream. There are many methods to acheive that.
There are several systems in the research and commercial world doing more or
less this. The resolution leaves NTP waaaaay beind in the dust.
> NTP by David Mills is the best way to apply statistics to many
> Internet transactions to find the best time transmission.
> SNTP does not use statistics, but does estimate the round trip
> delay, assuming equal out and back delays.
> Broadcast time does not estimate the delay, but assumes that any
> delay is negligible.
> And then there is Mister Softee's time sync, which, at best, may
> be good to the nearest few minutes.
These are ontop of IP. Where are fiddeling around in the physical and link
layers (if you beleive in ISO OSI stacks haha).
> So, if you are using long baseline telescopes, Internet is just
> not suitable. You can't get nanosecond resolution.
Not using the NTP approach, but you missed out that there is other ways to do
it and this is what is happening now.
NTP does a very good job under its conditions, being run ontop of IP. But is is
not sufficient for many applications and this is why other alternativs have
been developed. NTP will still solve problems for other applications, but it is
not the universal solution, neither is IP by the way.
More information about the time-nuts