[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