); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] RETRY Magnus Danielson wrote: > ); SAEximRunCond expanded to false > Errors-To: [EMAIL PROTECTED] RETRY > > From: "Bill Hawkins" <[EMAIL PROTECTED]> > Subject: Re: [time-nuts] Timing on Ethernet > Date: Sun, 5 Aug 2007 16:25:36 -0500 > Message-ID: <[EMAIL PROTECTED]> > > >> 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. > > Cheers, > Magnus > Hej Magnus
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. Bruce _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
