[time-nuts] wifi with time sync

[Scott Stobbe]

I don't think wifi is ever going to be a real-time system, as it shares the
ether with all other ISM devices. That said even 1 ms of variation is still
4 orders of magnitude greater than the actual time of flight.

The precision time aspect will most certainly be done in hardware, even if
it's just as simple as a timestamp of receiving the beacon frame.

On Sat, Jan 14, 2017 at 3:35 PM, Bob Camp <kb8tq at n1k.org> wrote:

> Hi
>
> Here’s what I am seeing:
>
> 64 bytes from 192.168.2.2: icmp_seq=3700 ttl=64 time=5.025 ms
> 64 bytes from 192.168.2.2: icmp_seq=3701 ttl=64 time=4.579 ms
> 64 bytes from 192.168.2.2: icmp_seq=3702 ttl=64 time=1.511 ms
> 64 bytes from 192.168.2.2: icmp_seq=3703 ttl=64 time=1.601 ms
> 64 bytes from 192.168.2.2: icmp_seq=3704 ttl=64 time=2.370 ms
> 64 bytes from 192.168.2.2: icmp_seq=3705 ttl=64 time=4.376 ms
> 64 bytes from 192.168.2.2: icmp_seq=3706 ttl=64 time=2.503 ms
> 64 bytes from 192.168.2.2: icmp_seq=3707 ttl=64 time=4.923 ms
> 64 bytes from 192.168.2.2: icmp_seq=3708 ttl=64 time=4.458 ms
> 64 bytes from 192.168.2.2: icmp_seq=3709 ttl=64 time=33.322 ms
> 64 bytes from 192.168.2.2: icmp_seq=3710 ttl=64 time=2.006 ms
> 64 bytes from 192.168.2.2: icmp_seq=3711 ttl=64 time=1.750 ms
> 64 bytes from 192.168.2.2: icmp_seq=3712 ttl=64 time=122.948 ms
> 64 bytes from 192.168.2.2: icmp_seq=3713 ttl=64 time=9.869 ms
> 64 bytes from 192.168.2.2: icmp_seq=3714 ttl=64 time=24.545 ms
> 64 bytes from 192.168.2.2: icmp_seq=3715 ttl=64 time=1.944 ms
> 64 bytes from 192.168.2.2: icmp_seq=3716 ttl=64 time=63.656 ms
> 64 bytes from 192.168.2.2: icmp_seq=3717 ttl=64 time=126.056 ms
> 64 bytes from 192.168.2.2: icmp_seq=3718 ttl=64 time=99.767 ms
> 64 bytes from 192.168.2.2: icmp_seq=3719 ttl=64 time=72.922 ms
> 64 bytes from 192.168.2.2: icmp_seq=3720 ttl=64 time=4.168 ms
> 64 bytes from 192.168.2.2: icmp_seq=3721 ttl=64 time=3.995 ms
> 64 bytes from 192.168.2.2: icmp_seq=3722 ttl=64 time=5.065 ms
> 64 bytes from 192.168.2.2: icmp_seq=3723 ttl=64 time=2.609 ms
> 64 bytes from 192.168.2.2: icmp_seq=3724 ttl=64 time=4.355 ms
> 64 bytes from 192.168.2.2: icmp_seq=3725 ttl=64 time=4.979 ms
> 64 bytes from 192.168.2.2: icmp_seq=3726 ttl=64 time=4.551 ms
> 64 bytes from 192.168.2.2: icmp_seq=3727 ttl=64 time=1.315 ms
> 64 bytes from 192.168.2.2: icmp_seq=3728 ttl=64 time=3.747 ms
> 64 bytes from 192.168.2.2: icmp_seq=3729 ttl=64 time=4.426 ms
> 64 bytes from 192.168.2.2: icmp_seq=3730 ttl=64 time=4.243 ms
> 64 bytes from 192.168.2.2: icmp_seq=3731 ttl=64 time=4.202 ms
> 64 bytes from 192.168.2.2: 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.
>
> Bob
>
> > 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.
>
> _______________________________________________
> 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.
>