Re: [time-nuts] wifi with time sync

[Bill Hawkins]

 
I haven't read the entire thread, but this may be relevant. If not, you
know where to find the delete key.

I live in a life care community - one of 450 people in 300 apartments on
3 floors. When I moved in a year ago, I could get Internet from the
house cable, and they provided the modem. I bought wired and wireless
802.11n dual band routers for two apartments, a two bedroom for us and
an alcove for my shop. There was plenty of noise from other such
routers, but no problem within an apartment. I couldn't use a wireless
keyboard, though. The cursor wandered around with the noise.

Last month, a company experienced in wiring hotels for wireless put DSL
to RJ-45 and 11n wireless access points in each apartment on the second
floor, adding 100 transmitters to the mix. DSL with existing phone
wiring was far cheaper than running new cable. The intent was to provide
universal public Wi-Fi for the children of the residents.

They might as well have installed 100 jammers. There were complaints of
unusable cordless phones (most in the 2.4 GHz range) and lost Wi-Fi
connections that simply reverted to the default IP address range and
failed to reconnect.

I got a home copy (this is my home) of InSSIDer software and surveyed
the halls at 2.4 GHz with a Windows 7 laptop (you need a larger screen
to see the signal distribution) I could see 10 to 20 of the new access
points, as well as the occasional excursion to -10 dbm (top of scale) as
nearby routers and printers kicked in. Great stuff.

There are environments where time sync with Wi-Fi hasn't got a chance.

Jim Lux was looking for a COTS solution to time sync, and this might
work in a controlled environment.

Don't even think about consumer radio clocks that sync from unknown
Wi-Fi environments.

Bill Hawkins (John Hawkins son)
bill.i...@pobox.com


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Scott Stobbe]

Yes, it will be interesting to see how well wifi rtt/tof does indoors with
plenty of multipath. But for sure sub microsecond.

On Sat, Jan 14, 2017 at 6:32 PM Bob Camp  wrote:

> Hi
>
>
>
>
>
> > On Jan 14, 2017, at 5:29 PM, Scott Stobbe 
> wrote:
>
> >
>
> > I don't think wifi is ever going to be a real-time system, as it shares
> the
>
> > ether with all other ISM devices. That said even 1 ms of variation is
> still
>
> > 4 orders of magnitude greater than the actual time of flight.
>
> >
>
> > The precision time aspect will most certainly be done in hardware, even
> if
>
> > it's just as simple as a timestamp of receiving the beacon frame.
>
>
>
> My concern *is* that it’s going to be like 1588 in that respect. Off we
> all have
>
> to buy new time stamping hardware. Until that’s all up and running
>
> you don’t get the new timing stuff. Based on what I see, there’s not a lot
>
> of hope for it otherwise.
>
>
>
> Bob
>
>
>
> >
>
> > On Sat, Jan 14, 2017 at 3:35 PM, Bob Camp  wrote:
>
> >
>
> >> Hi
>
>
>
> ___
>
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[jimlux]

On 1/14/17 4:25 PM, Bob Camp wrote:

Hi

Maybe the magic stamping has been hiding in the chips all along.
What’s pretty clear is that if it’s there, it’s well hidden ….

or totally unstandardized - it might be one of those "we put it in for 
manufacturing test" features, and everyone does it differently.



just rummmaging through some datasheets..
I see that for the SG922-0007 (a WiFi module with AT command set) they do list a value that can be 
read for "timestamp of last received packet" and "timestamp of last transmitted 
packet"



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Bob Camp]

Hi

Maybe the magic stamping has been hiding in the chips all along. 
What’s pretty clear is that if it’s there, it’s well hidden ….

Bob

