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

unruh unruh at wormhole.physics.ubc.ca
Wed Apr 14 23:48:37 UTC 2010


On 2010-04-14, Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
> nemo_outis wrote:
>> Rick Jones <rick.jones2 at hp.com> wrote in news:hq59ef$1p1$1
>> @usenet01.boi.hp.com:
>> 
>>> nemo_outis <abc at xyz.com> wrote:
>>>> 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.
>>> Slapping a GPS onto a system on land in a "radio transparant"
>>> structure may indeed be technically easy, but is the *solution* here
>>> easy?  How many decks down is this client?  How far below decks will
>>> the GPS signal penetrate?  How many water-tight bulkheads must be
>>> traversed to get from the antena to the client?  Is there any free
>>> space in the existing through-holes the network traverses? Will any of
>>> the other things traversing the through holes along with the network
>>> cable(s) interfere with the single traversing the antenna cable to be
>>> added? Presumably we cannot trust the network here, which means
>>> getting GPS signals to the client.
>>>
>>> rick jones
>>>
>>> One wonders if that might relate to some of the network problems -
>>> interference with the network cables - so checking link-layer stats on
>>> the client, the switch etc would be goodness.
>>>
>> 
>> 
>> I'll turn aside from my original purpose, bashing Rob for his affected 
>> ennui at Unruh's GPS suggestion, to consider your much more reasoned 
>> points. But first a prefatory divagation :-)
>> 
>> It is frequently the case that OPs (for a variety of reasons) misstate or 
>> mispecify their problem or overconstrain its solution (either in terms of 
>> what can or must be done or what can't or mustn't).  I submit that the 
>> current OP is a classic case.
>> 
>> In a nutshell: The OP has stated that he can't implement a GPS sensor 
>> solution.  (His dismissal of this is a terse, "That's our policy. I can't 
>> decide for that.")  On the other hand, there appears to be an emerging 
>> consensus on this newgroup that network problems associated with variable 
>> and irregular latency would vitiate any timekeeping solution (to the 1 ms 
>> level) and that the network problems must be addressed first.
>> 
>> Now I invite you to consider this: Given the lack of stroke of the OP 
>> and/or the recalcitrance of the ship's management, what is the likelihood 
>> that, having rejected something as simple as using a GPS receiver (which 
>> is likely *already* available on any modern oceanographic ship) that they 
>> would approve the OP's "dicking" with the network, a process which is far 
>> more likely to be disruptive?  While anything is possible, the likelihood 
>> is that a ship's management that won't let the OP use GPS won't let him 
>> mess with the network (or install a substitute network).  And, if that is 
>> the case, the OP is - to use a technical term - fucked.
>> 
>> Now, turning to your points above, could there be technical problems with 
>> implementing GPS?  Yep, just as you point out. 
>> 
>> Well, no, not exactly as you point out.  For the (potential) problems you 
>> point out (and we're both speculating here) have little to do with using 
>> a GPS sensor, per se, but rather with cobbling up a *separate and 
>> independent network* for transmission and propagation of the GPS signals 
>> within/through the ship.  Once again we're back to network problems, not 
>> GPS/timekeeping ones.
>> 
>> Regards,
>
> 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.

Not on the ms level (that is only 200 miles to the transmitter.)


>




More information about the questions mailing list