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

nemo_outis abc at xyz.com
Wed Apr 14 21:35:30 UTC 2010


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,




More information about the questions mailing list