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