Re: Raspberry Pi 3B+ and pitiful network speeds

From: Mark Millard via freebsd-arm <freebsd-arm_at_freebsd.org>
Date: Tue, 22 Jun 2021 21:56:08 -0700
On 2021-Jun-22, at 19:18, MJ <mafsys1234 at gmail.com> wrote:

> On 22/06/2021 11:25 pm, Ronald Klop wrote:
>> <...>
> 
>> 
>> Hi,
>> 
>> Just another data point for the investigation.
>> 
>> RPI3B+ FreeBSD 13.0-RELEASE-p1 #0: Wed May 26 22:19:21 UTC 2021 GENERIC
>> ue0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>    options=80009<RXCSUM,VLAN_MTU,LINKSTATE>
>>    ether b8:27:xx:xx:xx:xx
>>    inet 192.168.1.148 netmask 0xffffff00 broadcast 192.168.1.255
>>    media: Ethernet autoselect (1000baseT <full-duplex>)
>>    status: active
>>    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>> 
>> 
>> RPI4 FreeBSD 14.0-CURRENT #7 main-62ffcaab8: Tue Mar 23 17:26:53 CET 2021 GENERIC-NODEBUG
>> genet0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>    options=280009<RXCSUM,VLAN_MTU,LINKSTATE,RXCSUM_IPV6>
>>    ether dc:a6:xx:xx:xx:xx
>>    inet 192.168.1.127 netmask 0xffffff00 broadcast 192.168.1.255
>>    media: Ethernet autoselect (1000baseT <full-duplex,master>)
>>    status: active
>>    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>> 
>> 
>> These two are next to each other connected by a 1gbit switch.
>> 
>> 
>> [root_at_rpi3 ~]# iperf -c rpi4 -w 2m -t 30s -i 1
>> ------------------------------------------------------------
>> Client connecting to rpi4, TCP port 5001
>> TCP window size: 32.8 KByte (WARNING: requested 1.91 MByte)
>> ------------------------------------------------------------
>> [  1] local 192.168.1.148 port 21246 connected with 192.168.1.127 port 5001
>> [ ID] Interval       Transfer     Bandwidth
>> [  1] 0.00-1.00 sec  12.6 MBytes   106 Mbits/sec
>> [  1] 1.00-2.00 sec  13.6 MBytes   114 Mbits/sec
>> [  1] 2.00-3.00 sec  13.5 MBytes   113 Mbits/sec
>> [  1] 3.00-4.00 sec  13.6 MBytes   114 Mbits/sec
>> [  1] 4.00-5.00 sec  13.5 MBytes   113 Mbits/sec
>> [  1] 5.00-6.00 sec  13.6 MBytes   114 Mbits/sec
>> [  1] 6.00-7.00 sec  13.6 MBytes   114 Mbits/sec
>> [  1] 7.00-8.00 sec  13.6 MBytes   114 Mbits/sec
>> [  1] 8.00-9.00 sec  13.2 MBytes   111 Mbits/sec
>> [  1] 9.00-10.00 sec  13.5 MBytes   113 Mbits/sec
>> 
>> 
>> [root_at_rpi4 ~]# iperf -c rpi3 -w 2m -t 30s -i 1
>> ------------------------------------------------------------
>> Client connecting to rpi3, TCP port 5001
>> TCP window size: 32.8 KByte (WARNING: requested 1.91 MByte)
>> ------------------------------------------------------------
>> [  1] local 192.168.1.127 port 24993 connected with 192.168.1.148 port 5001
>> [ ID] Interval       Transfer     Bandwidth
>> [  1] 0.00-1.00 sec  15.6 MBytes   131 Mbits/sec
>> [  1] 1.00-2.00 sec  16.8 MBytes   141 Mbits/sec
>> [  1] 2.00-3.00 sec  16.6 MBytes   139 Mbits/sec
>> [  1] 3.00-4.00 sec  16.8 MBytes   141 Mbits/sec
>> [  1] 4.00-5.00 sec  16.5 MBytes   138 Mbits/sec
>> [  1] 5.00-6.00 sec  16.8 MBytes   141 Mbits/sec
>> [  1] 6.00-7.00 sec  16.4 MBytes   137 Mbits/sec
>> [  1] 7.00-8.00 sec  16.5 MBytes   138 Mbits/sec
>> [  1] 8.00-9.00 sec  16.6 MBytes   139 Mbits/sec
>> [  1] 9.00-10.00 sec  14.6 MBytes   123 Mbits/sec
>> 
>> 
>> Regards,
>> Ronald.
>> 
> These are very poor for the RPI4, are they not? Is it not fully 1000Mbit?

In both of the above tests, the RPi3B+ is either the sender
or the receiver: always involved. That likely bottlenecks
the RPi4B.

For reference:

QUOTE from "man iperf3"
 Normally, the test data is sent from the client to the server, and
       measures the upload speed of the client.  Measuring the download speed
       from the server can be done by specifying the -R flag on the client.
END QUOTE

I'll note that the -w 2m was ineffective: 32.8KByte was used.

> Your RPI3B results are a little better than mine. They are still not very impressive though.

In essence the tests confirm the trend of your results --but
from a different context.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Received on Wed Jun 23 2021 - 04:56:08 UTC

Original text of this message