[time-nuts] wifi with time sync

Chris Albertson albertson.chris at gmail.com
Sat Jan 14 13:38:57 EST 2017


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

>
> 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:
> >
> >> Hi
> >>
> >> Ok. so I bring up NTP on the laptop against a server on the other side
> of
> >> the country and install
> >> NTP on the laptop. I get all of the jitter and offset of my cable modem
> >> plus the network
> >> issues between here and who know where. If I want to know the specific
> >> delay issues just
> >> on the WiFi connection (like when it rotates keys), how do I separate
> that
> >> out?
> >>
> >
> > Run an NTP server on your local network with a wired connection to the
> > router.    Also in many cases the router itself can run NTP.
> >
> > If you are looking for smaller delays than NTP's level of uncertainty
> which
> > is going to be some tens of milliseconds then you need a hardware back
> > channel.  What I would do in that case is get s GPS with one pulse per
> > second output and feed that to BOTH the laptop and the wired NTP server.
> > Both servers will eventually sync to the 1PPS and have clocks running at
> > some tens of microseconds from each other.   With clocks on both
> computers
> > sync's to that level you can trust time stamped log files.      But this
> > requires a source of the 1PPS and some custom cables.   If tens of
> > milliseconds is OK (that is 1,000 times worse) then software and one
> > Ethernet cable are enough
> >
> > In short the best way is to have all the internal clocks of the computers
> > running UTC to some very close tolerance then when something happens you
> > log it and later process logs
> >
> > Another idea;   Connect the laptop to an NTP server with 100BaseT cable
> and
> > set up NTP to look ONLY over that interface.  Then bring up wifi for all
> > other uses.   The time sync will be maintained at millisecond level over
> > Ethernet then do your WiFi experiments.   The 1PPS a couple orders of
> > magnitude better but more work too.
> >
> > Actually your initial comment is right, you be measuring the uncertainty
> in
> > the WiFi delay added to the uncertainty in the Internet connection.  But
> he
> > local WiFi would be 10x worse (at least) and dominate.  If you used 5 or
> 7
> > NTP servers then NTP can figure out the uncertainty over the Internet by
> > comparing a large number of them and the effects of the local WiFi
> account
> > for most of it.
> >
> > All that said, you can buy a good enough GPS receiver on eBay for about
> $10
> > now.   One trouble is getting that 1PPS signal into a laptop that lacks a
> > serial port.  Using a USB dongle serieould degrades the timing accuracy.
> > But still the BEST way to distribute time sync is via a hardware 1PPS
> > network.  I use old RG58 coax salvaged from an old Ethernet to distribute
> > 1PPS.    The source of error is in the nanosecond range and mostly comes
> > from speed of light delays in the wire and not measuring the wire
> correctly
> > or not accounting for velocity factor correctly or noise.   But even so
> NTP
> > using a 1PPS  reference clock is going to keep the computer's system
> clock
> > accurate at close to the level off the system clock's resolution
> >
> >
> >>
> >> Bob
> >>
> >>> On Jan 13, 2017, at 3:45 PM, Chris Albertson <
> albertson.chris at gmail.com>
> >> wrote:
> >>>
> >>> Short answer:  See man page for ntpq
> >>>
> >>> Longer...
> >>>
> >>> First run NTP then after some time (15 minute to an hour) at the
> command
> >>> line time type "ntpq -p"
> >>>
> >>> "ntpq" will query NTP for timing statistics.  It will report the
> average
> >>> delay between the local computer and the set of reference clocks (other
> >>> servers) that NTP is connected to.  Along with the average delay you
> get
> >>> variation in that delay (std dev?)    Note the if NTP can calculate the
> >>> delay, it has already compensated for it.   It is only the uncertainty
> of
> >>> the compensation that matters, hence the need to report the variation.
> >>>
> >>> The data shows the total delay and variation over the network and the
> >>> reference clocks might be thousands of miles away.  So you might want
> to
> >>> run one on say your wifi router or a local computer with hardwire
> >>> connection to the router then you'd see the effect of only your wifi.
> >>>
> >>>
> >>>
> >>> On Fri, Jan 13, 2017 at 12:35 PM, Bob Camp <kb8tq at n1k.org> wrote:
> >>>
> >>>> Hi
> >>>>
> >>>> What standard protocol would you recommend I run from the command line
> >> on
> >>>> my computer
> >>>> to get a quick estimate of the timing lag and variablilty  on my
> >>>> particular WiFi connection?
> >>>>
> >>>> Bob
> >>>>
> >>>>> On Jan 13, 2017, at 3:25 PM, John Hawkinson <jhawk at MIT.EDU> wrote:
> >>>>>
> >>>>> Can we please stop talking about pings?
> >>>>>
> >>>>> Bob Camp <kb8tq at n1k.org> wrote on Fri, 13 Jan 2017
> >>>>> at 15:12:38 -0500 in <C88C78A6-A015-4DCC-9E23-394DC33A3470 at n1k.org>:
> >>>>>
> >>>>>> I’m sure you are right about the response time. Right now the
> >>>>>> variation is running almost 3 ms at one sigma on a ping so there is
> >>>>>> a lot to do simply to get the accuracy anywhere near 1 us.
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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.
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> Chris Albertson
> >>> Redondo Beach, California
> >>> _______________________________________________
> >>> 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.
> >>
> >
> >
> >
> > --
> >
> > Chris Albertson
> > Redondo Beach, California
> > _______________________________________________
> > 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.
>



-- 

Chris Albertson
Redondo Beach, California


More information about the time-nuts mailing list