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

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

--

Chris Albertson
Redondo Beach, California

If there is a modern microwave oven with a switching power supply,
or a cordless telephone around, you might want to look there.

The old linear supply ovens were easy to deal with because they
presented a strong CW signal that drifted around as voltage, load,
and temperature changed.  The switcher ovens simply splatter the
whole ISM band with strong microwave noise.

-Chuck Harris

Bob Camp 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…..

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

Hi

This is very much a one laptop to one router issue. The other couple dozen laptops
and tablets do not see an issue. The whole thing started when a series of firmware
updates rolled through a few weeks ago. The laptop is maybe 12 feet from the router.
It’s running at 5 GHz so microwaves (and a lot of other stuff) are not an issue.

Bob

This has nothing to do with time-nuts, can it stop please?

[ I don't know what forum to send you to for "weird wifi problems"; there
is probably no good one, because it is a very common consumer problem :( ]

NTP was mentioned because you (Bob Camp) had not defined the problem
very well, and asked some questions that it can solve. It will not
help spot an instanteous failure; it will help characterize the delay
of your network, and do so over fairly long time averages.

It seems pretty clear that nobody knows much about the protocol discussed
at CES, and probably most people have stopped reading this thread because
it is discussing something else entirely (...).
So we can probably just stop there.

However: I do not think your use of the word "overlay" is one that makes sense.
Typically things that are overlays increase overhead rather than reduce it.
Similarly, buffering causes delays which reduce the ability to get precise
timing, they do not help it. So while we can't say with much certainty
what a "magic protocol" is, it is surely not "giant buffers."

I tried to engage with you off-list and give you some pointers on this, but
that does not seem to be working. Consumer wifi driver problems are manifestly
inappropriate for this list, and trying to do both at once leads to gross
confusion :( I know this is my personal opinion and I don't speak with any
authority.

--jhawk@mit.edu
John Hawkinson

Bob Camp kb8tq@n1k.org wrote on Sat, 14 Jan 2017
at 10:46:16 -0500 in 3EE57DEE-3D6E-438B-9D1F-C2BC216C6925@n1k.org:

On 1/14/17 7:46 AM, Bob Camp wrote:

This is the thing about the OSI stack and similar models.. It works ok
for some levels of conceptualization, but quickly breaks when you have
something at a top layer that needs information from a lower layer.

Consider something like adaptive data rate and adaptive routing with
links that come and go, but are to a certain extent predictable, but
require on the fly negotiation of rate.  To make "intelligent" decisions
at the top layer, there needs to be a flow of management information
that goes up and down the stack, independent of the data flow.

This also arises when something that is notionally a communications link
gets used for something else (time transfer, ranging, etc.).

We face this all the time in spacecraft:  back in the day, when 10 bps
is your basic rate, having narrow band receivers with very good close in
phase noise was part of the system.  So using that same really pure
carrier to do ranging to centimeters was not that big a deal.  Now, when
your comm link is running at 100 Mbps, maybe the 1 Hz out phase noise
isn't important.

On 1/14/17 7:53 AM, John Hawkinson wrote:

I think that precision time distribution, over whatever medium, is the
subject of the list.  And to the extent we are cursed with hardware that
is designed for mass markets and didn't give any thought to time
distribution, figuring out how to make a rayon purse out of a pig's ear
is probably worth discussing.

NTP does a fine job at the millisecond-ey level with commodity network
hardware, and a lot of the techniques that are used by NTP - clock
modeling, various statistical filters to estimate delays from
measurements, etc. might have applicability to packet radio links (which
WiFi is but one instance of).

It might be intriguing to contemplate wireless precision time
distribution with other 802.xx systems - Zigbee, WiMax, etc.

This is an area of significant interest in the space community: We're
trying to get away from artisanally hand-crafted individual works of
technology to better utilize mass produced products. When you're
contemplating building a radio telescope with 50 receivers, each on a
small satellite, or deployed as a node on the far side of the moon,
trying to get time and frequency sync among the receivers is a
non-trivial problem. Unlike the Allen Telescope Array, it's hard to
string fiber in environmentally controlled ducts, etc. If I could use an
off the shelf WiFi or Zigbee chip to do so, that would be a wonderful
thing.  Or even if we have to design our own chip, leveraging existing
protocols and designs means we don't have to do that part of the job again.

Just to put some numerical desires to it..
Say we're contemplating HF signals.. Call it 50 MHz at the top, or 20
ns/cycle.  Say you want 1/1000 of a cycle phase knowledge, so you need
20 ps timing knowledge - for integration times of, say a few seconds.

Hi

We have a double issue here:

1. It’s a problem because “not enough information was given"

2. It’s a problem because “we are talking about it to much”

Sorry, but there is absolutely no way at all both of those criteria can
be met by me.

I do believe that WiFi time protocols are an on topic item for TimeNuts.
Given our ability to wander off topic for weeks on some subjects, it is
a bit unclear just where those bounds actually are.

I also believe that ping data is one way to come up with an upper bound on
just how awful WiFi timing can be.  If others have a similar single shot measure
of WiFi round trip that can be run on a wide range of devices, I’d certainly be just
as interested in that.

Bob

On 1/14/17 8:35 AM, Bob Camp wrote:

does software like netstumbler and such have lower level diagnostic
measurements?

There's a variety of apps for my phones that provide some info on WiFi
networks, but I think it's all sort of in the "received signal strength"
kind of level.  I've not seen anything for timing.  But that's not to
say that it doesn't exist.

I seem to recall some folks fooling with various timing parameters that
can be set into 802.11 chipsets from 10 years ago.  Today's interfaces?
I don't know.  The little interfaces that you put on a Arduino and such
expose a serial port kind of interface with a AT command set.  I think
they bury most all of the stuff we'd want to know about.

Hi

Before this all headed off into the weeds, it was a topic looking for more info on WiFi based timing enhancements. We still do not seem to have any real input on that side of it.
Hopefully somebody will pipe in at some point with real info on what the WiFI chipset guys are trying to do. At some point I would think it’s got to be made public ….

Bob