[time-nuts] Timing on Ethernet
Dr Bruce Griffiths
bruce.griffiths at xtra.co.nz
Sun Aug 5 23:04:48 EDT 2007
Magnus Danielson wrote:
> ); SAEximRunCond expanded to false
> Errors-To: time-nuts-bounces+bruce.griffiths=xtra.co.nz at febo.com RETRY
> 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.
One could always make use of the 2 spare pairs on a 100Mbit/s connection.
Its not that much more difficult to build a custom interface using these
than one doing precision timing on the receiver outputs.
More information about the time-nuts