> On Jan 14, 2017, at 7:04 PM, jimlux  wrote:
> 
> On 1/14/17 3:32 PM, Bob Camp wrote:
>> Hi
>> 
>> 
>>> On Jan 14, 2017, at 5:29 PM, Scott Stobbe  wrote:
>>> 
>>> I don't think wifi is ever going to be a real-time system, as it shares the
>>> ether with all other ISM devices. That said even 1 ms of variation is still
>>> 4 orders of magnitude greater than the actual time of flight.
>>> 
>>> The precision time aspect will most certainly be done in hardware, even if
>>> it's just as simple as a timestamp of receiving the beacon frame.
>> 
>> My concern *is* that it’s going to be like 1588 in that respect. Off we all 
>> have
>> to buy new time stamping hardware. Until that’s all up and running
>> you don’t get the new timing stuff. Based on what I see, there’s not a lot
>> of hope for it otherwise.
>> 
> 
> 
> just rummmaging through some datasheets..
> I see that for the SG922-0007 (a WiFi module with AT command set) they do 
> list a value that can be read for "timestamp of last received packet" and 
> "timestamp of last transmitted packet"
> 
> 
> As to what those might mean??
> 
> A Copperhead WiFi shield for Arduino has a microchip MRF24WB0MA on it (it's a 
> few years old, I think it's been replaced by something newer)
> 
> Microchip doesn't make it easy to find the SPI interface details, though.
> 
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[jimlux]

On 1/14/17 3:32 PM, Bob Camp wrote:

Hi



On Jan 14, 2017, at 5:29 PM, Scott Stobbe  wrote:

I don't think wifi is ever going to be a real-time system, as it shares the
ether with all other ISM devices. That said even 1 ms of variation is still
4 orders of magnitude greater than the actual time of flight.

The precision time aspect will most certainly be done in hardware, even if
it's just as simple as a timestamp of receiving the beacon frame.


My concern *is* that it’s going to be like 1588 in that respect. Off we all have
to buy new time stamping hardware. Until that’s all up and running
you don’t get the new timing stuff. Based on what I see, there’s not a lot
of hope for it otherwise.




just rummmaging through some datasheets..
I see that for the SG922-0007 (a WiFi module with AT command set) they 
do list a value that can be read for "timestamp of last received packet" 
and "timestamp of last transmitted packet"



As to what those might mean??

A Copperhead WiFi shield for Arduino has a microchip MRF24WB0MA on it 
(it's a few years old, I think it's been replaced by something newer)


Microchip doesn't make it easy to find the SPI interface details, though.




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Bob Camp]

Hi


> On Jan 14, 2017, at 5:29 PM, Scott Stobbe  wrote:
> 
> I don't think wifi is ever going to be a real-time system, as it shares the
> ether with all other ISM devices. That said even 1 ms of variation is still
> 4 orders of magnitude greater than the actual time of flight.
> 
> The precision time aspect will most certainly be done in hardware, even if
> it's just as simple as a timestamp of receiving the beacon frame.

My concern *is* that it’s going to be like 1588 in that respect. Off we all 
have 
to buy new time stamping hardware. Until that’s all up and running 
you don’t get the new timing stuff. Based on what I see, there’s not a lot
of hope for it otherwise. 

Bob

> 
> On Sat, Jan 14, 2017 at 3:35 PM, Bob Camp  wrote:
> 
>> Hi

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Scott Stobbe]

I don't think wifi is ever going to be a real-time system, as it shares the
ether with all other ISM devices. That said even 1 ms of variation is still
4 orders of magnitude greater than the actual time of flight.

The precision time aspect will most certainly be done in hardware, even if
it's just as simple as a timestamp of receiving the beacon frame.

On Sat, Jan 14, 2017 at 3:35 PM, Bob Camp  wrote:

