they were really short on hard details about this new technology.
the WiFi alliance website only shows this off-site article link I found under
NEWS:

http://www.rcrwireless.com/20170104/test-and-measurement/20170104test-and-measurementwi-fi-alliance-to-certify-timesync-among-multiple-devices-tag6

the main alliance site is here:
http://www.wi-fi.org/  but I don't see anything helpful other than this
general explanation of TimeSync:
http://www.wi-fi.org/discover-wi-fi/wi-fi-timesync

but meaty details that might help us are hard to find.

all the best,
walter

Walter Shawlee 2, President
Sphere Research Corporation
3394 Sunnyside Rd.,  West Kelowna,  BC
V1Z 2V4  CANADA  Phone: (250) 769-1834
walter2@sphere.bc.ca
WS2: We're all in one boat, no matter how it looks to you.
Love is all you need. (John Lennon)
But, that doesn't mean other things don't come in handy. (WS2)

On 2017-01-13 08:47 AM, Joshua Pollack wrote:

Hi

Just for reference, I happen to be running a ping over my local WiFi to one of the switches
on the LAN. The ping response is anywhere from 2 ms out to 400 ms. Most of the time it’s
in the 3 to 9 ms range. Simply taking that down to < 1 us would be a really big deal.

Bob

Ping, particularly to a switch, is not a good indication of actual latency in a local network. Hosts do not prioritize responding to icmp, and on a switch to icmp is the lowest “I’ll get around to it” priority the switch has. Pinging the switch that my host is directly attached to gives an average of 1.22ms. Pinging another host attached to the same switch gives an average of 100us. The actual port to port latency on the switch is 2.45us. Your mileage may vary.

Denny

Hi

I probably should have added that I already know that the switch will do sub 1 ms
LAN pings all day long with the near zero load that it’s running. Sorry about that.

Now, there certainly are OS level things on my laptop that will muck up pings. Unfortunately
they also get into a number of timing things as well.

Bob

On Fri, January 13, 2017 11:40 am, Bob Camp wrote:

I doubt that the response time will get that low, rather the time sync
will be moved lower in the hardware stack so that the variation stays
below 1us so it can be compensated as a systematic offset.  Basically a
Wi-Fi version of the hardware time stamping that a lot of NIC's do now for
PTP support.  Just a guess at this point.

--
Chris Caudle

Hi

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.

Bob

Can we please stop talking about pings?

Bob Camp kb8tq@n1k.org wrote on Fri, 13 Jan 2017
at 15:12:38 -0500 in C88C78A6-A015-4DCC-9E23-394DC33A3470@n1k.org:

Using ping remains deeply problematic as a measure of what is possible.
The underlying layer does retransmissions and inserts delays. And ping
measures around those things, not within them. But any real tool
that was using the wireless frames for timing would be measuring
the raw layer 2 frame timing.

(It's not apparent that this would require hardware timestamping support,
although that can certainly help.)

This sort of thing is doable with today's hardware and software
technology.  Although I'm not aware of a tool that does this today
(but building one is not hard).

Denny Page's comment about hosts not prioritizing responding to ICMP
is...IMO misleading. That's not really what happens. When you ping a
switch, think of the switch as a network switch with a small computer
(host) attached that handles mangement functions, like responding to
pings. They are entirely decoupled, and the load on the management
computer is not related to the load on the network, and sometimes it's
really slow. That makes the claim about priority effectively true for
network equipment, but it's not generally true for hosts. Most hosts
will indeed respond to ICMP rapidly (in the kernel) without
prioritizing it any differently from other packets. Except the other
kinds of packets often require leaving kernel space (e.g. application
processes) which ncessarily induces more delay.

But anyhow, the upshot is correct: don't trust pings to switches, but
pings to idle hosts will be much more meaningful. But still not meaningful
on wireless networks.

So...can we please stop talking about pings? Thanks.

--jhawk@mit.edu
John Hawkinson

Even with the long and variable ping time, time sync can work. The reason
it can work is that time is not re-sync'd in one "ping" but time sync is an
on-going process that occurs over a period as long as hours.

Think about adjusting the rate of a clock by hand.  The computer (NTP) can
(and does) use the same method.  You sync it up as best you can then come
back in 24 hours and see it your clock has gained or lost time then fix the
rate and continue this process forever, eventually some balance is reached
as you learn to make fine adjustments.

So having a few tens of milliseconds of error in the communications channel
is not so bad if we can let the clocks runs for a long time and also we can
average MANY measurements,  NTP uses quite a few tricks and works about as
well as it can given the nature of the communications channels it is given
work with.  PTP has one more trick it can use that really solves the
problem.,  PTP depends on special hardware that time stamps the messages so
it knows the ping-like delays you see.    But  PTP's problem is that it
requires special PTP compatible hardware.

There are people in academia who have sync close to on order 100
nanoseconds over WiFi using PTP.  I think this is a do it your self thing
right now.  It would not be really hard to build a WiFi router form Linux
or BSD then add PTPd on each end.  There might be a commercial solution, I
don't know.

But in any case don't expect your system clock to bounce around like the
ping times do.  NTP is good enough that it does an average.

I run NTP in some WiFi connected autonomous robots and it works well enough
to keep internal log files sync'd between robots.  But I only need a few
tens of milliseconds for that.

On Fri, Jan 13, 2017 at 11:35 AM, Chris Caudle chris@chriscaudle.org
wrote:

--

Chris Albertson
Redondo Beach, California

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

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@n1k.org wrote:

--

