RPi 3B+ gigabit ethernet bad download speeds.

[tkaiser]

But youtube performance on chromium is better on RPi3B+.

Can we please focus on Raspberry Pi Ethernet problem here? You're the one running in retransmits in one direction. You can reproduce this easily. So it would be great if you could help nailing the problem down. Trying out whether EEE is involved or not is more or less copy&paste of the instructions I posted yesterday.

BTW: If you want HW accelerated video decoding on your Tinkerboard you might want to switch from TinkerOS kernel to Armbian's kernel (using Rockchip's official 4.4 kernel and not the ASUS thing) and follow this tutorial: https://forum.armbian.com/topic/6506-tu ... lt-kernel/ (but please let us focus here on Raspberries!)

[RPIgoodSBC]

Sorry I don't have much time sometimes, here goes the new test:

---

Code: Select all

sudo apt-get install device-tree-compiler

Code: Select all

cd /boot

Code: Select all

cp bcm2710-rpi-3-b-plus.dtb bcm2710-rpi-3-b-plus.dtb.bak

Code: Select all

sudo cp bcm2710-rpi-3-b-plus.dtb bcm2710-rpi-3-b-plus.dtb.bak

Code: Select all

sudo dtc -I dtb -O dts -o bcm2710-rpi-3-b-plus.dts bcm2710-rpi-3-b-plus.dtb

Code: Select all

sudo leafpad bcm2710-rpi-3-b-plus.dts

Do a search in leafpad ... eee-enabled and uncommented this 2 lines:

line 423...
#microchip,eee-enabled;
line 734...
#eee = "", "", "", "!microchip,eee-enabled?";

Code: Select all

sudo dtc -I dts -O dtb -o bcm2710-rpi-3-b-plus.dtb bcm2710-rpi-3-b-plus.dts

Output terminal:

bcm2710-rpi-3-b-plus.dtb: Warning (unit_address_vs_reg): Node /soc has a reg or ranges property, but no unit name
bcm2710-rpi-3-b-plus.dtb: Warning (unit_address_vs_reg): Node /soc/axiperf has a reg or ranges property, but no unit name
bcm2710-rpi-3-b-plus.dtb: Warning (unit_address_vs_reg): Node /soc/gpiomem has a reg or ranges property, but no unit name
bcm2710-rpi-3-b-plus.dtb: Warning (unit_address_vs_reg): Node /soc/vchiq has a reg or ranges property, but no unit name
bcm2710-rpi-3-b-plus.dtb: Warning (unit_address_vs_reg): Node /soc/local_intc has a reg or ranges property, but no unit name
bcm2710-rpi-3-b-plus.dtb: Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name

---

Reboot and testing...

pi@raspberrypi:~ $ speedtest-cli
Retrieving speedtest.net configuration...
Testing from R Cable y Telecomunicaciones Galicia, S.A. (XX.XX.XX.XX)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by NOS (Porto) [247.07 km]: 30.025 ms
Testing download speed................................................................................
Download: 37.76 Mbit/s
Testing upload speed....................................................................................................
Upload: 19.57 Mbit/s
pi@raspberrypi:~ $ sudo ethtool -s eth0 speed 100 duplex full
pi@raspberrypi:~ $ speedtest-cli
Retrieving speedtest.net configuration...
Testing from R Cable y Telecomunicaciones Galicia, S.A. (XX.XX.XX.XX)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by NOS (Porto) [247.07 km]: 31.261 ms
Testing download speed................................................................................
Download: 86.15 Mbit/s
Testing upload speed....................................................................................................
Upload: 19.57 Mbit/s

No change nothing.
Better on 100 mode than on 1000 mode.

Must I will revert the done configuration?

---
Problem seems to appear on ISP asimetric connections mine is 200/20 and HermannSW have 400/20?

[RPIgoodSBC]

But youtube performance on chromium is better on RPi3B+.

