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 <kb...@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 <hmur...@megapathdsl.net> wrote: > > > > > > kb...@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@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.