On 2010-04-14, nemo_outis <[email protected]> wrote: > Rob <[email protected]> wrote in > news:[email protected]: > >> nemo_outis <[email protected]> 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. > > Regards, > > _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
