[time-nuts] wifi with time sync

[Bob Camp]

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 <tshoppa at 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 <kb8tq at n1k.org> wrote:
> 
>> Hi
>> 
>> 
>>> On Jan 14, 2017, at 1:38 PM, Chris Albertson <albertson.chris at gmail.com>
>> wrote:
>>> 
>>> On Sat, Jan 14, 2017 at 7:46 AM, Bob Camp <kb8tq at 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.chris at gmail.com>
>>>> wrote:
>>>>> 
>>>>> On Fri, Jan 13, 2017 at 1:11 PM, Bob Camp <kb8tq at n1k.org> wrote:
>> <snip>
>> _______________________________________________
>> 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.