[time-nuts] wifi with time sync

Bob Camp kb8tq at n1k.org
Sat Jan 14 15:35:29 EST 2017


Here’s what I am seeing:

64 bytes from icmp_seq=3700 ttl=64 time=5.025 ms
64 bytes from icmp_seq=3701 ttl=64 time=4.579 ms
64 bytes from icmp_seq=3702 ttl=64 time=1.511 ms
64 bytes from icmp_seq=3703 ttl=64 time=1.601 ms
64 bytes from icmp_seq=3704 ttl=64 time=2.370 ms
64 bytes from icmp_seq=3705 ttl=64 time=4.376 ms
64 bytes from icmp_seq=3706 ttl=64 time=2.503 ms
64 bytes from icmp_seq=3707 ttl=64 time=4.923 ms
64 bytes from icmp_seq=3708 ttl=64 time=4.458 ms
64 bytes from icmp_seq=3709 ttl=64 time=33.322 ms
64 bytes from icmp_seq=3710 ttl=64 time=2.006 ms
64 bytes from icmp_seq=3711 ttl=64 time=1.750 ms
64 bytes from icmp_seq=3712 ttl=64 time=122.948 ms
64 bytes from icmp_seq=3713 ttl=64 time=9.869 ms
64 bytes from icmp_seq=3714 ttl=64 time=24.545 ms
64 bytes from icmp_seq=3715 ttl=64 time=1.944 ms
64 bytes from icmp_seq=3716 ttl=64 time=63.656 ms
64 bytes from icmp_seq=3717 ttl=64 time=126.056 ms
64 bytes from icmp_seq=3718 ttl=64 time=99.767 ms
64 bytes from icmp_seq=3719 ttl=64 time=72.922 ms
64 bytes from icmp_seq=3720 ttl=64 time=4.168 ms
64 bytes from icmp_seq=3721 ttl=64 time=3.995 ms
64 bytes from icmp_seq=3722 ttl=64 time=5.065 ms
64 bytes from icmp_seq=3723 ttl=64 time=2.609 ms
64 bytes from icmp_seq=3724 ttl=64 time=4.355 ms
64 bytes from icmp_seq=3725 ttl=64 time=4.979 ms
64 bytes from icmp_seq=3726 ttl=64 time=4.551 ms
64 bytes from icmp_seq=3727 ttl=64 time=1.315 ms
64 bytes from icmp_seq=3728 ttl=64 time=3.747 ms
64 bytes from icmp_seq=3729 ttl=64 time=4.426 ms
64 bytes from icmp_seq=3730 ttl=64 time=4.243 ms
64 bytes from icmp_seq=3731 ttl=64 time=4.202 ms
64 bytes from icmp_seq=3732 ttl=64 time=4.382 ms

Each ping is about one second. 

A 64 second spacing on the round trip “check signals” would likely 
miss this sort of issue. On the other hand, if you are trying to send 
PPS time info *and* see the same sort of “bump” things are likely 
to go tilt pretty quickly. 

The range of the bump can go up to over half a second, but only
does that rarely. Timing between bumps is in the “hours” range.

Is this the nanoseconds or picoseconds that we normally work in?
Certainly not. It *is* something that could really mess up time 
transfer via WiFi if (note the if) it applies to other traffic as well.
There are a lot of people running around trying to move from wired
LAN’s to full WiFi. 


> On Jan 14, 2017, at 3:08 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
> kb8tq at n1k.org said:
>> Ok, what I see is that every few hours, I get a “rogue delay” on a single
>> ping. How would NTP help me spot a single transit with a 250 ms round trip
>> and identify the  time it occured? Keep in mind that NTP is going to
>> throttle back to a very low level of “chat” quite quickly….. 
> If you turn on ntpd's rawstats, it will write an entry for each packet 
> exchange with 4 time stamps.  If you assume the clocks on both systems are 
> accurate, you can get the transit times in each direction.  That will tell 
> you which direction is having troubles.  That may or may not be useful 
> information.
> You can make ntpd poll more frequently with maxpoll on the server line.  I 
> think the normal default min is 64 seconds.  You can get more by using more 
> servers.  If that's not fast enough, poke me off list and I'll write a hack 
> that will do it faster and/or write the log files in a format you like.
> -- 
> These are my opinions.  I hate spam.
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

More information about the time-nuts mailing list