[time-nuts] wifi with time sync

[Bob Camp]

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>