> Hi
>
> Here’s what I am seeing:
>
> 64 bytes from 192.168.2.2: icmp_seq=3700 ttl=64 time=5.025 ms
> 64 bytes from 192.168.2.2: icmp_seq=3701 ttl=64 time=4.579 ms
> 64 bytes from 192.168.2.2: icmp_seq=3702 ttl=64 time=1.511 ms
> 64 bytes from 192.168.2.2: icmp_seq=3703 ttl=64 time=1.601 ms
> 64 bytes from 192.168.2.2: icmp_seq=3704 ttl=64 time=2.370 ms
> 64 bytes from 192.168.2.2: icmp_seq=3705 ttl=64 time=4.376 ms
> 64 bytes from 192.168.2.2: icmp_seq=3706 ttl=64 time=2.503 ms
> 64 bytes from 192.168.2.2: icmp_seq=3707 ttl=64 time=4.923 ms
> 64 bytes from 192.168.2.2: icmp_seq=3708 ttl=64 time=4.458 ms
> 64 bytes from 192.168.2.2: icmp_seq=3709 ttl=64 time=33.322 ms
> 64 bytes from 192.168.2.2: icmp_seq=3710 ttl=64 time=2.006 ms
> 64 bytes from 192.168.2.2: icmp_seq=3711 ttl=64 time=1.750 ms
> 64 bytes from 192.168.2.2: icmp_seq=3712 ttl=64 time=122.948 ms
> 64 bytes from 192.168.2.2: icmp_seq=3713 ttl=64 time=9.869 ms
> 64 bytes from 192.168.2.2: icmp_seq=3714 ttl=64 time=24.545 ms
> 64 bytes from 192.168.2.2: icmp_seq=3715 ttl=64 time=1.944 ms
> 64 bytes from 192.168.2.2: icmp_seq=3716 ttl=64 time=63.656 ms
> 64 bytes from 192.168.2.2: icmp_seq=3717 ttl=64 time=126.056 ms
> 64 bytes from 192.168.2.2: icmp_seq=3718 ttl=64 time=99.767 ms
> 64 bytes from 192.168.2.2: icmp_seq=3719 ttl=64 time=72.922 ms
> 64 bytes from 192.168.2.2: icmp_seq=3720 ttl=64 time=4.168 ms
> 64 bytes from 192.168.2.2: icmp_seq=3721 ttl=64 time=3.995 ms
> 64 bytes from 192.168.2.2: icmp_seq=3722 ttl=64 time=5.065 ms
> 64 bytes from 192.168.2.2: icmp_seq=3723 ttl=64 time=2.609 ms
> 64 bytes from 192.168.2.2: icmp_seq=3724 ttl=64 time=4.355 ms
> 64 bytes from 192.168.2.2: icmp_seq=3725 ttl=64 time=4.979 ms
> 64 bytes from 192.168.2.2: icmp_seq=3726 ttl=64 time=4.551 ms
> 64 bytes from 192.168.2.2: icmp_seq=3727 ttl=64 time=1.315 ms
> 64 bytes from 192.168.2.2: icmp_seq=3728 ttl=64 time=3.747 ms
> 64 bytes from 192.168.2.2: icmp_seq=3729 ttl=64 time=4.426 ms
> 64 bytes from 192.168.2.2: icmp_seq=3730 ttl=64 time=4.243 ms
> 64 bytes from 192.168.2.2: icmp_seq=3731 ttl=64 time=4.202 ms
> 64 bytes from 192.168.2.2: icmp_seq=3732 ttl=64 time=4.382 ms
>
> Each ping is about one second.
>
> A 64 second spacing on the round trip “check signals” would likely
> miss this sort of issue. On the other hand, if you are trying to send
> PPS time info *and* see the same sort of “bump” things are likely
> to go tilt pretty quickly.
>
> The range of the bump can go up to over half a second, but only
> does that rarely. Timing between bumps is in the “hours” range.
>
> Is this the nanoseconds or picoseconds that we normally work in?
> Certainly not. It *is* something that could really mess up time
> transfer via WiFi if (note the if) it applies to other traffic as well.
> There are a lot of people running around trying to move from wired
> LAN’s to full WiFi.
>
> Bob
>
> > On Jan 14, 2017, at 3:08 PM, Hal Murray  wrote:
> >
> >
> > kb...@n1k.org said:
> >> 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…..
> >
> > If you turn on ntpd's rawstats, it will write an entry for each packet
> > exchange with 4 time stamps.  If you assume the clocks on both systems
> are
> > accurate, you can get the transit times in each direction.  That will
> tell
> > you which direction is having troubles.  That may or may not be useful
> > information.
> >
> > You can make ntpd poll more frequently with maxpoll on the server line.
> I
> > think the normal default min is 64 seconds.  You can get more by using
> more
> > servers.  If that's not fast enough, poke me off list and I'll write a
> hack
> > that will do it faster and/or write the log files in a format you like.
> >
> >
> > --
> > These are my opinions.  I hate spam.
> >
> >
> >
> > ___
> > time-nuts mailing list -- time-nuts@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@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@febo.com
To unsubscribe, go to 

Re: [time-nuts] Thermal effects on cables --> ADEV

[Azelio Boriani]

May I suggest to turn the 24 hours reset period into a parameter?

