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

Richard B. Gilbert rgilbert88 at comcast.net
Wed Apr 14 23:14:21 UTC 2010


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.




More information about the questions mailing list