Normal pings are less than 1500, try
$ ping -s 8000 {anywhere on the internet}
You can’t send packets larger than what the next hop can handle.
Yeah, that didn’t work.
I can ping with size 8000 on all my devices connected to the switch, though…
Is there any way for me to fix this, or should I just roll it back? My router, ancient monstrosity that it is, does not let me adjust the MTU at all in “automatic” mode.
No, there is no way to go from 9000 to 1500. The packets must originate with the correct max size.
With two network adapters you can multi-home and run two networks, a private one with jumbo packets for data and internal communication and another one for communicating to the outside world.
I’m a bit confused about why I can still access the internet, though. My Mac’s ethernet port is set for MTU 9000, which the switch can handle. I’m posting from there right now.
I’m not having any issue accessing the internet at all.
Is the issue that I won’t be able to access devices on the switch from outside the switch?
MTU is negotiable, maybe it does work. Keep me posted.
What should I not be able to do if I’ve got an MTU problem? That might help me focus my testing.
At the moment I’m also trying to figure out why my NAS write speed is so low, but that could be a SMB configuration issue.
Basically poor network performance between two network interfaces that have mismatching MTU sizes. And that would include two internal interfaces of a router. You can have dropped packets, fragmentation, packet re-transmissions and hung connections due to fragmented packets.
I’m guessing that’s why the reading I’ve done emphasizes making sure everything on the same switch has the same MTU.
Does it apply to WiFi, too?
In any case, it sounds like I should just leave it at 1500 MTU to be safe. I’m not doing 10Gbps networking yet–I’ve only got one server that can handle it, and the next fastest thing is a 5 Gbps NAS–so the only real advantage is the reduced CPU usage on the Pi when the network is going full tilt.
Yes, pretty sure MTU applies to all ethernets.
I’ve set everything back to 1500 MTU for now. I’m not hitting the Pi hard enough to worry about pegging one core. 
@0n0w1c , very anecdotally (I only did one test, because it’s midnight here), I lots about 10 MB/s transfer from a very high bandwidth remote server with jumbo frames turned on.
If my connection stays in place overnight, I’ll consider this working aside from the loss of LightDM, which I’m guessing is because this is an older, patched kernel.
If my connection goes down, I’m going to have to look harder at/get some help with the Udev rule to get that auto-suspend thing to turn off.
I’ll also update with whether or not I can get both the NVME and the USB 3 ethernet adapter both using USB 3.0 once I’ve got the powered hub.
I’m really happy with how this came out. Thanks again, @Darksky .
@Darksky ,
Good morning. I’ve been experimenting a bit more with the inability to boot off an SSD while using the USB ethernet adapter in a USB 3.0 port.
With the boot SSD still plugged into the USB 2.0 port, I left a powered USB 3.0 4-port hub plugged in to the USB 3.0 port overnight, with one USB 3.0 thumb drive and one USB 2.0 thumb drive plugged in to the hub.
Everything was fine when I walked away from the computer around 1 AM, but after I had gone to bed the SSH connection died around 2 AM.
When I woke up and tried to reboot the Pi, I had no luck until I unplugged the USB 3.0 hub.
So:
- Whether the USB 3.0 ports are drawing power from the Pi or the wall appears to make no difference;
- Something about trying to boot made it instantly fail, but it held out an hour or so before it died when it wasn’t booting off the attached USB 3.0 drive.
- I’m not sure what to make of the Pi not being able to boot when nothing was plugged into the USB 3.0 hub and the SSD was still plugged into the USB 2 port on the Pi.
Are there logs I could look at that might be helpful?
This weekend, after I’ve waded through a bunch of filing deadlines at work, I’m going to burn a new SD card with the latest Manjaro minimal install, and boot off that, and try USB adapter + SSD both in the USB 3.0 ports. Maybe with it booting off the SD card I can get some useful error messages.
As I told you above I loose my ssd drive here also when my 8152 and ssd drive was both plugged in the usb 3.0 ports. Because you have a self powered hub plugged in the usb 3.0 port you are not changing anything except how it is being powered.
I did recall that from earlier in the thread. The first USB 3.0 enclosure I tried failed on the Pi because the bus couldn’t give it enough juice, so I thought it might be worth trying, even if I knew it probably wouldn’t work.
(In any case I don’t mind having a portable powered USB 3 hub. I might need it elsewhere in the office. I’ve actually run into a few different computer/device combos where bus power isn’t enough. It’s particularly an issue with some keyboards and mice, which makes waking a computer from sleep tricky.)
Do you think this is a software issue upstream with the AUR driver, or an insurmountable hardware issue with the USB 3 bus on the Pi? Since USB-boot wasn’t even a thing when the Pi 4b was released, it wouldn’t surprise me if the specifications of the 4b assume the user just won’t be trying to do certain things with the USB 3 bus, ever.
What I think “It is what it is” unless someone can come up with a solution. Any conjecture would not be of any value at this point.
Agreed. And it’s not like the SSD performance is bad on USB 2. It pretty much behaves like the most stable high-speed SD card imaginable. Thanks again for all your work on this.
The one thing I haven’t been able to figure out is why LightDM doesn’t work. I’m leaning towards it not liking the kernel regression, but that’s just a guess.
Will this driver patch eventually migrate to the mainline kernel, or will it stay a testing only feature?
ETA: @0n0w1c , I didn’t realize I wasn’t running iperf3 in both directions before. By default it’s just upload. -R adds download. Download actually pegs the connection, minus overhead. It doesn’t look like that immediately, but that’s because there were a couple of slow ones in there. I immediately ran the test again and got 2.26 Gbps on the download.
1 Like
Works on all present and past kernels here. You must have some config change for your setup there.
Ugh. Figures. I seem to go about two weeks between random GUI breakages.
Thanks for letting me know.
I was getting instability with my particular NVME + enclosure combination plugged into the USB 2 port. At random the Pi would completely stop responding to commands–either claiming, e.g., that “ls” did not exist, or just hanging until interrupted. Eventually, it wouldn’t even let me interrupt.
So I decided to revert and plug the NVME back into the USB 3 port. Everything came back up correctly on 5.11.0-3, and LightDM restarted without issue.
@Darksky, thanks so much for this, again. I’ve already figured out a way to solve this problem permanently–if the USB 2.5G ethernet dongle wants to be the only USB device on the system, I’ll just have to figure out how to enable network boot at some point. 
There’s more than enough room on my NAS for that.
Truly bizarre. Clearly lightDM didn’t like something about switching kernels, but I’ll be dipped to figure out what.
EDIT: I may have goofed up my rollback a bit. I thought I uninstalled the r8152.ko module using pamac, but it’s still in /usr/lib/modules/5.10.17-2-MANJARO-ARM/updates. However, it’s not showing up in lsmod, so maybe I did it right?