Spyke

recalbox·Recalbox ROM emulatorbylet_s_get_started

Change MTU

Since almost all important devices in my network use an MTU (maximum transmission unit) of 9000, I looked high and low on how to change it on recalbox. The reason is that I wanted to try and optimize the Moonlight streaming as much as possible. By having less overhead, the cpu would maybe get a little more headroom (theoretically).

What I found is that at least currently, it IS possible to change it on a raspberry pi by issuing the command in SSH. This changes it temporary for testing sudo ip link set dev eth0 mtu 9000

or permanently `sudo nano /etc/dhcpcd.conf

interface eth0 static ip_address=192.168.1.50/24 static routers=192.168.1.1 static domain_name_servers=192.168.1.1 mtu 1400 `

BUT, this only works when running an OS that supports this change (Raspberry Pi OS for example).

When it comes to Recalbox, apparently it is not supported to change MTU and it will always use the default,

I am not sure how much the MTU would change things, if at all. But it would be nice to have been able to test it. Currently that does not seem possible. Maybe in the future.

View original on lemmy.zip

Comments2

Artwork

lemmy.world

Well, I believe 9000 bytes or whatever unit your network is using, is quite rare to see, even today.
The most frequent is 1500-2000 max, at least in common civilian networking.
Are you sure the network passes your custom MTU correctly to the software via path MTU discovery (PMTUD) or alike? Have you benchmarked lower limits?

When people say “jumbo frames,” they mean an MTU of 9000 bytes - six times the payload per packet...

One detail that trips people up: enabling jumbo frames on a switch only means the switch will forward larger frames. It doesn’t change the MTU on connected hosts. You have to configure both sides...

...servers and switches are set to MTU 9000, but one intermediate device - a firewall, a load balancer, a misconfigured VLAN trunk - supports only 1500. Large packets hit that device and either get fragmented (adding overhead and reassembly cost) or silently dropped. The result is unpredictable throughput and latency spikes, which is the opposite of what you were trying to achieve.
Source

let_s_get_started

lemmy.zip

Hey welcome and thanks for chiming in.

I have to agree that most home users have no idea what MTU they are using, and it is typically going to be 1500 for their LAN. Their internet will be 1492. The internet is bandwidth limited anyway, it is best left alone. The LAN MTU however, most power users (even amateur ones) will make use of jumbo frames. Especially people who use backbones with greater than gigabit speeds (like myself). I believe Synology even ships their NAS systems with a default MTU of 9000.

If you want to test if jumbo frames are working between 2 nodes in your network, it is actually very easy to do. Assuming you have a 9000 packet size set:

ping <target ip> -f -l 8973 will return a "Packet needs to be fragmented but DF set." message

while

ping <target ip> -f -l 8972 will return a normal ping reply saying "bytes=8972 time<1ms TTL=64"

When you get a ping reply with such a forced packet size, you also immediately know that your backbone/switch supports the forwarding of jumbo frames.

The use of jumbo frames with Moonlight might just be enough to stress the cpu a little less and thus you might be able to up the streaming bandwidth somewhat. An estimation? Max 10% gain, something like that. But on a raspberry pi, for a single core decoding application, you take any gains you can get ;)