On Fri, Jan 13, 2017 at 8:45 PM, Tom Van Baak  wrote:
> Mark, Ole,
>
> Yes, averaging can both enhance precision but also destroy information. In 
> many cases too much data is a bad thing. The solution is to add another 
> dimension to the plot. Stable32 does this with DAVAR (dynamic Allan 
> variance). TimeLab has a multi- "trace" feature. Both of these break large 
> data sets into smaller ones and display each in succession. This way you get 
> the best of both worlds; precision without long-term pollution and also a 
> view of long-term trends. Yes, there's an art to picking the right 
> parameters, but you get the idea. In some cases it is highly informative. The 
> color 3D DAVAR plots in particular can be a thing of beauty.
>
> So, in your case, save each of those 24 hour GIF's and then turn then into a 
> single animated GIF. That way not only do you get a fresh view of current 
> reception conditions, but also a time lapse view of changes over the 
> long-term.
>
> Another idea is to somehow 2D transform your polar plots into a horizontal 
> rectangular strip and then use elapsed time in the vertical. This would allow 
> a waterfall-style representation of GPS reception over time.
>
> /tvb
>
> - Original Message -
> From: "Mark Sims" 
> To: 
> Sent: Friday, January 13, 2017 11:03 AM
> Subject: [time-nuts] Thermal effects on cables --> ADEV
>
>
>>I recently made a change in Lady Heather's satellite signal maps to help with 
>>a very similar issue.  Before, the maps were based upon the accumulated 
>>average value of the sat signals at each point in the sky.  Now, every 24 
>>hours, the signal level averages are reset to their current average and the 
>>sample counts are reset to 1.  That way any change is your antenna 
>>performance won't be masked by days/week/months of previous data.
>>
>> 
>>
>>> Don't use years worth of data.
>> Otherwise it could be days before the xDEV visually changes
>
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Bob Camp]

Hi

Here’s what I am seeing:

64 bytes from 192.168.2.2: icmp_seq=3700 ttl=64 time=5.025 ms
64 bytes from 192.168.2.2: icmp_seq=3701 ttl=64 time=4.579 ms
64 bytes from 192.168.2.2: icmp_seq=3702 ttl=64 time=1.511 ms
64 bytes from 192.168.2.2: icmp_seq=3703 ttl=64 time=1.601 ms
64 bytes from 192.168.2.2: icmp_seq=3704 ttl=64 time=2.370 ms
64 bytes from 192.168.2.2: icmp_seq=3705 ttl=64 time=4.376 ms
64 bytes from 192.168.2.2: icmp_seq=3706 ttl=64 time=2.503 ms
64 bytes from 192.168.2.2: icmp_seq=3707 ttl=64 time=4.923 ms
64 bytes from 192.168.2.2: icmp_seq=3708 ttl=64 time=4.458 ms
64 bytes from 192.168.2.2: icmp_seq=3709 ttl=64 time=33.322 ms
64 bytes from 192.168.2.2: icmp_seq=3710 ttl=64 time=2.006 ms
64 bytes from 192.168.2.2: icmp_seq=3711 ttl=64 time=1.750 ms
64 bytes from 192.168.2.2: icmp_seq=3712 ttl=64 time=122.948 ms
64 bytes from 192.168.2.2: icmp_seq=3713 ttl=64 time=9.869 ms
64 bytes from 192.168.2.2: icmp_seq=3714 ttl=64 time=24.545 ms
64 bytes from 192.168.2.2: icmp_seq=3715 ttl=64 time=1.944 ms
64 bytes from 192.168.2.2: icmp_seq=3716 ttl=64 time=63.656 ms
64 bytes from 192.168.2.2: icmp_seq=3717 ttl=64 time=126.056 ms
64 bytes from 192.168.2.2: icmp_seq=3718 ttl=64 time=99.767 ms
64 bytes from 192.168.2.2: icmp_seq=3719 ttl=64 time=72.922 ms
64 bytes from 192.168.2.2: icmp_seq=3720 ttl=64 time=4.168 ms
64 bytes from 192.168.2.2: icmp_seq=3721 ttl=64 time=3.995 ms
64 bytes from 192.168.2.2: icmp_seq=3722 ttl=64 time=5.065 ms
64 bytes from 192.168.2.2: icmp_seq=3723 ttl=64 time=2.609 ms
64 bytes from 192.168.2.2: icmp_seq=3724 ttl=64 time=4.355 ms
64 bytes from 192.168.2.2: icmp_seq=3725 ttl=64 time=4.979 ms
64 bytes from 192.168.2.2: icmp_seq=3726 ttl=64 time=4.551 ms
64 bytes from 192.168.2.2: icmp_seq=3727 ttl=64 time=1.315 ms
64 bytes from 192.168.2.2: icmp_seq=3728 ttl=64 time=3.747 ms
64 bytes from 192.168.2.2: icmp_seq=3729 ttl=64 time=4.426 ms
64 bytes from 192.168.2.2: icmp_seq=3730 ttl=64 time=4.243 ms
64 bytes from 192.168.2.2: icmp_seq=3731 ttl=64 time=4.202 ms
64 bytes from 192.168.2.2: icmp_seq=3732 ttl=64 time=4.382 ms

