[time-nuts] wifi with time sync

Tim Shoppa tshoppa at gmail.com
Sun Jan 15 08:33:39 EST 2017


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.
>


More information about the time-nuts mailing list