Can we please focus on Raspberry Pi Ethernet problem here? You're the one running in retransmits in one direction. You can reproduce this easily. So it would be great if you could help nailing the problem down. Trying out whether EEE is involved or not is more or less copy&paste of the instructions I posted yesterday.

BTW: If you want HW accelerated video decoding on your Tinkerboard you might want to switch from TinkerOS kernel to Armbian's kernel (using Rockchip's official 4.4 kernel and not the ASUS thing) and follow this tutorial: https://forum.armbian.com/topic/6506-tu ... lt-kernel/ (but please let us focus here on Raspberries!)

Test done see above.
Yes I run armbian too good performance but no strech system and kodi is 15 not 17.But I like it too.
I have HW accelerated video decoding on armbian too.

[RPIgoodSBC]

---> jamesh

I'm still not sure what this has to do with the Raspberry Pi 3B+ ethernet speed. You seem to be running on the TB, an entirely different device with entirely different ethernet and wireless chips.

Nothing, an offtopic.
This only happens to me when try to solving the problem and I believe relevant comment.
But show us that my ISP connection is not the problem.
iperf3 runs perfect on my ISP over ethernet gigabit Tinkerboard.
The problem is on raspbian and my RPi3B+.

[tkaiser]

Problem seems to appear on ISP asimetric connections mine is 200/20 and HermannSW have 400/20?

I really don't know what you're doing with this speedtest thing. Again: https://www.performancevision.com/blog/ ... cket-loss/

If you have retransmits / packet loss then those will limit throughput based on latency. That's why a TCP/IP connection to 'somewhere on the Internet' can show a way lower throughput compared to 'somewhere on the local network' if you're suffering from retransmits. Without keeping this in mind (TCP/IP congestion) you will have a hard time explaining numbers. And you still need to get rid of the retransmits.

No idea how the kernel code deals with the eee DT property missing (maybe it defaults then to 'on', maybe not). But since the preferred mode here to deal with problems is to ignore them and to move on to something different I'll do this now too

[jamesh]

Problem seems to appear on ISP asimetric connections mine is 200/20 and HermannSW have 400/20?

I really don't know what you're doing with this speedtest thing. Again: https://www.performancevision.com/blog/ ... cket-loss/

If you have retransmits / packet loss then those will limit throughput based on latency. That's why a TCP/IP connection to 'somewhere on the Internet' can show a way lower throughput compared to 'somewhere on the local network' if you're suffering from retransmits. Without keeping this in mind (TCP/IP congestion) you will have a hard time explaining numbers. And you still need to get rid of the retransmits.

No idea how the kernel code deals with the eee DT property missing (maybe it defaults then to 'on', maybe not). But since the preferred mode here to deal with problems is to ignore them and to move on to something different I'll do this now too

Wow, just cannot stop themselves, so I have to do it for them.

[RPIgoodSBC]

Does anyone know another linux system that can run on RPi3B + with ethernet enabled so I can try it out and see if the problem is the raspbian ethernet kernel driver?

This way we will know how to perform speedtest-cli on RPi3B+ same hardware but different kernel system.
If speedtest-cli is up 100 download speeds then definitely is Raspbian kernel problem.

[RaTTuS]

this is on a fresh raspbian lite FYI / comparison

Code: Select all

./speedtest-cli
Retrieving speedtest.net configuration...
Testing from ....
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Spitfire Network Services (London) [9.61 km]: 15.453 ms
Testing download speed................................................................................
Download: 220.56 Mbit/s
Testing upload speed................................................................................................
Upload: 260.36 Mbit/s

[RPIgoodSBC]

this is on a fresh raspbian lite FYI / comparison

Code: Select all

./speedtest-cli
Retrieving speedtest.net configuration...
Testing from ....
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Spitfire Network Services (London) [9.61 km]: 15.453 ms
Testing download speed................................................................................
Download: 220.56 Mbit/s
Testing upload speed................................................................................................
Upload: 260.36 Mbit/s

Thanks for test.

Do you have a symmetric connection same up and down?.Your ping is more good than mine.
But how many is your ISP up/down?
Can you test iperf3?

