Re: Raspberry Pi 3B+ and pitiful network speeds

On Mon, 21 Jun 2021 17:04:32 +1000
MJ <mafsys1234@gmail.com> wrote:

> [A plain write to /dev/null from a file made by /dev/zero]
> 
> dd if=/tmp/test.img of=/dev/null
> 1024000+0 records in
> 1024000+0 records out
> 524288000 bytes (524 MB, 500 MiB) copied, 22.8584 s, 22.9 MB/s
> 
> 
> Now the network speeds (the destination machine is the same):
> 
> 22.9 Megabytes per second, filezilla to Windows 10, SSD & NVMe.

Hello Matt.

The dd command above does a sequential read performance test on the SD
reader (you mentioned earlier that the SD card is faster than that).
Even on the latest RPIs this does not exceed 45MB/s by design.

Please mind that your filezilla upload test performance is exactly the
SD card read performance (the network interface is said to be internally
bottlenecked at 300Mb/s, which is about 1.5 times the 22.9MB/s). Also it
looks like the SSD you mentioned is not where RPI filesystem is. But
this should not matter in a properly staged network throughput test.

In my "dd+nc" test the goal was to measure plain TCP performance. Hence
it consists of:
* an nc process at each end of the TCP connection
* a dd process piped to each nc process to measure the throughput
* no filesystem access, hence the dd processes reading from /dev/urandom
  (or /dev/zero if you like) and writing to /dev/null

Which would be along these lines:

# TCP download
freebsdrpi$ nc -l 10000 | dd bs=1m of=/dev/null
linuxpc$ dd if=/dev/zero bs=1M count=2000 status=progress | \
nc freebsdrpi 10000
# TCP upload
linuxpc$ nc -l 15000 | dd bs=1M of=/dev/null status=progress
freebsdrpi$ dd if=/dev/zero bs=1m count=2000 | nc linuxpc 15000

If you do not feel confident staging the test like this, iperf would be
a more convenient testing tool. Please mind it by default does a
one-way 1Mb/s test with a possible time limit. So you will have to look
at the man page and to use the right command-line options.

With due attention to detail it should be possible to identify the root
cause of the problem, and hopefully to solve it. Perhaps you could
work the test details out first using your preferred OS. As soon as you
get 300Mb/s sustained over more than the amount of RAM, you can boot
the RPI3B+ into FreeBSD and repeat the test exactly to see if the
results reproduce.

As to the board identification, RaspiOS/Raspbian can conveniently do
that in the ways explained by Mark. Obviously, you would have to boot
into it once. You don't have to keep it and to use it afterwards.

Alternatively, you can use NetBSD [1] and run the command below to get
the board revision:

# sysctl machdep.board_revision
machdep.board_revision = 10494163

(this is A020D3 in hex, as suggested by Mark before).

1:
https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.2/evbarm-aarch64/binary/gzimg/arm64.img.gz

-- 
    Denis Ovsienko