Pi4 2gb ram network speed

[BobHamil]

Hello,
I referred in another post about network performance of the new Pi4's I got. "Create your own Raspberry Pi Network Testers"
I got one each of 1gb, 2gb, and 4gb ram Pi4's, to use in 1000Mbps network testing especially with iperf3. I'll put Pi4's at distant points on networks, like I used to do with laptops to figure out problems.
I had to learn more about iperf3 to get a better idea what was happening. I still don't understand all the details of how these tests reflect network realities, but I think I'm using iperf3 effectively, but I welcome better ideas.
First, I had no idea how cpu intensive these tests are. Running bidirectional 900+Mbps tests occupies 2.5 of the 4 cpu's and can overheat the Pi4's. It never mattered on the laptops which had plenty of resources, but I think this load contributes to the Pi4's having a slightly higher error rate than the laptops do at the same top speed. I do think these Pi4's will be effective for 1g network testing, but I may have to take cooling measures.

I don't know the inner workings of iperf3, but I found that I could only get consistent tests if I used the -b 0 switch rather than -b 1000000000. I suspect that the effort by iperf3 to run at a specific speed was enough extra effort to make for many more errors on the Pi's. They seem to run just enough cooler with the -b 0 switch that perhaps additional cooling won't be needed. In the end, I was using "iperf3 -u -b 0 -c x.x.x.x -t 300 ; vcgencmd measure_temp".

After much elimination of poor cables and flaky switches, and improving iperf3 commands, I found the Pi4 1gb and 4gb ram units can consistently send 956Mbps and receive 942Mbps. The 2gb ram Pi4 could only send at 743Mbps, but received the same as the others. The sd cards are made from the same .img, the only difference in them is the host name and static ip address. I'm not too bothered by the slower send speed on the one, I think it will still be effective.
If anyone has ideas on how to check this out more, I would do so.

Thanks,
Bob

[jamesh]

Odd. Only ting I would say is that the Pi does not overheat - its can get hot, and it it gets to a predetermined temperature it will throttle to keep within allowed limits.

If you are doing encrypted traffic, that can load up the CPU's.

[blee0518]

I would say a faulty NIC on the PI, if everything is the same as the other. Using bootable image from same SD and all.

[ejolson]

Hello,
I referred in another post about network performance of the new Pi4's I got. "Create your own Raspberry Pi Network Testers"
I got one each of 1gb, 2gb, and 4gb ram Pi4's, to use in 1000Mbps network testing especially with iperf3. I'll put Pi4's at distant points on networks, like I used to do with laptops to figure out problems.
I had to learn more about iperf3 to get a better idea what was happening. I still don't understand all the details of how these tests reflect network realities, but I think I'm using iperf3 effectively, but I welcome better ideas.
First, I had no idea how cpu intensive these tests are. Running bidirectional 900+Mbps tests occupies 2.5 of the 4 cpu's and can overheat the Pi4's. It never mattered on the laptops which had plenty of resources, but I think this load contributes to the Pi4's having a slightly higher error rate than the laptops do at the same top speed. I do think these Pi4's will be effective for 1g network testing, but I may have to take cooling measures.

I don't know the inner workings of iperf3, but I found that I could only get consistent tests if I used the -b 0 switch rather than -b 1000000000. I suspect that the effort by iperf3 to run at a specific speed was enough extra effort to make for many more errors on the Pi's. They seem to run just enough cooler with the -b 0 switch that perhaps additional cooling won't be needed. In the end, I was using "iperf3 -u -b 0 -c x.x.x.x -t 300 ; vcgencmd measure_temp".

After much elimination of poor cables and flaky switches, and improving iperf3 commands, I found the Pi4 1gb and 4gb ram units can consistently send 956Mbps and receive 942Mbps. The 2gb ram Pi4 could only send at 743Mbps, but received the same as the others. The sd cards are made from the same .img, the only difference in them is the host name and static ip address. I'm not too bothered by the slower send speed on the one, I think it will still be effective.
If anyone has ideas on how to check this out more, I would do so.

