On 2010-04-14, Richard B. Gilbert <[email protected]> wrote: > nemo_outis wrote: >> Rick Jones <[email protected]> wrote in news:hq59ef$1p1$1 >> @usenet01.boi.hp.com: >> >>> nemo_outis <[email protected]> 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.
Not on the ms level (that is only 200 miles to the transmitter.) > _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
