[ntp:questions] how to have offset < 1ms
Richard B. Gilbert
rgilbert88 at comcast.net
Wed Apr 14 23:14:21 UTC 2010
> 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.
More information about the questions