Thanks,
Bob

Could the firmware of the 2GB model be a different version? Unlike previous Pi, the Pi 4B has onboard EEPROMs which store firmware. Thus, there could be differences in the low-level software, even if the SD cards are identical.

In my opinion 743 Mbps is slow enough to indicate something is wrong.

[ejolson]

In my opinion 743 Mbps is slow enough to indicate something is wrong.

On the other hand, I just ran a test here with the "iperf3 -s" server running on a PC named d0 and obtained the following results from a Pi 4B 2GB:

Code: Select all

$ /usr/bin/time iperf3 -c d0 -u -b1G ; # UDP from Pi to PC
Connecting to host d0, port 5201
[  5] local 192.168.174.145 port 38448 connected to 192.168.174.150 port 5201
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec  90.0 MBytes   755 Mbits/sec  65189  
[  5]   1.00-2.00   sec  89.5 MBytes   751 Mbits/sec  64801  
[  5]   2.00-3.00   sec  89.4 MBytes   750 Mbits/sec  64705  
[  5]   3.00-4.00   sec  89.4 MBytes   750 Mbits/sec  64770  
[  5]   4.00-5.00   sec  89.6 MBytes   752 Mbits/sec  64905  
[  5]   5.00-6.00   sec  90.2 MBytes   757 Mbits/sec  65347  
[  5]   6.00-7.00   sec  90.6 MBytes   760 Mbits/sec  65634  
[  5]   7.00-8.00   sec  90.4 MBytes   759 Mbits/sec  65491  
[  5]   8.00-9.00   sec  90.8 MBytes   761 Mbits/sec  65719  
[  5]   9.00-10.00  sec  90.8 MBytes   761 Mbits/sec  65736  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec   901 MBytes   756 Mbits/sec  0.000 ms  0/652297 (0%)  sender
[  5]   0.00-10.04  sec   901 MBytes   752 Mbits/sec  0.016 ms  0/652297 (0%)  receiver

iperf Done.
0.87user 9.18system 0:10.12elapsed 99%CPU (0avgtext+0avgdata 3752maxresident)k
0inputs+0outputs (1major+222minor)pagefaults 0swaps
$ /usr/bin/time iperf3 -c d0 ; # TCP from Pi to PC
Connecting to host d0, port 5201
[  5] local 192.168.174.145 port 44586 connected to 192.168.174.150 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   113 MBytes   944 Mbits/sec    0    373 KBytes       
[  5]   1.00-2.00   sec   112 MBytes   941 Mbits/sec    0    373 KBytes       
[  5]   2.00-3.00   sec   112 MBytes   941 Mbits/sec    0    373 KBytes       
[  5]   3.00-4.00   sec   112 MBytes   938 Mbits/sec    0    373 KBytes       
[  5]   4.00-5.00   sec   112 MBytes   941 Mbits/sec    0    373 KBytes       
[  5]   5.00-6.00   sec   112 MBytes   938 Mbits/sec    0    373 KBytes       
[  5]   6.00-7.00   sec   112 MBytes   941 Mbits/sec    0    373 KBytes       
[  5]   7.00-8.00   sec   112 MBytes   941 Mbits/sec    0    373 KBytes       
[  5]   8.00-9.00   sec   112 MBytes   941 Mbits/sec    0    373 KBytes       
[  5]   9.00-10.00  sec   112 MBytes   938 Mbits/sec    0    373 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec    0             sender
[  5]   0.00-10.04  sec  1.09 GBytes   936 Mbits/sec                  receiver

iperf Done.
0.03user 0.60system 0:10.12elapsed 6%CPU (0avgtext+0avgdata 3756maxresident)k
0inputs+0outputs (1major+254minor)pagefaults 0swaps