Chris Albertson
Redondo Beach, California

Hi

That assumes that NTP is installed on the laptop.

Bob

Bob Camp kb8tq@n1k.org wrote on Fri, 13 Jan 2017
at 15:35:19 -0500 in ADCE3C3B-A84F-4F78-93B0-824F5A9B4EFC@n1k.org:

Bob: I hope you read the whole of my message, rather than just the
short upper part you quoted. I said "I'm not aware of a tool that does
this today" -- I don't think there is a good answer.

==> There isn't one. <==

You can certainly use ping to get a gross upper bound. But rememnber
it's a gross upper bound, and the underlying technology can do much
better. As Chris said, ntp will do a good job telling you the delay
between two hosts (that are running ntp and talking to each other)
by sending a lot of samples and averaging over time.

But what is your application here? You haven't made it clear.  Ping is
not representative of what you could get with a wifi using a new
technology, which was what was how this thread started, and so the
context some of the anwers (esp. mine) are in. Ping is representative
of other things, though.

--jhawk@mit.edu
John Hawkinson

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?

Bob

To add to this I'd be curious in knowing about easy PC based ways to measure network latencies / delays with microsecond accuracy vs millisecond accuracy.

The tools I used to use at work were generally designed for use on networks where millisecond resolution measurements made sense as a "figure of merit."

Best regards
Mark Spencer

Sent from my iPhone

Hi

It just so happens that I’m trying to track down an issue with my WiFi as
I type this. My guess is that there is a dropout going on. The only easy
way I can see to get a round trip time with a high data rate is to run ping.
It’s the only tool that gives me something that is fast enough to spot issues.
Is it perfect? certainly not. Is it an upper bound that is also likely the limit
for things like NTP - in my experience it sure is. That of course assumes
the gizmo that sends the pings back does so quickly and consistently. I’ve
spent enough time testing that side of it that I’m quite sure it’s true in this case.

Bob

It’s a little more complicated than that. A switch’s main cpu is like a host with rx coalesce set to 100. And there are a surprising number of things that trigger the main cpu beyond management functions. Multicast is a good example. The amount of load on the main cpu can be quite variable, and given ICMP’s low priority, it’s not unusual to see a switch that responds in 1ms suddenly jump to 25-100ms and then drop back.

Denny

On Fri, Jan 13, 2017 at 3:35 PM, Bob Camp kb8tq@n1k.org wrote:

If I wanted to do this I would use MTR (it has been ported to Windows but I
don't use that version) with the jitter option and a sub-second period.
First characterize with a wired connection against a stable host and then
switch to WiFi.  Of course that assumes you don't want to do your own math.

--
Paul

On Fri, January 13, 2017 3:17 pm, Bob Camp wrote:

This is getting off topic for time-nuts very quickly, but use bufferbloat
and "make wifi fast" as search phrases.  The guy who did a lot of the work
on queue disciplines to solve bufferbloat (over sized buffers in network
devices and drivers adding unnecessary excess latency) turned his
attention to Wi-Fi and found that Wi-Fi devices and drivers were even
worse, and the devices often had firmware running on them that hid the
sources of latency.
Because you need to be able to measure latency and bandwidth concurrently
they put together some scripts using combinations of iperf, netperf, ping,
and other tools running concurrently to measure latency under conditions
of various levels of simultaneous bandwidth use.

You can start here:
https://www.bufferbloat.net/projects/
https://www.bufferbloat.net/projects/make-wifi-fast/wiki/

For the level of problem you are trying to diagnose ping is probably an
appropriate tool, although it doesn't give much diagnostic information
when the reply time increases, it is more of a "what" than a "why" tool.

--
Chris Caudle

On 1/13/17 2:19 PM, Chris Caudle wrote:

well, wireless distribution of accurate time is, I think, on topic..

Wifi, in general, has really poor diagnostics - probably because while
they had IP (in the TCP/UDP sense) when Unix was written, or shortly
thereafter, so there are things like ping and traceroute..

WiFi has always had idiosyncracies with the Media Access and Link layer

• all stuff that is "beneath" the sort of idealized network driver level.

It's like asking for generalized utilities to measure disk access time
and error rates.. There aren't any, because every disk drive is
different (originally.. now they tend to have the same interface, which
hides most of the timing, but they also expose things like SMART)

802.11 performance is affected by oh-so-many things - your basic node is
actually half duplex, so you have the whole access point/user timing
cycle to deal with.  Then there's the whole infrastructure vs ad-hoc
thing - the latter which is very poorly supported by a lot of drivers
and OSes. Doesn't everyone just run their computer talking to an access
point? That's what all the software focuses on.

802.11 changes the data rate on the fly according to conditions, which
will change the time it takes to send the message over the air.

I'm sure there's probably some registers that count the number of bad
packets and number of good packets, but knowing whether the packet was a
2 Mbps or a 54 Mbps packet or something else is generally not available.

Most 802.11 devices have tons of configuration and status registers of
one sort or another, but very sketchy documentation.

The fact that there are even tools like net stumbler is a credit to
people who reverse engineered, or figured stuff out.

On Fri, Jan 13, 2017 at 8:45 PM, Chris Albertson
albertson.chris@gmail.com wrote:

Presuming that the computer on the WiFi network is a supported Unix, I
might use PTP to measure one way delay, PTP needs "special" hardware
to do hardware timestamping, but can be run on any network
interface.

I'd guess that the the WiFi for doing "sub microsecond" accuracy would
not be the current 2.4ghz and 5ghz, but 802.11ay

Cheers

Arne