On 2010-04-15, nemo_outis <[email protected]> wrote: > unruh <[email protected]> wrote in > news:[email protected]: > >> On 2010-04-15, nemo_outis <[email protected]> wrote: >>> John Hasler <[email protected]> wrote in >>> news:[email protected]: >>> >>>> Richard B. Gilbert writes: >>>>> One possible solution is using radio controlled clocks. I have a >>>>> wristwatch that uses a radio signal to correct itself. I also have >>>>> a wall clock that does the same. Both work very well. >>>> >>>> They won't work very well inside a steel ship or far out to sea. >>>> They use VLF (60kHz/77kHz) signals that only propagate a thousand >>>> miles or so and not at all through steel. >>>> >>>> In any case it is clear that the ACEB box can provide the >>>> performance he needs if he can only communicate with it. He has a >>>> networking problem, not a timekeeping problem. >>> >>> >>> Spot on! >>> >>> Regards, >>> >>> PS Which means we can now dispense with much of the speculation >>> regarding GPS and its putative implementation, howsoever configured. >> >> Not clear what you thought was spot on. Radio control is not GPS. It >> is true that the equipment ( at a cost of maybe a 1000 times that of >> GPS) can keep time, but so far the evidence is that it is useless as >> it cannot actually report that time at all accurately. Whether it is >> network, or the actual ntp card in the box we do not know ( the pings >> indicate it is not a network problem) Again, putting a laptop on the >> same network as the box, and doing a tcpdump on the ntp packets could >> tell you if the delay is in the network or in the box. (If t3-t2 is >> 29ms, it is in the box. If t3-t2 is 1usec, it is in the network) >> >>> >> > > IMHO (although I'm not all that H :-) what was spot on was the > observation that the OP had a networking problem, not a timekeeping > problem. > > If the ACEB box is performing to spec the OP has no need for GPS or radio > as a timekeeping source (although those might well improve his > timekeeping, I provisionally accept his lax criterion that the single- > source ACEB box is "good enough" for his purposes). Accordingly, his > core problem is distributing that ACEB signal (or one derived from it) - > a network problem.
No, it may be a network problem, it may be a problem with the box. IF for example the machine itself is causing the 29ms delay, it is not a network problem. The evidence from the pings is that there is no network problem. Now it may be that something ( the switch?) is inserting a delay just for ntp packets, but before resorting to paranoia, other options should perhaps be examined. Attaching a switch to the line running to the box, and running tcpdump on another port of that could give info as to the packets that are coming in and going out. doing the same in front of the computer whose time is being controlled could give additional info. 29ms is a LONG LONG time. Ie, if the ACEB box is itself failing, no network fixing is going to help. > > Now, as you discuss above, resolving that network problem may require > some detective work to discern whether the network problem originates in > the ACEB box's NIC, the switch, or elsewhere. Those investigations and > their outcome will depend on the available tools and other resources, not > least of which is the OP's insight (or lack thereof). If the trouble is > found, workarounds may be possible (e.g., replace the NIC, bypass the > switch with a direct connection, etc.). Agreed. (Note that now that we have a much better idea of what the actual situation is and the setup is, much more directed advice can be given. It is now not at all clear why the 1ms requirement was there for only the beginning of the voyage however. Is the ACEB box brought on board in dock only and then removed? If so stringing a GPS out the porthole would probably have been a far cheaper alternative. Is it there permanantly? Etc. > > Regards, _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
