On Sat, Nov 06, 2021 at 07:53:57PM +0100, Paul de Weerd wrote: > It's not so much throughput as it is latency. From the rpi to its > gateway I see solid RTTs (note that I'm SSH'd into the raspberry to > run this command): > > 64 bytes from 192.168.34.1: icmp_seq=0 ttl=255 time=1.870 ms > 64 bytes from 192.168.34.1: icmp_seq=1 ttl=255 time=2.738 ms > 64 bytes from 192.168.34.1: icmp_seq=2 ttl=255 time=2.995 ms > 64 bytes from 192.168.34.1: icmp_seq=3 ttl=255 time=2.617 ms > 64 bytes from 192.168.34.1: icmp_seq=4 ttl=255 time=2.735 ms > 64 bytes from 192.168.34.1: icmp_seq=5 ttl=255 time=2.774 ms > 64 bytes from 192.168.34.1: icmp_seq=6 ttl=255 time=2.717 ms > 64 bytes from 192.168.34.1: icmp_seq=7 ttl=255 time=2.655 ms > 64 bytes from 192.168.34.1: icmp_seq=8 ttl=255 time=2.726 ms > 64 bytes from 192.168.34.1: icmp_seq=9 ttl=255 time=2.788 ms > > --- 192.168.34.1 ping statistics --- > 10 packets transmitted, 10 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 1.870/2.661/2.995/0.281 ms > > The other direction is a lot more erratic: > > 64 bytes from 192.168.34.129: icmp_seq=0 ttl=255 time=52.829 ms > 64 bytes from 192.168.34.129: icmp_seq=1 ttl=255 time=67.423 ms > 64 bytes from 192.168.34.129: icmp_seq=2 ttl=255 time=296.138 ms > 64 bytes from 192.168.34.129: icmp_seq=3 ttl=255 time=115.754 ms > 64 bytes from 192.168.34.129: icmp_seq=4 ttl=255 time=37.241 ms > 64 bytes from 192.168.34.129: icmp_seq=5 ttl=255 time=61.002 ms > 64 bytes from 192.168.34.129: icmp_seq=6 ttl=255 time=290.358 ms > 64 bytes from 192.168.34.129: icmp_seq=7 ttl=255 time=108.851 ms > 64 bytes from 192.168.34.129: icmp_seq=8 ttl=255 time=30.519 ms > 64 bytes from 192.168.34.129: icmp_seq=9 ttl=255 time=55.587 ms > > --- 192.168.34.129 ping statistics --- > 10 packets transmitted, 10 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 30.519/111.570/296.138/94.467 ms > > When the raspberry is doing traffic (i.e. pinging its gateway or > downloading a file), replies come a lot faster (similar to RTT's when > pinging from the raspberry)
This could be wifi-client power management, in which case there is nothing to worry about. You are not losing any packets. I would assume frames get buffered in the AP while the wifi chip on the rpi is taking a short power-saving nap. The beacon period of an AP is usually about 100ms and it might take a beacon or two for the client to wake up and see the message from the AP that tells it about frames which have been buffered for it. These RTTs of <= 300 ms fit into that picture.
