Hi I’d be surprised if a laptop running on wall power and doing a variety of low level traffic every second is throttling the chip set. It *is* doing something weird and that certainly is one candidate. I’m not quite as concerned with the *why* the bumps occur (though I am curious). I’m more interested in the fact that they are really enormous (compared to other delays). How they do microsecond timing with them in the mix is the big question.
Bob > On Jan 15, 2017, at 8:33 AM, Tim Shoppa <tsho...@gmail.com> wrote: > > 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. _______________________________________________ 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.