[time-nuts] wifi with time sync

[Bob Camp]

Hi

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

Bob

> On Jan 14, 2017, at 1:51 PM, Orin Eman <orin.eman at 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 at 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 at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.