So I'm getting about 750 Mbits/sec sending data from the Pi to the PC using UDP and about 940 Mbits/sec when doing the same using TCP. Note CPU was 99 percent when using UDP.

For comparison PC to PC networking between two similar PCs was

Code: Select all

$ /usr/bin/time iperf3 -c d0 -u -b1G ; # UDP from PC to similar PC
Connecting to host d0, port 5201
[  5] local 192.168.174.151 port 39665 connected to 192.168.174.150 port 5201
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec   113 MBytes   949 Mbits/sec  81884  
[  5]   1.00-2.00   sec   113 MBytes   949 Mbits/sec  81913  
[  5]   2.00-3.00   sec   113 MBytes   949 Mbits/sec  81889  
[  5]   3.00-4.00   sec   113 MBytes   949 Mbits/sec  81890  
[  5]   4.00-5.00   sec   113 MBytes   949 Mbits/sec  81881  
[  5]   5.00-6.00   sec   113 MBytes   949 Mbits/sec  81888  
[  5]   6.00-7.00   sec   113 MBytes   949 Mbits/sec  81888  
[  5]   7.00-8.00   sec   113 MBytes   949 Mbits/sec  81925  
[  5]   8.00-9.00   sec   113 MBytes   949 Mbits/sec  81884  
[  5]   9.00-10.00  sec   113 MBytes   949 Mbits/sec  81887  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  1.10 GBytes   949 Mbits/sec  0.000 ms  0/818929 (0%)  sender
[  5]   0.00-10.00  sec  1.10 GBytes   949 Mbits/sec  0.015 ms  0/818921 (0%)  receiver

iperf Done.
0.74user 3.47system 0:10.01elapsed 42%CPU (0avgtext+0avgdata 3580maxresident)k
8inputs+0outputs (1major+193minor)pagefaults 0swaps
$ /usr/bin/time iperf3 -c d0 ; # TCP from PC to similar PC
Connecting to host d0, port 5201
[  5] local 192.168.174.151 port 35250 connected to 192.168.174.150 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   113 MBytes   949 Mbits/sec    0    411 KBytes       
[  5]   1.00-2.00   sec   111 MBytes   935 Mbits/sec    0    411 KBytes       
[  5]   2.00-3.00   sec   111 MBytes   933 Mbits/sec    0    411 KBytes       
[  5]   3.00-4.00   sec   111 MBytes   931 Mbits/sec    0    411 KBytes       
[  5]   4.00-5.00   sec   112 MBytes   940 Mbits/sec    0    411 KBytes       
[  5]   5.00-6.00   sec   111 MBytes   934 Mbits/sec    0    411 KBytes       
[  5]   6.00-7.00   sec   111 MBytes   928 Mbits/sec    0    411 KBytes       
[  5]   7.00-8.00   sec   111 MBytes   935 Mbits/sec    0    411 KBytes       
[  5]   8.00-9.00   sec   112 MBytes   939 Mbits/sec    0    411 KBytes       
[  5]   9.00-10.00  sec   111 MBytes   931 Mbits/sec    0    411 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.09 GBytes   936 Mbits/sec    0             sender
[  5]   0.00-10.00  sec  1.09 GBytes   934 Mbits/sec                  receiver

iperf Done.
0.01user 0.41system 0:10.02elapsed 4%CPU (0avgtext+0avgdata 3624maxresident)k
256inputs+0outputs (1major+225minor)pagefaults 0swaps

[ejolson]

It would appear the EEPROM in the 2GB Raspberry Pi 4B here is a rather old version. I typed the commands

Code: Select all

$ vcgencmd bootloader_version
May 10 2019 19:40:36
version d2402c53cdeb0f072ff05d52987b1b6b6d474691 (release)
timestamp 0

which seems to indicate the original May 10, 2019 version of the firmware. Could you try running the same command on your 1GB, 2GB and 4GB models to see if there is a correlation with the faster UDP network speeds and the EEPROM version?

[BobHamil]

ejolson,
Thanks for that possibility, but it looks like they are all current.

