|
|
Posted by Unruh on 07/03/07 02:33
ibuprofin@painkiller.example.tld (Moe Trin) writes:
>On Mon, 02 Jul 2007, in the Usenet newsgroup comp.os.linux, in article
><NkYhi.5342$Io4.64@edtnps89>, Unruh wrote:
>>ibuprofin@painkiller.example.tld (Moe Trin) writes:
>>>Maybe you want to read the NTP documentation. If all you have is one
>>>time source, you are indeed unable to correct for propagation delays.
>>>But if you have more than that (can you say "redundancy" Bill? I
>>>though you could), you can deduce and eliminate nearly all of the
>>>delays.
>>
>>What delays? The delay between the gps receiver and the computer it is
>>attached to is a usec at most.
>Geez Bill, don't quit your day job. You are assuming that the delay
Maybe that is also true for you, since you have not read what I said. There
is no delay between the gps receiver and the computer it is attached to . I
said nothing about a network attached computer.
>between the server application producing the time stamp, putting that
>time stamp into a UDP packet, getting that packet out onto the wire,
What udp packet? What wire?
>up through the network stack on the receiving end, and into the NTP
What network stack?
>client a being zero, and only the transit time of an IP datagram over
>the few meters of local wire matters. Wrong-O By the same token,
>the GPS satellites are not located just down the hall but are more than
>a few miles above the surface of the geoid (try "thousands of miles"),
>and are changing the absolute range at a fairly significant rate. The
>circuitry in the GPS receiver needs the signals from _four_ satellites
>at the same time in order to determine absolute position of the
>receiver, has to listen to the ephemeral data contained within the RF
>bitstream in order to see where the sending satellites are, AND THEN
>make a correction for the range between each satellite and receiver.
Yes. And they do that for you. Then the pps delived to your computer is UTC
correct to better than a usec.
>>However redundancy is good, esp is someone decides to disconnect your gps.
>They're on UPS, just like the rest of the servers. Doesn't prevent the
>power from being disconnected, but as they are in a secured server room,
>it reduces the possibility some.
I meant disconnect the gps receiver from your computer.
>>I guess you meant that you have one gps receiver which acts as a stratum
>>one to a whole bunch of other systems. Then yes, redundancy can be useful.
>Didn't take the hint? Let's try again:
>-rw-rw-r-- 1 gferg ldp 43295 Nov 18 2005 TimePrecision-HOWTO
And here is one from my system
-rw-r--r-- 1 unruh root 2118 Oct 8 2006 /home/unruh/.bashrc
Anyway. Exactly what was it that you wanted me to read in that file.
>>On the other hand just put one on each critical machine and be done with
>>it.
>A bit impractical in these building which by reason of the metal
>fabrication, insulation with vapor barrier, and distance from a location
>where you can install a GPS antenna makes it a pain to do so. Oh, and don't
>forget to apply a correction for the length of the cable between the
>receiving antenna and the actual location of the receiver.
Lets see, propagation is a foot per nanosecond, so one usec ( which is what
I specified) is 1000 ft. Most gps antenna cable lengths are much less than
that.
>>>Read the docs from Dave Mills at UofDelaware. He writes pretty well.
>>
>>Yes, have done so. Just which point was it you wanted me to read?
>[compton ~]$ zgrep -c propag rfcs/rfc4330.txt.gz
>5
>[compton ~]$
>There might be a good word to look for and one of several places to start.
And I recommend you read the Count of Monte Cristo.
> Old guy
Navigation:
[Reply to this message]
|