Each ping is about one second. 

A 64 second spacing on the round trip “check signals” would likely 
miss this sort of issue. On the other hand, if you are trying to send 
PPS time info *and* see the same sort of “bump” things are likely 
to go tilt pretty quickly. 

The range of the bump can go up to over half a second, but only
does that rarely. Timing between bumps is in the “hours” range.

Is this the nanoseconds or picoseconds that we normally work in?
Certainly not. It *is* something that could really mess up time 
transfer via WiFi if (note the if) it applies to other traffic as well.
There are a lot of people running around trying to move from wired
LAN’s to full WiFi. 

Bob

> On Jan 14, 2017, at 3:08 PM, Hal Murray  wrote:
> 
> 
> kb...@n1k.org said:
>> 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….. 
> 
> If you turn on ntpd's rawstats, it will write an entry for each packet 
> exchange with 4 time stamps.  If you assume the clocks on both systems are 
> accurate, you can get the transit times in each direction.  That will tell 
> you which direction is having troubles.  That may or may not be useful 
> information.
> 
> You can make ntpd poll more frequently with maxpoll on the server line.  I 
> think the normal default min is 64 seconds.  You can get more by using more 
> servers.  If that's not fast enough, poke me off list and I'll write a hack 
> that will do it faster and/or write the log files in a format you like.
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Hal Murray]

kb...@n1k.org said:
> 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….. 

If you turn on ntpd's rawstats, it will write an entry for each packet 
exchange with 4 time stamps.  If you assume the clocks on both systems are 
accurate, you can get the transit times in each direction.  That will tell 
you which direction is having troubles.  That may or may not be useful 
information.

You can make ntpd poll more frequently with maxpoll on the server line.  I 
think the normal default min is 64 seconds.  You can get more by using more 
servers.  If that's not fast enough, poke me off list and I'll write a hack 
that will do it faster and/or write the log files in a format you like.


-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Mark Spencer]

Sorry as this is perhaps a bit off topic but I've tried to make this somewhat 
time nuts relevant.

Over the years I found ping tests have worked quite well (at least on WAN 
links) to roughly measure network bandwidth.  When I used to visit remote sites 
with WAN links I would often perform several ping tests with different payload 
sizes, average the results for each payload size, then use the difference in 
ping times for different payload sizes to calculate the available WAN 
bandwidth.  The calculated bandwidth was typically close enough to the actual 
bandwidth that I was later asked to demonstrate this "procedure" by people who 
maintained the networks.   

It also worked fairly well on "wifi type" networks as well.

I do understand that ping traffic may or may not be handled differently than 
other network traffic but at least in my experience the results of ping tests 
were useful.   As usual the experience of others may differ and I can 
understand why this technique may not always work well.

To relate this somewhat to time nuts it might be of interest to collect this 
type of data and see how consistent the difference is for round trip times with 
pings with a small payload and a large payload over a given network path.   

One also needs to be aware of TCP Window sizes and allowable network packet 
sizes when picking the payload sizes for this type of test.

BTW I was shown this basic technique at an industry seminar a few decades ago 
but in my experience it seems to have fallen out of common use these days.

All the best
Mark Spencer


> On Jan 14, 2017, at 11:02 AM, Bob Camp  wrote:
> 
> Hi
> 
> 
>> On Jan 14, 2017, at 1:38 PM, Chris Albertson  
>> wrote:
>> 
>> On Sat, Jan 14, 2017 at 7:46 AM, 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…..
>> 
>> 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.  
> 
> Not a good thing if you want to check the link at least once a second and 
> keep 
> doing so for days and days. If the objective is to profile the timing 
> stability of 
> the WiFi link *and* catch all the stupid things that happen … you need a lot
> of data. There are things that happen at widely spaced intervals. Is a ping 
> the 
> best thing to use? Certainly not. There just aren’t a lot of other 
> candidates. 
> Indeed there can be such a thing as “to much data”, there is an ADEV thread
> going along about that. 
> 
> Bob
> 
>> 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
> 
> … but If you are playing the sound out of multiple speakers scattered around 
> the 
> room *and* their only link is WiFi, time sync does matter. That’s what 
> started this
> thread in the first place. Milisecond sync isn’t good enough in this case. 
> You need
> microsecond level sync. 
> 
> Bob
> 
>> 
>>> 
>>> 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

