[ntp:questions] how to have offset < 1ms
unruh at wormhole.physics.ubc.ca
Wed Apr 14 23:39:31 UTC 2010
On 2010-04-14, nemo_outis <abc at xyz.com> wrote:
> Rob <nomail at example.com> wrote in
> news:slrnhsc00l.l0m.nomail at xs8.xs4all.nl:
>> nemo_outis <abc at xyz.com> wrote:
>>> True, one can chase any number of will-o-the-wisps such as the causes
>>> of the network latency and asymmetry, but that is not the central
>>> problem posed by the OP.
>> But it is!
>>> In short, Unruh may be boring in his reiteration of his simple GPS
>>> solution, but that is because it works for a very wide range of
>>> problems - including this one!
>> No, not at all. The poster wants to be within 1ms of his chosen
>> reference clock, and syncing to GPS is bringing nothing towards that.
> First, the OP isn't going to synchronize anything with anything to 1 ms
> given the high and irregular latencies on his network. In short, he doesn't
> have a time problem, he has a network problem.
> Second, it is true that the OP presented his problem as merely keeping
> Lamport time linked to an arbitrary shipboard server (ntpgmtaceb) of
> unknown stability and accuracy - a task which is presently unachievable and
> may ultimately be of limited utility. But, of course, it's up to the OP to
> decide if such a makeshift approach encapsulating what may be charitably
> called ntp "worst practices" is "good enough."
It is not at all clear to me that ntpgmtaceb is a shipboard machine. My
impression was that it was a land based machine to which he wanted to
sync his shipboard based system when the ship was in dock.
But it is certainly true that the network problems are severe, more so
because the ping results show a roundtrip time of 1/2ms, rather than
30ms. He might want to use tcpdump to capture some of the ntp packets
and read the time stamps to see whether the problem is outbound or
inbound, or both.
I have found weird assymmetric trips between machines here, where the
normal roundtrip time is 140usec, some of my systems have an bimodal of
140usec, and 800usec, and some up to 20ms. This is on a GB network all
within one building. I have treid to get the network people to look at
it, and they c annot find anything wrong.
> However, it would be irresponsible for Unruh and others here not to point
> out that a much better timekeeping solution is readily available - a
> solution which is technically easy to implement.
> Unruh has rightly pointed out that installing a GPS sensor would be clearly
> better than the current ludicrous 18th century policy of setting the master
> clock at voyage outset and then earnestly hoping that subsequent drift (or
> other timekeeping irregularities) is not "too bad." That the OP may not
> be able or willing to implement such a straightforward solution (whether
> from his lack of stroke or his superiors' indifference) does not invalidate
> the suggestion.
> Moreover, that you find Unruh's pointing out the elephant in the room
> tiresome only indicts your judgment, not his.
More information about the questions