On Tue, 3 May 2016, Frank Nicholas wrote: With regards to WiFi, if I ping a Pi, sometimes 1-3 pings fail, before
the WiFi seems to "wake up". I’ve not been able to track this down to
a chipset or USB specific (it happens on the Pi 3, with built-in
Broadcom WiFi). All my scripts that automate things with my Pi’s that
are on WiFi, start with a “ping -c 4 -q $host”. ALWAYS by the 4th
ping, the Pi is responding. With the Ethernet, always by the 2nd ping,
the Pi is responding.
Aside from the wakeup issue, the latency on WiFi is typically horrible and inconsistent, making it a terrible choice for connecting a time server. The single-packet drop in the wired case is probably due to ARP. When there's no ARP cache entry for the destination, typical practice is to send an ARP request *instead of* the IP packet that it was trying to send (hoping to get a response before the retransmission).
The above wasn’t mentioned to suggest a Pi should be used on WiFi for NTP. I was just explaining that I have had no issues with using USB & WiFi on several Pi’s. Understood & agreed regarding the single ping loss on wired Ethernet. On Tue, 3 May 2016, Hal Murray wrote: Conveniently, the build doesn't require either USB or WiFi.
On a Pi, the Ethernet is on USB.
That by itself makes it a questionable choice for a time server. :-)
I mentioned that in the another discussion, when I mentioned using a USB puck GPS instead of fighting with HATs & GPIO. I’ll ask it again here - the issue/performance with polling on a USB puck GPS (limited to USB polling speed), does that same issue/concern apply because the Ethernet is on the USB bus?
Thanks, Frank |