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