Re: [time-nuts] wifi with time sync

[Orin Eman]

I merely used the ping to demonstrate Wireshark's packet time stamping
(though in this case, it seems that the router responds immediately).
FWIW, a couple of NTP packets got captured too with a 34 ms round trip.  I
was actually looking for an ARP request/response in consecutive packets on
the grounds that the router wouldn't delay ARP responses... I found one and
it was (claimed) 1.107 ms round trip.  I make no claim as to the accuracy
of these timestamps.

NTP packets:

Frame 779: 90 bytes on wire (720 bits), 90 bytes captured (720 bits) on
interface 0
Interface id: 0 (en1)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 14, 2017 10:22:46.628995000 PST
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1484418166.628995000 seconds
[Time delta from previous captured frame: 0.279231000 seconds]
[Time delta from previous displayed frame: 0.279231000 seconds]
[Time since reference or first frame: 129.296382000 seconds]
Frame Number: 779
Frame Length: 90 bytes (720 bits)
Capture Length: 90 bytes (720 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:udp:ntp]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: Apple_a2:57:7b (a8:8e:24:a2:57:7b), Dst:
Actionte_1a:57:9e (00:26:b8:1a:57:9e)
Internet Protocol Version 4, Src: 192.168.1.10, Dst: 17.253.26.253
User Datagram Protocol, Src Port: 123, Dst Port: 123
Network Time Protocol (NTP Version 4, client)
Flags: 0x23, Leap Indicator: no warning, Version number: NTP Version 4,
Mode: client
Peer Clock Stratum: secondary reference (2)
Peer Polling Interval: 6 (64 sec)
Peer Clock Precision: 0.01 sec
Root Delay:0.0334 sec
Root Dispersion:0.0335 sec
Reference ID: 17.253.26.253
Reference Timestamp: Jan 14, 2017 18:20:38.646497000 UTC
Origin Timestamp: Jan  1, 1970 00:00:00.0 UTC
Receive Timestamp: Jan  1, 1970 00:00:00.0 UTC
Transmit Timestamp: Jan 14, 2017 18:22:46.628854000 UTC

Frame 780: 90 bytes on wire (720 bits), 90 bytes captured (720 bits) on
interface 0
Interface id: 0 (en1)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 14, 2017 10:22:46.663003000 PST
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1484418166.663003000 seconds
[Time delta from previous captured frame: 0.034008000 seconds]
[Time delta from previous displayed frame: 0.034008000 seconds]
[Time since reference or first frame: 129.33039 seconds]
Frame Number: 780
Frame Length: 90 bytes (720 bits)
Capture Length: 90 bytes (720 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:udp:ntp]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: Actionte_1a:57:9e (00:26:b8:1a:57:9e), Dst:
Apple_a2:57:7b (a8:8e:24:a2:57:7b)
Internet Protocol Version 4, Src: 17.253.26.253, Dst: 192.168.1.10
User Datagram Protocol, Src Port: 123, Dst Port: 123
Network Time Protocol (NTP Version 4, server)
Flags: 0x24, Leap Indicator: no warning, Version number: NTP Version 4,
Mode: server
Peer Clock Stratum: primary reference (1)
Peer Polling Interval: 6 (64 sec)
Peer Clock Precision: 0.02 sec
Root Delay:0. sec
Root Dispersion:0.0011 sec
Reference ID: Unidentified reference source 'GPSs'
Reference Timestamp: Jan 14, 2017 18:22:40.409336000 UTC
Origin Timestamp: Jan 14, 2017 18:22:46.628854000 UTC
Receive Timestamp: Jan 14, 2017 18:22:46.637396000 UTC
Transmit Timestamp: Jan 14, 2017 18:22:46.637419000 UTC


On Sat, Jan 14, 2017 at 10:55 AM, Bob Camp  wrote:

> Hi
>
> The issue with using Wireshark is that it still is looking at a ping. It
> may tag the
> event to one more digit, but all of the earlier mentioned issues with
> pings are
> still there. Simply put, they aren’t the greatest thing for testing timing.
>
> Bob
>
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Bob Camp]

Hi


> On Jan 14, 2017, at 1:38 PM, Chris Albertson  
> wrote:
> 
> On Sat, Jan 14, 2017 at 7:46 AM, 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…..
>> 
> 
> 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.  

