Re: [time-nuts] wifi with time sync
kb8tq@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.
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 hmurray@megapathdsl.net wrote:
kb8tq@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.
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 kb8tq@n1k.org 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 hmurray@megapathdsl.net wrote:
kb8tq@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.
Hi
On Jan 14, 2017, at 5:29 PM, Scott Stobbe scott.j.stobbe@gmail.com 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 1/14/17 3:32 PM, Bob Camp wrote:
Hi
On Jan 14, 2017, at 5:29 PM, Scott Stobbe scott.j.stobbe@gmail.com 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.
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 jimlux@earthlink.net wrote:
On 1/14/17 3:32 PM, Bob Camp wrote:
Hi
On Jan 14, 2017, at 5:29 PM, Scott Stobbe scott.j.stobbe@gmail.com 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.
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"
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 kb8tq@n1k.org wrote:
Hi
On Jan 14, 2017, at 5:29 PM, Scott Stobbe scott.j.stobbe@gmail.com
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 kb8tq@n1k.org 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.
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.iaxs@pobox.com
Hi
Again, this is why the interest in “how the heck did they accomplish it?
With the claim of microsecond level performance, they must have run
into all these issues.
====
Just a note: any time I want to do anything that matters, I put it on 5 GHz.
There are still issues, but not quite as many. The data I presented is
from a 5 GHz link. There’s also data over the same time period showing
LAN pings all running below 1 ms for the same 24 hour period. The random
delay bumps are WiFi specific.
Bob
On Jan 15, 2017, at 12:51 AM, Bill Hawkins bill.iaxs@pobox.com wrote:
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.iaxs@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.