You are loosing 40 Mbit/s on download versus upload.

[jamesh]

I've been taking a look at this.

Doing a large download (wget downloads.raspberrypi.org/raspbian_latest) I do get issues with routing being reset. However, whilst that affects the entire download, the instantaneous speed seems to be about 85Mbits/s. I suspect this is a limitation of our uplink in the office - 10MBytes/s or thereabouts. So.....

Tried a rsync between a Pi and a Ubuntu Box in a VM, I do get instantaneous speeds above the 100base speed, upto to 200Mbits/s. But I still get occasional drops outs on the link, which is my main concern. Doing the sync the other ways, Ubuntu pulling from Pi, no issues. So it appears to be a RX problem on the Pi. I see no dropped packets.

Currently trying to up the message level in the lan78xx driver to see if it knows what is going on. Definitely seems to be something awry somewhere.

[RPIgoodSBC]

---> jamesh

So it appears to be a RX problem on the Pi.

OK.
If you have some new compilation of raspbian with a new ethernet driver even beta tell me and try it.

[jamesh]

---> jamesh

So it appears to be a RX problem on the Pi.

OK.
If you have some new compilation of raspbian with a new ethernet driver even beta tell me and try it.

I've not made any changes. Still trying to determine what the issue might be. These things can take a while.

[RPIgoodSBC]

This can help to solve the problem...
Pay attention:

RPi3B+ internal gigabit NIC...

pi@raspberrypi:~ $ sudo iperf3 -c XXX.XXX.X.XXX ... sending from pi to my big PC

Connecting to host big PC, port 5201
[ 4] local RPi3B+ port 54914 connected to big PC port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 37.9 MBytes 318 Mbits/sec 0 257 KBytes
[ 4] 1.00-2.00 sec 37.7 MBytes 316 Mbits/sec 0 270 KBytes
[ 4] 2.00-3.00 sec 37.8 MBytes 317 Mbits/sec 0 284 KBytes
[ 4] 3.00-4.00 sec 37.7 MBytes 316 Mbits/sec 0 298 KBytes
[ 4] 4.00-5.00 sec 37.5 MBytes 314 Mbits/sec 0 317 KBytes
[ 4] 5.00-6.00 sec 37.7 MBytes 316 Mbits/sec 0 317 KBytes
[ 4] 6.00-7.00 sec 37.7 MBytes 316 Mbits/sec 0 331 KBytes
[ 4] 7.00-8.00 sec 37.7 MBytes 316 Mbits/sec 0 349 KBytes
[ 4] 8.00-9.00 sec 37.6 MBytes 315 Mbits/sec 0 387 KBytes
[ 4] 9.00-10.00 sec 37.7 MBytes 316 Mbits/sec 0 387 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 377 MBytes 316 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 376 MBytes 315 Mbits/sec receiver

iperf Done.

pi@raspberrypi:~ $ sudo iperf3 -c XXX.XXX.X.XXX -R

Connecting to host big PC, port 5201
Reverse mode, remote host big PC is sending
[ 4] local RPi3B+ port 54918 connected to big PC port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 27.2 MBytes 228 Mbits/sec
[ 4] 1.00-2.00 sec 27.1 MBytes 227 Mbits/sec
[ 4] 2.00-3.00 sec 27.0 MBytes 227 Mbits/sec
[ 4] 3.00-4.00 sec 27.3 MBytes 229 Mbits/sec
[ 4] 4.00-5.00 sec 25.6 MBytes 214 Mbits/sec
[ 4] 5.00-6.00 sec 25.0 MBytes 209 Mbits/sec
[ 4] 6.00-7.00 sec 26.1 MBytes 219 Mbits/sec
[ 4] 7.00-8.00 sec 25.9 MBytes 217 Mbits/sec
[ 4] 8.00-9.00 sec 25.0 MBytes 210 Mbits/sec
[ 4] 9.00-10.00 sec 26.2 MBytes 220 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 262 MBytes 220 Mbits/sec 3281 sender
[ 4] 0.00-10.00 sec 262 MBytes 220 Mbits/sec receiver

