[ntp:questions] how to have offset < 1ms
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
>>> 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.
> 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