pi@pi1:~ $ vcgencmd bootloader_version
Sep 10 2019 10:41:50
version f626c772b15ba1b7e0532a8d50a761b3ccbdf3bb (release)
timestamp 1568112110
pi@pi1:~ $

pi@pi2:~ $ vcgencmd bootloader_version
Sep 10 2019 10:41:50
version f626c772b15ba1b7e0532a8d50a761b3ccbdf3bb (release)
timestamp 1568112110
pi@pi2:~ $

pi@pi4:~ $ vcgencmd bootloader_version
Sep 10 2019 10:41:50
version f626c772b15ba1b7e0532a8d50a761b3ccbdf3bb (release)
timestamp 1568112110
pi@pi4:~ $

Bob

[ejolson]

ejolson,
Thanks for that possibility, but it looks like they are all current.

pi@pi1:~ $ vcgencmd bootloader_version
Sep 10 2019 10:41:50
version f626c772b15ba1b7e0532a8d50a761b3ccbdf3bb (release)
timestamp 1568112110
pi@pi1:~ $

pi@pi2:~ $ vcgencmd bootloader_version
Sep 10 2019 10:41:50
version f626c772b15ba1b7e0532a8d50a761b3ccbdf3bb (release)
timestamp 1568112110
pi@pi2:~ $

pi@pi4:~ $ vcgencmd bootloader_version
Sep 10 2019 10:41:50
version f626c772b15ba1b7e0532a8d50a761b3ccbdf3bb (release)
timestamp 1568112110
pi@pi4:~ $

Bob

I agree that the difference in speed you have observed between the 1GB, 2GB and 4GB models is mysterious. From what I understand, you have already tried plugging the 2GB Pi into the exact same network cable and port on the network switch and it is still 20% slower when transmitting UPD packets.

Interestingly, I get similar speeds to your 2GB model with the 2GB model here. What type of switch are you using? Have you tried the same experient with a single point-to-point cable?

[BobHamil]

In the end I was connecting directly to a laptop and just changed the Pi on the end of the cable for each test. I have been using static addresses on Pi's and laptop.
I think the only thing that I haven't done, but don't think it will make any difference, is swapping sd cards between the units. My current setup makes that difficult.
Thanks for the help,
Bob

[ejolson]

In the end I was connecting directly to a laptop and just changed the Pi on the end of the cable for each test. I have been using static addresses on Pi's and laptop.
I think the only thing that I haven't done, but don't think it will make any difference, is swapping sd cards between the units. My current setup makes that difficult.
Thanks for the help,
Bob

I've been looking at my WireGuard performance results at

viewtopic.php?f=36&t=251159

and realized that the likely reason for most of the performance loss is due to poor UDP performance on the 2GB model rather than the encryption. If, for some reason, the Pi 4B with 2GB RAM really has 20% slower UDP performance than the 1GB and 4GB models, this would imply that replacing the 1GB model with a 2GB model as has been done in the current product lineup could be a mistake when WireGuard or any other protocol which relies on UDP is in use.

It would be nice if more people could confirm this result. In particular, does the 2GB model with improved USB-C compatibility still suffer from the same slowdown in UDP networking as reported here?

[BobHamil]