Not a good thing if you want to check the link at least once a second and keep 
doing so for days and days. If the objective is to profile the timing stability 
of 
the WiFi link *and* catch all the stupid things that happen … you need a lot
of data. There are things that happen at widely spaced intervals. Is a ping the 
best thing to use? Certainly not. There just aren’t a lot of other candidates. 
Indeed there can be such a thing as “to much data”, there is an ADEV thread
going along about that. 

Bob

> 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

… but If you are playing the sound out of multiple speakers scattered around 
the 
room *and* their only link is WiFi, time sync does matter. That’s what started 
this
thread in the first place. Milisecond sync isn’t good enough in this case. You 
need
microsecond level sync. 

Bob

> 
>> 
>> 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 
>> wrote:
>>> 
>>> On Fri, Jan 13, 2017 at 1:11 PM, Bob Camp  wrote:

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Bob Camp]

Hi

The issue with using Wireshark is that it still is looking at a ping. It may 
tag the
event to one more digit, but all of the earlier mentioned issues with pings are
still there. Simply put, they aren’t the greatest thing for testing timing. 

Bob

> On Jan 14, 2017, at 1:51 PM, Orin Eman  wrote:
> 
> You could run a network monitor, Wireshark for example...
> 
> https://wiki.wireshark.org/CaptureSetup/WLAN
> 
> There are specialized WIFI capture programs, but they tend to be designed
> to break into networks rather than monitor performance - kismet/kismac.  I
> run them every so often to check for malfeasance in the neighborhood.  The
> Netstumbler kind of apps just try to discover local networks and report
> their signal strengths.
> 
> I'd say Wireshark is a fair bet for packet timing, but even it might not
> have the accuracy desired.  Here is a ping and its response on my WIFI
> network, taken by Wireshark on a late 2012 Mac Mini on its builtin WIFI
> adapter.  It's reporting to micro-second resolution and the ping time is
> around 1.2 ms on this network.  It ranged from 0.993 to 5.927 (first ping)
> over the dozen or so pings before I stopped it.  I don't know where the
> time stamps are taken - whether it's in the OS or when it gets to Wireshark
> itself.  FWIW, the WIFI access point is a Frontier Fios router.
> 
> Frame 955: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on
> interface 0
>Interface id: 0 (en1)
>Encapsulation type: Ethernet (1)
>Arrival Time: Jan 14, 2017 10:23:01.707462000 PST
>[Time shift for this packet: 0.0 seconds]
>Epoch Time: 1484418181.707462000 seconds
>[Time delta from previous captured frame: 0.501617000 seconds]
>[Time delta from previous displayed frame: 0.501617000 seconds]
>[Time since reference or first frame: 144.374849000 seconds]
>Frame Number: 955
>Frame Length: 98 bytes (784 bits)
>Capture Length: 98 bytes (784 bits)
>[Frame is marked: False]
>[Frame is ignored: False]
>[Protocols in frame: eth:ethertype:ip:icmp:data]
>[Coloring Rule Name: ICMP]
>[Coloring Rule String: icmp || icmpv6]
> Ethernet II, Src: Apple_a2:57:7b (a8:8e:24:a2:57:7b), Dst:
> Actionte_1a:57:9e (00:26:b8:1a:57:9e)
> Internet Protocol Version 4, Src: 192.168.1.10, Dst: 192.168.1.1
> Internet Control Message Protocol
> 
> 
> Frame 956: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on
> interface 0
>Interface id: 0 (en1)
>Encapsulation type: Ethernet (1)
>Arrival Time: Jan 14, 2017 10:23:01.708586000 PST
>[Time shift for this packet: 0.0 seconds]
>Epoch Time: 1484418181.708586000 seconds
>[Time delta from previous captured frame: 0.001124000 seconds]
>[Time delta from previous displayed frame: 0.001124000 seconds]
>[Time since reference or first frame: 144.375973000 seconds]
>Frame Number: 956
>Frame Length: 98 bytes (784 bits)
>Capture Length: 98 bytes (784 bits)
>[Frame is marked: True]
>[Frame is ignored: False]
>[Protocols in frame: eth:ethertype:ip:icmp:data]
>[Coloring Rule Name: ICMP]
>[Coloring Rule String: icmp || icmpv6]
> Ethernet II, Src: Actionte_1a:57:9e (00:26:b8:1a:57:9e), Dst:
> Apple_a2:57:7b (a8:8e:24:a2:57:7b)
> Internet Protocol Version 4, Src: 192.168.1.1, Dst: 192.168.1.10
> Internet Control Message Protocol
> 
> 
> On Sat, Jan 14, 2017 at 9:44 AM, jimlux  wrote:
> 
>> On 1/14/17 8:35 AM, Bob Camp wrote:
>> 
>>> Hi
>>> 
>>> 
>> 
>>> 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.
>>> 
>>> 
>> 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.
>> 
>> 
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Orin Eman]

