[time-nuts] wifi with time sync

[Mark Spencer]

Sorry as this is perhaps a bit off topic but I've tried to make this somewhat time nuts relevant.

Over the years I found ping tests have worked quite well (at least on WAN links) to roughly measure network bandwidth.  When I used to visit remote sites with WAN links I would often perform several ping tests with different payload sizes, average the results for each payload size, then use the difference in ping times for different payload sizes to calculate the available WAN bandwidth.  The calculated bandwidth was typically close enough to the actual bandwidth that I was later asked to demonstrate this "procedure" by people who maintained the networks.   

It also worked fairly well on "wifi type" networks as well.

I do understand that ping traffic may or may not be handled differently than other network traffic but at least in my experience the results of ping tests were useful.   As usual the experience of others may differ and I can understand why this technique may not always work well.

To relate this somewhat to time nuts it might be of interest to collect this type of data and see how consistent the difference is for round trip times with pings with a small payload and a large payload over a given network path.   

One also needs to be aware of TCP Window sizes and allowable network packet sizes when picking the payload sizes for this type of test.

BTW I was shown this basic technique at an industry seminar a few decades ago but in my experience it seems to have fallen out of common use these days.

All the best
Mark Spencer


> On Jan 14, 2017, at 11:02 AM, 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.
>