CA
Chris Albertson
Sat, Jan 14, 2017 6:38 PM
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
Hi
Ok. so I bring up NTP on the laptop against a server on the other side
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
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
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
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
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
the WiFi delay added to the uncertainty in the Internet connection. But
local WiFi would be 10x worse (at least) and dominate. If you used 5 or
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
for most of it.
All that said, you can buy a good enough GPS receiver on eBay for about
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
or not accounting for velocity factor correctly or noise. But even so
using a 1PPS reference clock is going to keep the computer's system
accurate at close to the level off the system clock's resolution
On Jan 13, 2017, at 3:45 PM, Chris Albertson <
Short answer: See man page for ntpq
Longer...
First run NTP then after some time (15 minute to an hour) at the
line time type "ntpq -p"
"ntpq" will query NTP for timing statistics. It will report the
delay between the local computer and the set of reference clocks (other
servers) that NTP is connected to. Along with the average delay you
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
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
run one on say your wifi router or a local computer with hardwire
connection to the router then you'd see the effect of only your wifi.
On Fri, Jan 13, 2017 at 12:35 PM, Bob Camp kb8tq@n1k.org wrote:
Hi
What standard protocol would you recommend I run from the command line
my computer
to get a quick estimate of the timing lag and variablilty on my
particular WiFi connection?
Bob
I’m sure you are right about the response time. Right now the
variation is running almost 3 ms at one sigma on a ping so there is
a lot to do simply to get the accuracy anywhere near 1 us.
mailman/listinfo/time-nuts
and follow the instructions there.
mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
On Sat, Jan 14, 2017 at 7:46 AM, Bob Camp <kb8tq@n1k.org> 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 <albertson.chris@gmail.com>
> wrote:
> >
> > On Fri, Jan 13, 2017 at 1:11 PM, Bob Camp <kb8tq@n1k.org> 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 <
> albertson.chris@gmail.com>
> >> 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 <kb8tq@n1k.org> wrote:
> >>>
> >>>> Hi
> >>>>
> >>>> What standard protocol would you recommend I run from the command line
> >> on
> >>>> my computer
> >>>> to get a quick estimate of the timing lag and variablilty on my
> >>>> particular WiFi connection?
> >>>>
> >>>> Bob
> >>>>
> >>>>> On Jan 13, 2017, at 3:25 PM, John Hawkinson <jhawk@MIT.EDU> wrote:
> >>>>>
> >>>>> Can we please stop talking about pings?
> >>>>>
> >>>>> Bob Camp <kb8tq@n1k.org> wrote on Fri, 13 Jan 2017
> >>>>> at 15:12:38 -0500 in <C88C78A6-A015-4DCC-9E23-394DC33A3470@n1k.org>:
> >>>>>
> >>>>>> I’m sure you are right about the response time. Right now the
> >>>>>> variation is running almost 3 ms at one sigma on a ping so there is
> >>>>>> a lot to do simply to get the accuracy anywhere near 1 us.
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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.
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> Chris Albertson
> >>> Redondo Beach, California
> >>> _______________________________________________
> >>> 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.
> >>
> >
> >
> >
> > --
> >
> > Chris Albertson
> > Redondo Beach, California
> > _______________________________________________
> > 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.
>
--
Chris Albertson
Redondo Beach, California
OE
Orin Eman
Sat, Jan 14, 2017 6:51 PM
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.000000000 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.000000000 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 jimlux@earthlink.net wrote:
On 1/14/17 8:35 AM, Bob Camp wrote:
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.
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.000000000 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.000000000 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 <jimlux@earthlink.net> 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.
>
>
BC
Bob Camp
Sat, Jan 14, 2017 6:55 PM
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 orin.eman@gmail.com 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.000000000 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.000000000 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 jimlux@earthlink.net wrote:
On 1/14/17 8:35 AM, Bob Camp wrote:
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.
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 <orin.eman@gmail.com> 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.000000000 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.000000000 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 <jimlux@earthlink.net> 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.
BC
Bob Camp
Sat, Jan 14, 2017 7:02 PM
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
<snip>
Hi
> On Jan 14, 2017, at 1:38 PM, Chris Albertson <albertson.chris@gmail.com> wrote:
>
> On Sat, Jan 14, 2017 at 7:46 AM, Bob Camp <kb8tq@n1k.org> 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 <albertson.chris@gmail.com>
>> wrote:
>>>
>>> On Fri, Jan 13, 2017 at 1:11 PM, Bob Camp <kb8tq@n1k.org> wrote:
<snip>
OE
Orin Eman
Sat, Jan 14, 2017 7:29 PM
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.000000000 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.000001 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.000000000 UTC
Receive Timestamp: Jan 1, 1970 00:00:00.000000000 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.000000000 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.330390000 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.000002 sec
Root Delay: 0.0000 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 kb8tq@n1k.org 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
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.000000000 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.000001 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.000000000 UTC
Receive Timestamp: Jan 1, 1970 00:00:00.000000000 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.000000000 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.330390000 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.000002 sec
Root Delay: 0.0000 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 <kb8tq@n1k.org> 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
>
>
MS
Mark Spencer
Sat, Jan 14, 2017 7:38 PM
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
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
wrote:
On Fri, Jan 13, 2017 at 1:11 PM, Bob Camp kb8tq@n1k.org wrote:
<snip>
_______________________________________________
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.
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 <kb8tq@n1k.org> wrote:
>
> Hi
>
>
>> On Jan 14, 2017, at 1:38 PM, Chris Albertson <albertson.chris@gmail.com> wrote:
>>
>> On Sat, Jan 14, 2017 at 7:46 AM, Bob Camp <kb8tq@n1k.org> 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 <albertson.chris@gmail.com>
>>>> wrote:
>>>>
>>>> On Fri, Jan 13, 2017 at 1:11 PM, Bob Camp <kb8tq@n1k.org> wrote:
> <snip>
> _______________________________________________
> 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.
>
TS
Tim Shoppa
Sun, Jan 15, 2017 1:33 PM
Bob, I think you are pushing me in this direction, but it was my conclusion
before this discussion even began.
Most consumer WiFi devices will quiesce the WiFi chipset between major
consumer-initiated usages for battery savings, so it's not surprising to
see a good amount of random variation in ping times when done from a laptop.
Some apps that try to do timing over internet do a "wake-up call" of the
interface first, and then do the timing. I don't know if this was ever
added to ntpd but I work with all sorts of UDP applications that have to do
application-level things like wake-up calls or application-layer keepalives
to bring VPN tunnels "Back to life" (otherwise the first UDP packets are
dropped).
Tim N3QE
On Sat, Jan 14, 2017 at 2:02 PM, Bob Camp kb8tq@n1k.org wrote:
Hi
Ok, what I see is that every few hours, I get a “rogue delay” on a
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
low level
of “chat” quite quickly…..
I don't understand about NTP throttling back? Yes it quickly figure out
best poll interval to each of the configure reference clocks but that is
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
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
Question: do something happen every hour to cause this or is that
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
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
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
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
they do
something more interesting.
Bob
On Jan 14, 2017, at 12:32 AM, Chris Albertson <
<snip>
_______________________________________________
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.
Bob, I think you are pushing me in this direction, but it was my conclusion
before this discussion even began.
Most consumer WiFi devices will quiesce the WiFi chipset between major
consumer-initiated usages for battery savings, so it's not surprising to
see a good amount of random variation in ping times when done from a laptop.
Some apps that try to do timing over internet do a "wake-up call" of the
interface first, and then do the timing. I don't know if this was ever
added to ntpd but I work with all sorts of UDP applications that have to do
application-level things like wake-up calls or application-layer keepalives
to bring VPN tunnels "Back to life" (otherwise the first UDP packets are
dropped).
Tim N3QE
On Sat, Jan 14, 2017 at 2:02 PM, Bob Camp <kb8tq@n1k.org> wrote:
> Hi
>
>
> > On Jan 14, 2017, at 1:38 PM, Chris Albertson <albertson.chris@gmail.com>
> wrote:
> >
> > On Sat, Jan 14, 2017 at 7:46 AM, Bob Camp <kb8tq@n1k.org> 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 <
> albertson.chris@gmail.com>
> >> wrote:
> >>>
> >>> On Fri, Jan 13, 2017 at 1:11 PM, Bob Camp <kb8tq@n1k.org> wrote:
> <snip>
> _______________________________________________
> 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.
>
BC
Bob Camp
Sun, Jan 15, 2017 2:32 PM
Hi
I’d be surprised if a laptop running on wall power and doing a variety of low level
traffic every second is throttling the chip set. It is doing something weird and
that certainly is one candidate. I’m not quite as concerned with the why the bumps
occur (though I am curious). I’m more interested in the fact that they are really
enormous (compared to other delays). How they do microsecond timing with them
in the mix is the big question.
Bob
On Jan 15, 2017, at 8:33 AM, Tim Shoppa tshoppa@gmail.com wrote:
Bob, I think you are pushing me in this direction, but it was my conclusion
before this discussion even began.
Most consumer WiFi devices will quiesce the WiFi chipset between major
consumer-initiated usages for battery savings, so it's not surprising to
see a good amount of random variation in ping times when done from a laptop.
Some apps that try to do timing over internet do a "wake-up call" of the
interface first, and then do the timing. I don't know if this was ever
added to ntpd but I work with all sorts of UDP applications that have to do
application-level things like wake-up calls or application-layer keepalives
to bring VPN tunnels "Back to life" (otherwise the first UDP packets are
dropped).
Tim N3QE
On Sat, Jan 14, 2017 at 2:02 PM, Bob Camp kb8tq@n1k.org wrote:
Hi
Ok, what I see is that every few hours, I get a “rogue delay” on a
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
low level
of “chat” quite quickly…..
I don't understand about NTP throttling back? Yes it quickly figure out
best poll interval to each of the configure reference clocks but that is
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
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
Question: do something happen every hour to cause this or is that
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
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
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
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
they do
something more interesting.
Bob
On Jan 14, 2017, at 12:32 AM, Chris Albertson <
<snip>
_______________________________________________
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
I’d be surprised if a laptop running on wall power and doing a variety of low level
traffic every second is throttling the chip set. It *is* doing something weird and
that certainly is one candidate. I’m not quite as concerned with the *why* the bumps
occur (though I am curious). I’m more interested in the fact that they are really
enormous (compared to other delays). How they do microsecond timing with them
in the mix is the big question.
Bob
> On Jan 15, 2017, at 8:33 AM, Tim Shoppa <tshoppa@gmail.com> wrote:
>
> Bob, I think you are pushing me in this direction, but it was my conclusion
> before this discussion even began.
>
> Most consumer WiFi devices will quiesce the WiFi chipset between major
> consumer-initiated usages for battery savings, so it's not surprising to
> see a good amount of random variation in ping times when done from a laptop.
>
> Some apps that try to do timing over internet do a "wake-up call" of the
> interface first, and then do the timing. I don't know if this was ever
> added to ntpd but I work with all sorts of UDP applications that have to do
> application-level things like wake-up calls or application-layer keepalives
> to bring VPN tunnels "Back to life" (otherwise the first UDP packets are
> dropped).
>
> Tim N3QE
>
>
>
> On Sat, Jan 14, 2017 at 2:02 PM, Bob Camp <kb8tq@n1k.org> wrote:
>
>> Hi
>>
>>
>>> On Jan 14, 2017, at 1:38 PM, Chris Albertson <albertson.chris@gmail.com>
>> wrote:
>>>
>>> On Sat, Jan 14, 2017 at 7:46 AM, Bob Camp <kb8tq@n1k.org> 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 <
>> albertson.chris@gmail.com>
>>>> wrote:
>>>>>
>>>>> On Fri, Jan 13, 2017 at 1:11 PM, Bob Camp <kb8tq@n1k.org> wrote:
>> <snip>
>> _______________________________________________
>> 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.
D
David
Mon, Jan 16, 2017 8:12 PM
Modern systems are very aggressive about DVFS (dynamic voltage and
frequency scaling) so it would not surprise me at all. I have run
across this problem on the timescale of one second even on 10 year old
desktop hardware.
On Sun, 15 Jan 2017 09:32:56 -0500, you wrote:
Hi
Id be surprised if a laptop running on wall power and doing a variety of low level
traffic every second is throttling the chip set. It is doing something weird and
that certainly is one candidate. Im not quite as concerned with the why the bumps
occur (though I am curious). Im more interested in the fact that they are really
enormous (compared to other delays). How they do microsecond timing with them
in the mix is the big question.
Bob
Modern systems are very aggressive about DVFS (dynamic voltage and
frequency scaling) so it would not surprise me at all. I have run
across this problem on the timescale of one second even on 10 year old
desktop hardware.
On Sun, 15 Jan 2017 09:32:56 -0500, you wrote:
>Hi
>
>Id be surprised if a laptop running on wall power and doing a variety of low level
>traffic every second is throttling the chip set. It *is* doing something weird and
>that certainly is one candidate. Im not quite as concerned with the *why* the bumps
>occur (though I am curious). Im more interested in the fact that they are really
>enormous (compared to other delays). How they do microsecond timing with them
>in the mix is the big question.
>
>Bob
