"Richard B. Gilbert" <[EMAIL PROTECTED]> writes: >Unruh wrote: >> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes: >> >> ... >> >>>A good way to learn what's good and bad is to use a hardware reference >>>clock such as a GPS receiver. A timing receiver with PPS output will >>>generally keep the leading edge of the PPS within 50 microseconds of the >>>"top of the second". The very best internet servers will agree with the >>>GPS within two or three milliseconds. A very poorly chosen server might >>>be out by 100 milliseconds or more. By very poorly chosen, I mean >>>something like someone in New York City configuring ntpd to use a server >>>in Tokyo! A server with a GPS reference will open your eyes to the >>>atrocities committed by typical internet connections! >> >> >> A good gps receiver should be good to 1usec, not 50. And if you interrupt
>Sorry, I meant to write nanoseconds rather than microseconds. My >Motorola Oncore M12+T specifies the PPS to be within 50 ns. OK, although that is pretty optimistic. A wire from the receiver to the computer delays it by about 2ns/ foot, the interrupt serice on the computer and the time required to timestamp that packet is about another 2usec, with fluctuations depending on whether other interrupts are being serviced. >> drive the computer, the computer i timestamp should also be good to 2-3usec >> or so. >> That is the kind of jitter I get in getting the gps time from a gps PPS >> receiver. >That sounds about right. >> And yes, even for computers in the same building, the best I can get using >> that ntp server as the source is about 50 usec, with .2 msec best delay ( >> but sometimes the delays are many many times that). The biggest problem >> seems to be the computer itself getting the packet out the network card >> onto the net. >Once you get a LAN into the act, accuracy deteriorates rapidly. 50 >microseconds can easily degrade to 2-5 milliseconds depending on the >network hardware. That's still more than adequate for most That is all over a lan, through 2 switches. Typically it is about a 200 usec travel time, with the time itself fluctuating by about 30usec. with obvious popcorn spikes. >applications. Still, I don't think that the bottle neck is likely to be >the computer's ability to get the packet on the wire. Once the packet Actually if I believe tcpdump timestamping compared with the packet timestamping, it can at times be a few msec to get the packet out onto the net. Ie, the network card is far worse than the network itself. >hits the wire it still has to go through a switch and, perhaps, even a >router and another switch to reach its destination in a large building. >At my last job, we had a "core" switch in the data center, a switch on >the first floor, another on the second floor, and yet another in the >warehouse area. A packet originating in the data center had to pass >through two switches to get anywhere else in the building. When we >added VLANs to trim the sizes of our broadcast domains, the router had >to be consulted to figure out how to get the packet to its destination. Most of my machines pass through two or three switches along the way ( all GBit switches by now) >> >> Astonishingly a connection across the country 1000 miles away has a round >> trip of 40ms, but the time offset is usually about .2msec-- ie the two legs >> of the trip are amazingly repeatable. >> >> >It sometimes happens that way. In the general case, the to and from >paths are not guaranteed to be the same. Your query might go direct >from New York to Los Angeles and the reply might travel via Dallas-Fort >Worth! The routers work together to move the traffic as quickly and as >cheaply as possible but the route cannot be guaranteed unless the entire >path is under your control. I'm sure that some companies need, and can >afford, a direct line from New York to Los Angeles but most of us must >rely on the internet eventually getting things where they are going. Fortunately Canada is very one dimensional. So stuff tends to go the same way there and back. Between Sask and BC the only alternatives are Calgary or Edmonton, and I suspect that the backbone goes through calgary. >I've noticed that servers that appear dreadful from 8 AM to 10 PM local >time can show amazing improvement when the net quiets down at night. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
