MTU, fragmentation and the mystery 3% loss
Here is a pattern that confuses a lot of people. Ping looks fine. Most of the game works. But joining takes forever, the map download stalls at the same percentage, or a steady few percent of packets just vanish. Nobody else in the room has the problem. Very often the cause is packet size, not speed.
What MTU means
MTU stands for Maximum Transmission Unit. It is the largest packet a network link will carry in one piece. On Ethernet and on most home connections it is 1500 bytes. That number includes the IP header (20 bytes) and, for UDP, the UDP header (8 bytes), so the most data a single UDP packet can carry on a plain 1500-byte link is 1472 bytes.
Every link on the path has its own MTU. The smallest one decides. That smallest value is called the path MTU.
Some common values:
| Link | Typical MTU | Why |
|---|---|---|
| Ethernet, most cable and fibre | 1500 | The standard default. |
| PPPoE (common on DSL and some fibre) | 1492 | 8 bytes go to the PPPoE header. |
| Mobile and some 4G/5G routers | 1400–1500 | Varies by carrier. |
| Any tunnel or VPN | Less than the link underneath | The tunnel adds its own headers to every packet. |
Why tunnels make it worse
A tunnel wraps each packet inside another packet. The original packet becomes the payload, and the tunnel adds a new outer IP header, a UDP header and its own header on top. That overhead is usually somewhere between 40 and 80 bytes, depending on the protocol and on whether the outer layer is IPv4 or IPv6.
So if your real line has an MTU of 1500 and the tunnel adds 60 bytes, the biggest inner packet that fits is 1440. Anything larger than that has two options: get split into fragments, or get dropped.
This applies to every VPN and every virtual LAN, including ours. It is not a flaw of one product. It is arithmetic.
What fragmentation does to a game
IPv4 can split a large packet into fragments and reassemble them at the other end. That sounds like a fix. In practice it causes three problems.
- Loss multiplies. If a packet is split in two and either half is lost, the whole packet is lost. A link with 1% loss becomes roughly 2% loss for fragmented packets.
- Some devices drop fragments. Firewalls, NAT routers and some ISPs handle fragments badly or discard them outright. That turns "large packets are slow" into "large packets never arrive".
- The warning never comes. Modern systems try to discover the path MTU using ICMP "fragmentation needed" messages. When a firewall blocks those, the sender never learns that its packets are too big. This is called a PMTU black hole.
Old games make it worse. Most of them use UDP, pick their own packet sizes, and do not do path MTU discovery at all. They assume a LAN, where 1500 bytes always works.
What it looks like in a game
MTU problems have a signature. Small packets work and big ones do not. In a game that usually means:
- You can see the game in the list, but joining hangs on "connecting" or "retrieving info".
- Map or mod downloads from the host stall, often at the same point every time.
- The game plays fine for a while, then desyncs or drops you when a lot happens at once and the game sends a larger state update.
- A small, steady percentage of loss that does not change with time of day. If three packets in a hundred are large enough to be dropped, you see 3% loss, every time.
- Only one player is affected, and that player is the one on PPPoE, a mobile connection or an extra VPN.
Normal congestion loss behaves differently. It comes and goes, it is worse in the evening, and it hits packets of every size.
How to test it on Windows
Windows ping can send packets with the "don't fragment" flag set. If the packet is too large for any link on the path, it fails instead of being split. That lets you find the limit.
Open Command Prompt and start with the largest size that fits a 1500-byte link:
ping -f -l 1472 1.1.1.1
-f sets don't-fragment. -l sets the payload size in bytes. If you see normal replies, your path to the internet carries full 1500-byte packets. If you see Packet needs to be fragmented but DF set., or plain timeouts, it does not.
Lower the size until it works. Halving the gap each time gets you there in a handful of tries: 1472, 1450, 1430, 1440, 1435 and so on. When you find the largest size that gets replies, add 28 (20 for IP, 8 for ICMP). That is your path MTU.
Timeouts can also mean the target simply ignores ping. Always confirm first that a small ping, like ping -l 32 1.1.1.1, gets replies from the same address.
Testing inside the virtual LAN
Run the same test against another player's 10.60.x.x address while you are both in the room. This measures the path through the tunnel, which is the one the game actually uses. Compare results between players. If one person's limit is clearly lower than everyone else's, you have found the odd one out.
What to adjust
First, remove what you added
A very common cause is a second layer. A VPN running under the virtual LAN, a "gaming accelerator", or an MTU value someone changed by hand years ago. Turn off the extra layer and test again before touching anything else.
Check the router
If your connection uses PPPoE, the router's WAN MTU should normally be 1492. Some routers ship with odd values, or were set lower by a technician at some point. The setting is usually under WAN or Internet in the router's admin page.
Lowering MTU on Windows
You can see the MTU of each interface with:
netsh interface ipv4 show subinterfaces
And change one, from an administrator prompt, with:
netsh interface ipv4 set subinterface "Ethernet" mtu=1450 store=persistent
Replace Ethernet with the interface name from the first command. Only do this on your physical adapter, and only if testing showed your path really is smaller than 1500. Leave the LanOrbit adapter at whatever value the app set. If you think that value is wrong for your connection, send us your ping -f results through PC support rather than changing it by hand.
Write down what you changed
MTU tweaks are easy to forget. A value that fixed one problem three years ago can cause a new one today. Keep a note of the old value so you can put it back.
The short version
If loss is steady, small, affects only one player, and big things like joining or map downloads are what break, test MTU before you blame the route. Two minutes with ping -f -l will usually tell you. And if the problem is plain high ping or jitter instead, the ping test is the better place to start.
