[ntp:questions] Leap second bug?
Richard B. Gilbert
rgilbert88 at comcast.net
Wed Jan 2 21:57:30 UTC 2008
> "Richard B. Gilbert" <rgilbert88 at comcast.net> 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.
> 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
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
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
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.
> 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.
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.
More information about the questions