[ntp:questions] how to have offset < 1ms

unruh unruh at wormhole.physics.ubc.ca
Thu Apr 15 15:13:55 UTC 2010

On 2010-04-15, nemo_outis <abc at xyz.com> wrote:
> unruh <unruh at wormhole.physics.ubc.ca> wrote in
> news:slrnhsd78b.gnt.unruh at wormhole.physics.ubc.ca: 
>> On 2010-04-15, nemo_outis <abc at xyz.com> wrote:
>>> John Hasler <jhasler at newsguy.com> wrote in 
>>> news:874ojdmx12.fsf at thumper.dhh.gt.org:
>>>> 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
Ie, if the ACEB box is itself failing, no network fixing is going to

> 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,

More information about the questions mailing list