iperf Done.

Now:

RPi3B+ USB 3.0 hub with gigabit NIC lsmod reports ax88179_178a kernel module...
RPi3B+ internal gigabit NIC is now down.

pi@raspberrypi:~ $ sudo iperf3 -c XXX.XXX.X.XXX ... sending from pi to my big PC

Connecting to host big PC, port 5201
[ 4] local RPi3B+ port 54016 connected to big PC port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 21.7 MBytes 182 Mbits/sec 0 38.2 KBytes
[ 4] 1.00-2.00 sec 21.8 MBytes 183 Mbits/sec 0 42.4 KBytes
[ 4] 2.00-3.00 sec 21.8 MBytes 183 Mbits/sec 0 45.2 KBytes
[ 4] 3.00-4.00 sec 21.6 MBytes 181 Mbits/sec 0 69.3 KBytes
[ 4] 4.00-5.00 sec 21.6 MBytes 181 Mbits/sec 0 69.3 KBytes
[ 4] 5.00-6.00 sec 21.7 MBytes 182 Mbits/sec 0 103 KBytes
[ 4] 6.00-7.00 sec 21.8 MBytes 183 Mbits/sec 0 156 KBytes
[ 4] 7.00-8.00 sec 22.0 MBytes 184 Mbits/sec 0 156 KBytes
[ 4] 8.00-9.00 sec 22.1 MBytes 185 Mbits/sec 0 233 KBytes
[ 4] 9.00-10.00 sec 21.9 MBytes 184 Mbits/sec 0 233 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 218 MBytes 183 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 217 MBytes 182 Mbits/sec receiver

iperf Done.

pi@raspberrypi:~ $ sudo iperf3 -c XXX.XXX.X.XXX -R

Connecting to host big PC, port 5201
Reverse mode, remote host big PC is sending
[ 4] local RPi3B+ port 54020 connected to big PC port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 20.3 MBytes 170 Mbits/sec
[ 4] 1.00-2.00 sec 20.6 MBytes 173 Mbits/sec
[ 4] 2.00-3.00 sec 20.8 MBytes 174 Mbits/sec
[ 4] 3.00-4.00 sec 20.6 MBytes 173 Mbits/sec
[ 4] 4.00-5.00 sec 20.5 MBytes 172 Mbits/sec
[ 4] 5.00-6.00 sec 20.3 MBytes 170 Mbits/sec
[ 4] 6.00-7.00 sec 20.6 MBytes 173 Mbits/sec
[ 4] 7.00-8.00 sec 21.0 MBytes 176 Mbits/sec
[ 4] 8.00-9.00 sec 19.3 MBytes 162 Mbits/sec
[ 4] 9.00-10.00 sec 20.7 MBytes 174 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 205 MBytes 172 Mbits/sec 3368 sender
[ 4] 0.00-10.00 sec 205 MBytes 172 Mbits/sec receiver

iperf Done.

---

We can see that ethernet gigabit usb adapter (ax88179_178a kernel module) performs a little less than internal gigabit adapter RPi3B+.
But both internal and external gigabits NIC on RPi3B+ have RX loss packets to show us Retr column.
Then, lan78xx kernel driver is not the problem.The same problem exists with ax88179_178a lan kernel module.
Same problem on old RPi3B not plus latest raspbian OS.

Then... the problem is on Raspbian kernel.

---
Same net, same cable, same router port, and iperf3 test from tinkerboard to big PC and back.
0 Retr sending and receiving.Then no hardware problem on my net in all test in this thread.Problem appears using RPi.

iperf3-on-tinkerboard-on-same-net-cable-router-port-that-rpi3b-plus-before-tested.png (228.8 KiB) Viewed 8042 times

[jamesh]

Bit confused. There doesn't seem to be anything wrong with those performance numbers - why do you think they are slow? >300Mbits/s seems very good.

[RPIgoodSBC]