You could run a network monitor, Wireshark for example...

https://wiki.wireshark.org/CaptureSetup/WLAN

There are specialized WIFI capture programs, but they tend to be designed
to break into networks rather than monitor performance - kismet/kismac.  I
run them every so often to check for malfeasance in the neighborhood.  The
Netstumbler kind of apps just try to discover local networks and report
their signal strengths.

I'd say Wireshark is a fair bet for packet timing, but even it might not
have the accuracy desired.  Here is a ping and its response on my WIFI
network, taken by Wireshark on a late 2012 Mac Mini on its builtin WIFI
adapter.  It's reporting to micro-second resolution and the ping time is
around 1.2 ms on this network.  It ranged from 0.993 to 5.927 (first ping)
over the dozen or so pings before I stopped it.  I don't know where the
time stamps are taken - whether it's in the OS or when it gets to Wireshark
itself.  FWIW, the WIFI access point is a Frontier Fios router.

Frame 955: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on
interface 0
Interface id: 0 (en1)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 14, 2017 10:23:01.707462000 PST
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1484418181.707462000 seconds
[Time delta from previous captured frame: 0.501617000 seconds]
[Time delta from previous displayed frame: 0.501617000 seconds]
[Time since reference or first frame: 144.374849000 seconds]
Frame Number: 955
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: Apple_a2:57:7b (a8:8e:24:a2:57:7b), Dst:
Actionte_1a:57:9e (00:26:b8:1a:57:9e)
Internet Protocol Version 4, Src: 192.168.1.10, Dst: 192.168.1.1
Internet Control Message Protocol


Frame 956: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on
interface 0
Interface id: 0 (en1)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 14, 2017 10:23:01.708586000 PST
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1484418181.708586000 seconds
[Time delta from previous captured frame: 0.001124000 seconds]
[Time delta from previous displayed frame: 0.001124000 seconds]
[Time since reference or first frame: 144.375973000 seconds]
Frame Number: 956
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: True]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: Actionte_1a:57:9e (00:26:b8:1a:57:9e), Dst:
Apple_a2:57:7b (a8:8e:24:a2:57:7b)
Internet Protocol Version 4, Src: 192.168.1.1, Dst: 192.168.1.10
Internet Control Message Protocol


On Sat, Jan 14, 2017 at 9:44 AM, jimlux  wrote:

> On 1/14/17 8:35 AM, Bob Camp wrote:
>
>> Hi
>>
>>
>
>> 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.
>>
>>
> 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.
>
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Chris Albertson]

On Sat, Jan 14, 2017 at 7:46 AM, 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…..
>

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 
> wrote:
> >
> > On Fri, Jan 13, 2017 at 1:11 PM, Bob Camp  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 

Re: [time-nuts] wifi with time sync

[Bob Camp]

Hi

> On Jan 14, 2017, at 12:44 PM, jimlux  wrote:
> 
> On 1/14/17 8:35 AM, Bob Camp wrote:
>> Hi
>> 
> 
>> 
>> 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.
>> 
> 
> 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.

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

> 
> 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.
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[jimlux]

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

Hi





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.



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.




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Bob Camp]

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 Jan 14, 2017, at 10:53 AM, John Hawkinson  wrote:
> 
> 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


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[jimlux]

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


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.




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.





___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[jimlux]

On 1/14/17 7:46 AM, 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.



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.


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[John Hawkinson]

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.

--jh...@mit.edu
  John Hawkinson


Bob Camp  wrote on Sat, 14 Jan 2017
at 10:46:16 -0500 in <3ee57dee-3d6e-438b-9d1f-c2bc216c6...@n1k.org>:

> 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.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Bob Camp]

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

> On Jan 14, 2017, at 1:15 AM, Chuck Harris  wrote:
> 
> 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
>> 
>> 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
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Bob Camp]

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
> On Jan 14, 2017, at 12:32 AM, Chris Albertson  
> wrote:
> 
> On Fri, Jan 13, 2017 at 1:11 PM, Bob Camp  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 
>> 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  wrote:
>>> 
 Hi
 
 What