Bob, I think you are pushing me in this direction, but it was my conclusion before this discussion even began.
Most consumer WiFi devices will quiesce the WiFi chipset between major consumer-initiated usages for battery savings, so it's not surprising to see a good amount of random variation in ping times when done from a laptop. Some apps that try to do timing over internet do a "wake-up call" of the interface first, and then do the timing. I don't know if this was ever added to ntpd but I work with all sorts of UDP applications that have to do application-level things like wake-up calls or application-layer keepalives to bring VPN tunnels "Back to life" (otherwise the first UDP packets are dropped). Tim N3QE On Sat, Jan 14, 2017 at 2:02 PM, Bob Camp <kb...@n1k.org> wrote: > Hi > > > > On Jan 14, 2017, at 1:38 PM, Chris Albertson <albertson.ch...@gmail.com> > wrote: > > > > On Sat, Jan 14, 2017 at 7:46 AM, Bob Camp <kb...@n1k.org> wrote: > > > >> Hi > >> > >> 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….. > >> > > > > I don't understand about NTP throttling back? Yes it quickly figure out > the > > best poll interval to each of the configure reference clocks but that is > a > > good thing. > > Not a good thing if you want to check the link at least once a second and > keep > doing so for days and days. If the objective is to profile the timing > stability of > the WiFi link *and* catch all the stupid things that happen … you need a > lot > of data. There are things that happen at widely spaced intervals. Is a > ping the > best thing to use? Certainly not. There just aren’t a lot of other > candidates. > Indeed there can be such a thing as “to much data”, there is an ADEV thread > going along about that. > > Bob > > > You like those poll intervals to be as long as possible > > > > It will tell you the TIME an event occurred with good accuracy. Record > the > > ping delay and the ping's time of day in the file. Then if you want to > > compare files between different logs made on different computers you can > > know that all the time stamps are comparable. I assume you want to know > > the cause so you'd have to look at logs from other devices on your > network > > > > Question: do something happen every hour to cause this or is that > something > > happening say every 13 seconds and sets in phase with the ping interval > > every hour? > > > > Audio over wifi depends on "buffering". The data are sent in packets or > > batches. The device that actually plays the audio will keep as much as a > > few seconds of data and request more when the buffer gets about 1/2 > empty. > > So delays over wifi are not important. The re-timing is done on the > > receiving end, likely using a cheap crystal. > > > > Audio over USB, HDMI to fiber TOSLINK is packetized as well and buffered > > and re-clocked at the receiving end. The difference is the size of the > > buffer. If it is packetized then it must be buffered and rechecked, no > way > > out of that. > > > > So yes it is "giant buffers". The data sent does contain the format, how > > many channels, the sample rate and so forth > > … but If you are playing the sound out of multiple speakers scattered > around the > room *and* their only link is WiFi, time sync does matter. That’s what > started this > thread in the first place. Milisecond sync isn’t good enough in this case. > You need > microsecond level sync. > > Bob > > > > >> > >> While this *is* getting far more into my WiFi (which I had no real > >> intention of doing) it > >> does apply to timing and running audio over WiFi as well. The basic > >> transport as it > >> runs up through the various layers is *not* very good time wise. There > is > >> indeed a > >> real need for some sort of overlay to take care of that issue. I’d still > >> love to know if > >> this magic protocol is simply giant buffers and some sort of tagging or > if > >> they do > >> something more interesting. > >> > >> Bob > >>> On Jan 14, 2017, at 12:32 AM, Chris Albertson < > albertson.ch...@gmail.com> > >> wrote: > >>> > >>> On Fri, Jan 13, 2017 at 1:11 PM, Bob Camp <kb...@n1k.org> wrote: > <snip> > _______________________________________________ > 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.