Bit confused. There doesn't seem to be anything wrong with those performance numbers - why do you think they are slow? >300Mbits/s seems very good.

Yes sending on iperf3 is good but not receiving.That is on the problem is.

Retr column is showing 3281 Retr when RPi3B+ is receiving and 0 Retr when is sending.
Both the internal gigabit and testing with an external gigabit USB.

So it appears to be a RX problem on the Pi.

RX problem is receiving packets not?

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 262 MBytes 220 Mbits/sec 3281 sender
[ 4] 0.00-10.00 sec 262 MBytes 220 Mbits/sec receiver

220 Mbits/sec receiving with a lot of retransmits packets.3281

And don't forget that I can not achieve more than 40 Mbits/sec average with gigabit internal or external card on 1000 mode.

I am wrong?

[jamesh]

I am wrong?

No idea, still investigating a router drop out issue that I get when doing large wget's on the PI3B+. Might be related, might not. The lan78xx driver is getting an interrupt from the device (via USB as that is how it is connect) which claims link broken, but there seems to be no reason why this might be the case. The time taken to reestablish the link does seem to be affect the overall throughput quite badly. Since it happens only 3 or 4 times over a 1.2GB wget, I suspect iperf does not run long enough to encounter the problem.

[Bruny]

RX problem is receiving packets not?

Code: Select all

[ ID]	 Interval 	Transfer 	Bandwidth 	Retr
[ 4] 	0.00-10.00 sec 	262 MBytes 	220 Mbits/sec 	3281	 sender
[ 4] 	0.00-10.00 sec 	262 MBytes 	220 Mbits/sec 		receiver

It seems to be related to firmware?
#1954

[RaTTuS]

on 3 of my pi :-
dropped rx packets showing ,

Code: Select all

uprecords ;cat /sys/firmware/devicetree/base/model ; echo; ifconfig
     #               Uptime | System                                     Boot up
----------------------------+---------------------------------------------------
->   1   195 days, 17:56:40 | Linux 4.9.41+             Wed Sep 13 17:19:50 2017
     2    11 days, 20:21:59 | Linux 4.9.41+             Fri Sep  1 11:34:26 2017
     3     0 days, 08:31:32 | Linux 4.9.41+             Wed Sep 13 08:16:52 2017
----------------------------+---------------------------------------------------
NewRec   183 days, 21:34:40 | since                     Mon Sep 25 13:41:49 2017
    up   207 days, 22:50:11 | since                     Fri Sep  1 11:34:26 2017
  down     0 days, 00:51:53 | since                     Fri Sep  1 11:34:26 2017
   %up               99.983 | since                     Fri Sep  1 11:34:26 2017
