[time-nuts] can of worms: time-of-day in a community radio station

Sun Oct 20 19:18:43 UTC 2019

I have been quite puzzled about the asymmetric nature of my home Cable
Modem connection to the Internet in regard with the offset discrepancy
I observe. The "last mile" asymmetric nature of Cable Modem (Comcast
in my case) is not very high compared the delta I see between my
stratum-1 servers at home and the nearest public stratum-1 NTP server.
The upload/download discrepancy would be much less than 100
microseconds - as you point out in your calculation the worst is 33
microseconds for an upload speed of 12 Mbps, which is a drop in the
bucket compared to other potential sources of jitter, switch queueing
delays or asymmetric routing. The latter is not an issue in my case.
I've used traceroute to check routing and I see that in both
directions packets are routed between the two BGP ASes by the nearest
(and most importantly, the same) peering point in Seattle. The public
stratum-1 NTP server is at UW University in Seattle, and my home is in
Bellevue, 10 miles from Seattle. All in all the latency from Comcast
endpoint to UW University is approximately 3 millieconds, and latency
from my home to Comcast endpoint is about 10 milliseconds. I've
observed these latency numbers to be fairly constant throughout a few
months of observations.

This is a typical NTPQ output from one of my stratum-1 NTP servers at home:

root at pendulum # ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oGPS_NMEA(0)     .GPS.            0 l   13   16  377    0.000    0.014   0.000
 ticktock.pengui .GPS.            1 u    4   64  377    0.101   -0.016   0.012
 clepsydra.pengu .GSYM.           1 u    4   64  377    0.114    0.042   0.011
 omega.s.uw.edu  172.22.16.38     2 u   43   64  377   19.868    1.631   1.189

* local server (pendulum) is a FreeBSD pcengines x64 box which uses a
BG7TBL GPSDO with PPS
* ticktock is a FreeBSD pcengines x64 box which uses a Ublox-7 GPS
receiver with PPS
* clepsydra is a FeeBSD AMD x64 PC which uses a Symmetricom BCP635
timing board disciplined with a Ublox-7 GPS receiver with PPS
* omega.s.uw.edu is Seattle's University of Washington public
stratum-1 NTP server

Currently I am observing a time offset of about 1.6 milliseconds,
compared with a maximum time offset of 42 microseconds between the
internal stratum-1 servers (I really need to measure the interrupt
latency for PPS and adjust the offsets accordingly).

I've taken pendulum stratum-1 server to my office in Seattle, and once
there NTPQ reports an offset of about 100-200 microseconds with the
public NTP server, which is a far more reasonable.

Maybe I should double check the routing from both ends again and make
sure they are really symmetric...... I can also ask my coworkers in
the networking group and hear what they think about it.

-- Fio (a time-nut who's very puzzled by this offset discrepancy)

>
>
> Assume a NTP packet with all the protocol overhead is 100 bytes.  That's 800
> bits.  At 12 megabits/sec, that's 66 microseconds.  Half of that is the worst
> offset you can get and it would be lost in the noise from other sources.
>
>
> There are 2 big ones.  The first is queuing delays.  The usual suspect the
> last hop to your house.  You have some control over that.  But there are
> queues out in the great big internet that you probably can't measure.
>
> The second is asymmetric routing.  Your packets probably go out mostly on the
> server's ISP and back mostly on your ISP.
>
> If you get caught in the crossfire of nation-state level cyber games, packets
> between cities in the US may go via Iceland in one direction.
>
>

-- Fio Cattaneo

Universal AC, can Entropy be reversed? -- "THERE IS AS YET
INSUFFICIENT DATA FOR A MEANINGFUL ANSWER."

On Sun, Oct 20, 2019 at 2:03 AM Hal Murray <hmurray at megapathdsl.net> wrote:
>
>
> Replies to several messages collected here to reduce traffic.
>
>
> artgodwin at gmail.com said:
> > Off-the-wall thought :   could you discipline a well-insulated raspberry pi
> > to NTP using heaters or workload to modify its temperature ?
>
> Yes.
>   https://blog.ntpsec.org/2017/03/21/More_Heat.html
>
> The other approach is to measure the temperature and correct for it.
>
> NTP temperature compensation
> Mark Martinec, 2001-01-08
>   https://www.ijs.si/time/temp-compensation/
>
> ----------
>
> David J Taylor  said:
> > I suppose if you have a poor or overloaded internet connection  server
> > quality doesn't matter as much - well, almost.  My ISP is 200/20, and  used
> > to be 200/12.  Talk about asymmetric!
>
> Assume a NTP packet with all the protocol overhead is 100 bytes.  That's 800
> bits.  At 12 megabits/sec, that's 66 microseconds.  Half of that is the worst
> offset you can get and it would be lost in the noise from other sources.
>
> There are 2 big ones.  The first is queuing delays.  The usual suspect the
> last hop to your house.  You have some control over that.  But there are
> queues out in the great big internet that you probably can't measure.
>
> The second is asymmetric routing.  Your packets probably go out mostly on the
> server's ISP and back mostly on your ISP.
>
> If you get caught in the crossfire of nation-state level cyber games, packets
> between cities in the US may go via Iceland in one direction.
>
> ------------
>
> kb8tq at n1k.org said:
> > At some odd hour of the day, one day a week, the tech geek fires up WWVB and
> > pipes it into an audio trunk. He / she then wanders around with  a set of
> > headphones. Each clock in the station gets set to “the right time”. Any clock
> > that is out by more than some defined amount gets flagged  for repair.
>
> What was the ballpark for "defined amount"?
>
> Any guess on how far a typical clock drifted in a week?
>
>
> > In some places, the clocks that got the set process had tags on them that
> > told you to use them for the correct time. Indeed even so, people  still
> > would look at their wrist watch …..
>
> 40ish years ago, the time servers on the Xerox internal network were mostly
> set from my watch.  I don't remember doing anything fancy to set it.  I
> probably used POP-CORN.  We did have crude drift correction.  I think the
> units were seconds per day, probably an integer.
>
> I remember an interesting improvement in Alto timekeeping.  Ed Taft got annoyed at how poorly they kept time.  He tracked it down to the handoff between designers, builders, and programmers.  The Alto was designed with a 170 ns cycle time.  Crystals are ordered by MHz rather than ns.  The crystals said 5.88 MHz.  That's off by 400 ppm.  A magic constant deep within the OS was tweaked and things got much better.
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.