Maybe this belongs in a iperf3 forum, but I think I should relate that I use udp for iperf3 testing because a year ago, when I was failing to find a problem of poor throughput on a client's network, I was getting excellent testing results using tcp on iperf3, but still couldn't get much real-life throughput.
Finally, I made a test rig of two rj-45's and four 30inch twisted pairs I stripped the jacket off of. I connected it between two laptops with 1g nics. (Since then I have ruined the 1g nics in all but one laptop, so I can't replicate the test, just with laptops.)
I kept running iperf3 tcp tests while I progressively untwisted the active twisted pair a couple more inches for each test. The tcp iperf3 tests kept showing in the 900's, even with most of the active pair untwisted, I connected the test setup to the internet, and couldn't get any webpage through it.
By chance (I don't understand the difference in how computers or iperf3 treat tcp different than udp) I added the -u and found that iperf3 -u gave test results that accurately reflected how real-world throughput I was getting. Using the -u switch, I was able to find several problems in the client's network, and got it going at 950Mbps, so I've never use iperf3 without the -u switch since.
I still have the test rig I could try, if anyone thought it was helpful, but it was a lot of tedium, so I'm not going to if not necessary.
Bob

[PhilE]

I can't think of any hardware reasons why a 2GB board should be any slower. I'd like to see all your boards with the latest EEPROMs and OS images (the software has improved quite a bit), but before then you could try adding "total_mem=2048" to config.txt on the card used by the 4GB Pi - that should restrict it to the first 2GB of RAM, making it effectively a 2GB board.

[ejolson]

It would be nice if more people could confirm this result. In particular, does the 2GB model with improved USB-C compatibility still suffer from the same slowdown in UDP networking as reported here?

I just had another idea, maybe by default Pi 4B computers with different memory sizes boot different kernels. Could it be

• The 2GB model boots the LPAE kernel by default.
• The 1GB model boots the non-LPAE 32-bit kernel instead.

Can you check with

uname -a

to determine if the same kernels are running on each of the Pi computers?

[BobHamil]

Hello all,
BTW, I am running the latest Buster Lite 2/13/20.
It looks like there are firmware upgrades available, so I plan to update all three Pi4's, then repeat all the throughput tests on each Pi, and run a second test using "total_mem=2048" added to config.txt on the Pi4 4gb.
I have a 1g usb3 nic that I will also run thrupt tests on each Pi4 also from the usb3 port to laptop, but may also run the test from eth0 to the usb nic on each Pi4 out of curiosity to see what happens.
I notice that ejolson's tests do not have any errors, but my tests last week, almost all had a few errors. Is there any value if I go to the trouble of posting output from all the tests?
I'll run uname -a on each Pi and post results.
I'm thinking I need to write a test plan to follow exactly on each Pi to assure uniformity in testing. I'll probably post it here for comment before doing the testing. Any additional suggestions are welcome.

Bob

[BobHamil]

Here is my testing plan:

I plan to test the Pi4's in this order: 1gb, 2gb, 4gb, 4gb with "total_mem=2048" added to config.txt. I plan to run all tests bidirectional simultaneously. I will have a monitor and keyboard connected. If the speeds on the 2gb improve after firmware upgrades, I may stop testing at that point.

1 Turn on ufw and connect to internet then run apt update/upgrade
2 Disconnect from internet and sudo ufw disable
3 Run uname -a | tee unameXgb.txt ; vcgencmd get_mem | tee -a unameXgb.txt
4 Start iperf3 -s on Pi4Xgb and laptop
5 Connect eth0 to laptop and run iperf3 -u -b 0 -c x.x.x.x -t 30 | tee eth0-LapXgb.txt and iperf3 -u -b 0 -c x.x.x.x -t 30 | tee Lap-eth0Xgb.txt
6 Add usb nic to Pi4Xgb usb3 port and connect eth1 to laptop and run iperf3 -u -b 0 -c x.x.x.x -t 30 | tee eth1-LapXgb.txt and iperf3 -u -b 0 -c x.x.x.x -t 30 | tee Lap-eth1Xgb.txt
7 Connect eth0 to eth1 and run iperf3 -u -b 0 -c x.x.x.x -t 30 | tee eth0-eth1Xgb.txt and iperf3 -u -b 0 -c x.x.x.x -t 30 | tee eth1-eth0Xgb.txt
8 Connect eth1 to laptop and ssh into Pi4 and collect the .txt's


Any other ideas??

I'm going to go for a walk, and when I come back, decide if I'm doing all this yet tonight, so there may be plenty of time for people to make suggestions about this plan.

Bob

[ejolson]

Here is my testing plan:

I plan to test the Pi4's in this order: 1gb, 2gb, 4gb, 4gb with "total_mem=2048" added to config.txt. I plan to run all tests bidirectional simultaneously. I will have a monitor and keyboard connected. If the speeds on the 2gb improve after firmware upgrades, I may stop testing at that point.

1 Turn on ufw and connect to internet then run apt update/upgrade
2 Disconnect from internet and sudo ufw disable
3 Run uname -a | tee unameXgb.txt ; vcgencmd get_mem | tee -a unameXgb.txt
4 Start iperf3 -s on Pi4Xgb and laptop
5 Connect eth0 to laptop and run iperf3 -u -b 0 -c x.x.x.x -t 30 | tee eth0-LapXgb.txt and iperf3 -u -b 0 -c x.x.x.x -t 30 | tee Lap-eth0Xgb.txt
6 Add usb nic to Pi4Xgb usb3 port and connect eth1 to laptop and run iperf3 -u -b 0 -c x.x.x.x -t 30 | tee eth1-LapXgb.txt and iperf3 -u -b 0 -c x.x.x.x -t 30 | tee Lap-eth1Xgb.txt
7 Connect eth0 to eth1 and run iperf3 -u -b 0 -c x.x.x.x -t 30 | tee eth0-eth1Xgb.txt and iperf3 -u -b 0 -c x.x.x.x -t 30 | tee eth1-eth0Xgb.txt
8 Connect eth1 to laptop and ssh into Pi4 and collect the .txt's


Any other ideas??

I'm going to go for a walk, and when I come back, decide if I'm doing all this yet tonight, so there may be plenty of time for people to make suggestions about this plan.

Bob

I would suggest comparing the 64-bit kernel to the LPAE kernel on the 2GB and 4GB models. I think this is accomplished with a flag in config.txt and then rebooting as the needed kernels should be already on your SD card.

[BobHamil]

ejolson,
"comparing the 64-bit kernel to the LPAE kernel on the 2GB and 4GB models"
I don't know about this, and web searches are not enlightening me. I don't see any mention in config.txt docs.

Can you explain more, or direct me to links?
Bob

[ejolson]

Can you explain more, or direct me to links?
Bob

The instructions appear in the thread

viewtopic.php?t=250730

[BobHamil]

Ok there is a lot there I read, but I'm tired. It seems easier to ask than figure it out.
I see that I can run rpi-update while connected to the internet, and add arm_64bit=1 to config.txt then reboot.
Do I do both? I gather from your post I may only need arm_64bit=1.

So I think you mean I'd do the testing as my plan describes, then make one or both changes and repeat on the 2gb and 4gb?
I'm going to bed and will do more on this later tomorrow.
Thanks, bob

[PhilE]

ejolson can explain his own requirements - I just want to know the outcome of:

but before then you could try adding "total_mem=2048" to config.txt on the card used by the 4GB Pi - that should restrict it to the first 2GB of RAM, making it effectively a 2GB board.

[BobHamil]

Ok first results are in for Pi41gb.
Three sets of tests - plain latest updated BusterLite, add arm_64bit=1 to config.txt, rpi-update run
First, I have to say I've seen other results on here from iper3 testing that doesn't get any errors. I'm always getting small amounts of errors - I don't know what that difference would be... Most of the test will be in the 900's, but for a couple seconds of the test, thurpt drops to 600's and there are 1-10% errors, then goes back to full speed w/o errors.

I have test files of all the tests I can post if wanted, but the quick summary is:
updated BusterLite runs in 900's both ways
add arm_64bit=1 to config.txt, runs in 900's both ways
rpi-update rec in 900's, but tx only in the 700's.

Here are the three uname -a results

Linux pi1 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux
total used free shared buff/cache available
Mem: 946636 67696 784304 12292 94636 810548
Swap: 102396 0 102396

Linux pi1 4.19.97-v8+ #1294 SMP PREEMPT Thu Jan 30 13:27:08 GMT 2020 aarch64 GNU/Linux
total used free shared buff/cache available
Mem: 938604 67836 774500 6304 96268 809136
Swap: 102396 0 102396

Linux pi1 4.19.108-v8+ #1298 SMP PREEMPT Fri Mar 6 18:15:51 GMT 2020 aarch64 GNU/Linux
total used free shared buff/cache available
Mem: 938160 69832 769464 6304 98864 806528
Swap: 102396 0 102396

Here it the test plan I'm generally managing to follow:

1 Turn on ufw and connect to internet then run apt update/upgrade
2 Disconnect from internet and sudo ufw disable
3 Run uname -a | tee unameXgb.txt ; free | tee -a unameXgb.txt
4 Start iperf3 -s on Pi4Xgb and laptop
5 Connect eth0 to laptop and run iperf3 -u -b 0 -c x.x.x.x -t 30 | tee eth0-LapXgb.txt and iperf3 -u -b 0 -c x.x.x.x -t 30 | tee Lap-eth0Xgb.txt
6 Add usb nic to Pi4Xgb usb3 port and connect eth1 to laptop and run iperf3 -u -b 0 -c x.x.x.x -t 30 | tee eth1-LapXgb.txt and iperf3 -u -b 0 -c x.x.x.x -t 30 | tee Lap-eth1Xgb.txt

7 add arm_64bit=1 to config.txt then reboot

8 Run uname -a | tee 64unameXgb.txt ; free | tee -a 64unameXgb.txt
9 Start iperf3 -s on Pi4Xgb and laptop
10 Connect eth0 to laptop and run iperf3 -u -b 0 -c x.x.x.x -t 30 | tee 64eth0-LapXgb.txt and iperf3 -u -b 0 -c x.x.x.x -t 30 | tee 64Lap-eth0Xgb.txt
11 Add usb nic to Pi4Xgb usb3 port and connect eth1 to laptop and run iperf3 -u -b 0 -c x.x.x.x -t 30 | tee 64eth1-LapXgb.txt and iperf3 -u -b 0 -c x.x.x.x -t 30 | tee 64Lap-eth1Xgb.txt

12 Turn on ufw and connect to internet then run rpi-update
13 Disconnect from internet and sudo ufw disable

14 Run uname -a | tee rpi64unameXgb.txt ; free | tee -a rpi64unameXgb.txt
15 Start iperf3 -s on Pi4Xgb and laptop
16 Connect eth0 to laptop and run iperf3 -u -b 0 -c x.x.x.x -t 30 | tee rpi64eth0-LapXgb.txt and iperf3 -u -b 0 -c x.x.x.x -t 30 | tee rpi64Lap-eth0Xgb.txt
17 Add usb nic to Pi4Xgb usb3 port and connect eth1 to laptop and run iperf3 -u -b 0 -c x.x.x.x -t 30 | tee rpi64eth1-LapXgb.txt and iperf3 -u -b 0 -c x.x.x.x -t 30 | tee rpi64Lap-eth1Xgb.txt


Phil, I will do your pi4$gb mem=2048 tests first and get you the results
Bob

[BobHamil]

BINGO!!!!!!!!!!!!!!!!!!!1

sudo apt upgrade which has firmware solves the problem with the Pi42gb!!

950ish both ways simultaneous.

Is more testing needed?
I'll post the test files in second post.
Bob

[PhilE]

950ish both ways simultaneous.

Is more testing needed?

No - the issue is closed as far as I'm concerned. You can add a "[SOLVED]" to the topic subject.

[BobHamil]

PhilE,
Is whomever it may matter to going to note the degradation in tx speed on the Pi41gb after rpi-update?
Bob

[PhilE]

Is whomever it may matter to going to note the degradation in tx speed on the Pi41gb after rpi-update?

So far there's one board that has one bad patch while testing, so not much to go on. Are they now all running the same images with the same EEPROM version?