Raspberry Pi Model B Rev 1
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.8.31  netmask 255.255.224.0  broadcast 192.168.31.255
        ether b8:27:eb:4e:05:8d  txqueuelen 1000  (Ethernet)
        RX packets 469562900  bytes 2993170528 (2.7 GiB)
        RX errors 0  dropped 35650  overruns 0  frame 0
        TX packets 261864919  bytes 1918101123 (1.7 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 518  bytes 78391 (76.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 518  bytes 78391 (76.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Code: Select all

uprecords ;cat /sys/firmware/devicetree/base/model ; echo; ifconfig
     #               Uptime | System                                     Boot up
----------------------------+---------------------------------------------------
     1   202 days, 00:21:13 | Linux 4.1.18-v7+          Wed Sep 28 09:51:31 2016
->   2   196 days, 02:20:57 | Linux 4.9.41-v7+          Wed Sep 13 08:55:48 2017
     3   100 days, 23:20:18 | Linux 4.1.18-v7+          Wed Apr  6 15:16:12 2016
     4    72 days, 02:16:53 | Linux 4.1.18-v7+          Mon Jul 18 07:15:50 2016
     5    36 days, 20:24:28 | Linux 4.9.24-v7+          Tue Jun  6 11:44:02 2017
     6    34 days, 22:37:11 | Linux 4.9.24-v7+          Tue May  2 12:45:16 2017
     7    22 days, 21:30:13 | Linux 4.1.18-v7+          Tue Mar  8 12:29:53 2016
     8    17 days, 21:01:04 | Linux 4.9.41-v7+          Thu Aug 24 11:10:21 2017
     9    15 days, 02:16:14 | Linux 4.9.35-v7+          Tue Jul 18 10:24:41 2017
    10    14 days, 22:09:14 | Linux 4.9.35-v7+          Wed Aug  2 12:42:27 2017
----------------------------+---------------------------------------------------
no1 in     5 days, 22:00:17 | at                        Tue Apr  3 09:17:01 2018
    up   749 days, 12:00:02 | since                     Wed Mar  2 12:57:51 2016
  down     6 days, 09:18:52 | since                     Wed Mar  2 12:57:51 2016
   %up               99.155 | since                     Wed Mar  2 12:57:51 2016
Raspberry Pi 3 Model B Rev 1.2
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.8.39  netmask 255.255.224.0  broadcast 192.168.31.255
        inet6 fe80::ef72:a3ba:9af5:2c43  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:ab:5c:27  txqueuelen 1000  (Ethernet)
        RX packets 241522786  bytes 1011397213 (964.5 MiB)
        RX errors 0  dropped 3992  overruns 0  frame 0
        TX packets 1575327  bytes 678364385 (646.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 83  bytes 9158 (8.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 83  bytes 9158 (8.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether b8:27:eb:fe:09:72  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Code: Select all

uprecords ;cat /sys/firmware/devicetree/base/model ; echo; ifconfig
     #               Uptime | System                                     Boot up
----------------------------+---------------------------------------------------
->   1     7 days, 03:59:05 | Linux 4.9.80-v7+          Wed Mar 21 06:17:41 2018
     2     0 days, 18:00:07 | Linux 4.9.80-v7+          Mon Mar 19 11:16:58 2018
     3     0 days, 11:00:08 | Linux 4.9.80-v7+          Tue Mar 20 09:24:45 2018
     4     0 days, 01:54:35 | Linux 4.9.80-v7+          Fri Mar 16 11:45:48 2018
     5     0 days, 01:04:09 | Linux 4.9.80-v7+          Fri Mar 16 14:05:47 2018
----------------------------+---------------------------------------------------
NewRec     6 days, 09:58:57 | since                     Thu Mar 22 00:17:49 2018
    up     8 days, 11:58:04 | since                     Fri Mar 16 11:45:48 2018
  down     3 days, 10:32:54 | since                     Fri Mar 16 11:45:48 2018
   %up               71.189 | since                     Fri Mar 16 11:45:48 2018
Raspberry Pi 3 Model B Plus Rev 1.3
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.8.41  netmask 255.255.224.0  broadcast 192.168.31.255
        inet6 fe80::dac7:bc8b:50a7:3496  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:3d:c1:8c  txqueuelen 1000  (Ethernet)
        RX packets 11837165  bytes 933479967 (890.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1689799  bytes 2819569740 (2.6 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether b8:27:eb:68:94:d9  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[ejolson]

on 3 of my pi :-
dropped rx packets showing

That's right. Dropped packets are expected. With modern Linux kernels dropped packets usually refer to IPv6 packets and others that were received but not processed. It's retransmits which are the problem.

I think I've seen similar issues when placing a Gbit Ethernet card on the 33 Mhz PCI bus of an early Pentium 4 computer. Strange things can happen with TCP/IP throughput over buffered high-latency interconnects when you can't receive packets at wire speed.

[Kamera]

I am not an expert but the issue I am having seems related.

Using updated Raspbian stretch lite (I have also tried Raspbian stretch) media streaming and samba shares over cat6 ethernet from USB drives on the Pi3B+ pause seemingly randomly, sometimes for a short time and resuming, other times for a long time and not resuming.

Hoping an update will fix.

[jamesh]

Can those people experiencing drop outs or odd delays during downloads or copies, please try the following.

In config.txt, add the line

Code: Select all

dtparam=eee=off

And report back if the problem goes away.

[RPIgoodSBC]

---> RaTTuS

I can not see any problem in your code related.
Command ifconfig is no the right tool to see this problem.
I have similar output than you ifconfig related.

You need to use iperf3 over your cable net to other PC and look at retransmits.

That must be 0 in a good cable net hardware configuration.
Retransmits is about receiving packets not sending.
Sending you can not loose nothing.I am right?.
The loss is on the hardware that is receiving.

Easy HOWTO iperf3:

On your RPi3B+

sudo ifconfig

and note the inet ip XXX.XXX.X.XXX...RPi3B+ (not needed in this test)

On your other PC ethernet cable connected to the pi for gigabit switch do the same.
If you only have one monitor you can plug and unplug hdmi or better commuting in monitor to output PC or RPi3B+ to see.
You need keyboard and mouse for PC and keyboard and mouse for RPi3B+.

And note the inet ip YYY.YYY.Y.YYY ... PC

On your other PC in linux terminal; of course you must be installed iperf3 in your PC system, Linux Mint for example.

iperf3 -s

Now on RPi3B+

iperf3 -c YYY.YYY.Y.YYY ...Now your PC is receiving and retr column must be 0 on a good network.

Now reverse mode from PC to pi...

iperf3 -c YYY.YYY.Y.YYY -R ... Now the retr column show us the lost packets that must be 0 too on a good net cable.
But RPi3B+ on receiving mode from PC is losing a lot of packets about 3000 average on mi pi...

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 267 MBytes 224 Mbits/sec 3388 sender
[ 4] 0.00-10.00 sec 266 MBytes 224 Mbits/sec receiver

iperf Done.

Understand?

The problem on RPi3B+ is on receiving and iperf3 show us that very clear.
For this reason in this thread all people have better upload speedtest-cli speeds than download speeds.
Because the problem is on receiving and how the Raspbian kernel is doing about usb staff and receiving packets on a net cable.

[RPIgoodSBC]

Can those people experiencing drop outs or odd delays during downloads or copies, please try the following.

In config.txt, add the line

Code: Select all

dtparam=eee=off

And report back if the problem goes away.

I am going to test it now.

[RPIgoodSBC]

Can those people experiencing drop outs or odd delays during downloads or copies, please try the following.

In config.txt, add the line

Code: Select all

dtparam=eee=off

And report back if the problem goes away.

No change nothing an this was tested in other way in this thread.
Here the results now:

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 268 MBytes 225 Mbits/sec 3494 sender
[ 4] 0.00-10.00 sec 268 MBytes 225 Mbits/sec receiver

iperf Done.

pi@raspberrypi:~ $ speedtest-cli

Testing download speed................................................................................
Download: 36.54 Mbit/s
Testing upload speed....................................................................................................
Upload: 19.60 Mbit/s


Is kernel related problem not a driver problem.This happens no matter driver we are using on ethernet usb or internal.

This problem is old but I can see now because gigabit NIC performs very bad on 1000 mode 40 Mbit/s download speeds average, and in 100 mode 80 Mbit/s download speeds average with speedtest-cli.
And this has led me to try iperf3 which is the one that clearly shows us the problem.

[jamesh]

I wasn't expecting much change in overall speed performance, I've not seen improvements by turning off eee. What I have seen is that the number of drop outs went from 5 or 6 per 1.5GB transfer down to zero. So I am expecting the link to be more robust, but not faster.

When we have tested for speed in the office, we definitely see a major improvement on internal transfers for the 3B+, but we cannot check internet speed because our office link is capped at 100Mbits/s, so both the B and B+ hit about the same speed.

And a quick lesson on definitions. The Linux kernel is monolithic, this means that drivers are inherently part of the kernel (even if loaded as a module, but the lan78xx is built in anyway), so there is no real distinction between being a kernel problem and a driver problem. A driver problem IS a kernel problem.