time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

Re: [time-nuts] NTP stratum 0

HM
Hal Murray
Sat, Jan 14, 2006 9:05 PM

If you are within about a millisecond, then no one will notice if the
time exchange is over the internet...

How about almost no one.  This is the time-nuts mailing list after all.

It's pretty easy to see a 1 ms offset if you have a good local clock (a place
to stand) and reasonable network connectivity to the clock you want to check.

Setup ntpd to use the remote system as a server.  Turn on logging.  Wait a while, say a day.  Maybe set minpoll to be nice and/or maxpoll to get more data.

Pull the info for that system from peerstats.  Make two graphs.

First, just plot the offset and RTT as a function of time.  That should give you the big picture.  The normal case is the RTT is flat bottom with spikes going up.  Sometimes you see shifts as the network routing changes.  The spikes are packets that hit queuing in the network.

Next, plot RTT as X and offset as Y.  That should give an arrow pointing left.  The blob at the point is the case where your request didn't encounter any network queuing.  The points along the lines leading to the point are samples with network queuing delays - top line is delays in one direction, bottom line is the other direction.  Points in the middle hit delays in both directions.

The size of the blob determines how accurately you can measure the time offset of the remote system.  (or systematic errors like ADSL or asymmetric routing)

If the fuzzy blob is 1 ms in dia, a 10 ms offset is trivial to see but you have to look closer to see a 1 ms offset.

[My system is messed up.  A good reminder to go fix it.]

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

> If you are within about a millisecond, then no one will notice if the > time exchange is over the internet... How about almost no one. This is the time-nuts mailing list after all. It's pretty easy to see a 1 ms offset if you have a good local clock (a place to stand) and reasonable network connectivity to the clock you want to check. Setup ntpd to use the remote system as a server. Turn on logging. Wait a while, say a day. Maybe set minpoll to be nice and/or maxpoll to get more data. Pull the info for that system from peerstats. Make two graphs. First, just plot the offset and RTT as a function of time. That should give you the big picture. The normal case is the RTT is flat bottom with spikes going up. Sometimes you see shifts as the network routing changes. The spikes are packets that hit queuing in the network. Next, plot RTT as X and offset as Y. That should give an arrow pointing left. The blob at the point is the case where your request didn't encounter any network queuing. The points along the lines leading to the point are samples with network queuing delays - top line is delays in one direction, bottom line is the other direction. Points in the middle hit delays in both directions. The size of the blob determines how accurately you can measure the time offset of the remote system. (or systematic errors like ADSL or asymmetric routing) If the fuzzy blob is 1 ms in dia, a 10 ms offset is trivial to see but you have to look closer to see a 1 ms offset. [My system is messed up. A good reminder to go fix it.] -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.
PK
Poul-Henning Kamp
Sat, Jan 14, 2006 11:33 PM

If you are within about a millisecond, then no one will notice if the
time exchange is over the internet...

How about almost no one.  This is the time-nuts mailing list after all.

NTPns > show ntpv4 0 partner
total  ours others
partners            2000  1144    856
partners good      1759  1118    641
partners bad        241    26    215
partners > 1s        160      6    154
partners < 1s        95    26    69
partners < 100ms    202    77    125
partners < 10ms      638    337    301
partners < 1ms      905    698    207
NTPns >

We're certainly far from "no one", in the above about 60% (698 of
1144) of the machines syncing to my server is in the millisecond
range and about 20% (207 of 856) for machines synching from other
servers.  For the entire population it is about 45% (905 of 2000)

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

In message <20060114210541.2B845BDE3@ip-64-139-1-69.sjc.megapath.net>, Hal Murr ay writes: > >> If you are within about a millisecond, then no one will notice if the >> time exchange is over the internet... > >How about almost no one. This is the time-nuts mailing list after all. NTPns > show ntpv4 0 partner total ours others partners 2000 1144 856 partners good 1759 1118 641 partners bad 241 26 215 partners > 1s 160 6 154 partners < 1s 95 26 69 partners < 100ms 202 77 125 partners < 10ms 638 337 301 partners < 1ms 905 698 207 NTPns > We're certainly far from "no one", in the above about 60% (698 of 1144) of the machines syncing to my server is in the millisecond range and about 20% (207 of 856) for machines synching from other servers. For the entire population it is about 45% (905 of 2000) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.