The relay's ceiling was a 208 KB socket buffer, not the link

• What the run showed
• What that means for the numbers on the pricing page
• Three things the tool got wrong
• What changed

Before the free tier said 100 concurrent players, I wanted to know where the relay actually stopped. The relay is a single small VM in Ashburn forwarding UDP between players who cannot reach each other directly. The bench tool opens lobbies of eight, fills them with synthetic players, and sends game-sized packets through the relay at 60 Hz, while I read the relay's own counters off the control plane every ten seconds.

What the run showed#

At 50 players: clean. Between 56 and 104 players, drops began. At that point the relay was moving about 0.46 MB/s, which is under one percent of the 480 Mbps link. CPU load was 0.17. The per-tick p95 was 1.2 ms. Nothing about the box looked busy.

So the drops were not the link and not the CPU. Three counters agreed to the unit on what they were:

• The relay's own rx_drops read 26,498.
• The kernel's UdpRcvbufErrors read 26,498.
• The socket on port 7788, in ss -u, showed d26498 and a receive buffer of rb212992.

212,992 bytes is the Linux default for a UDP socket receive buffer, and net.core.rmem_max on that box was also 212,992, so the relay could not have asked for more even if it had. Under a burst, packets arrived faster than one thread drained a 208 KB buffer, and the kernel dropped the overflow before the relay ever saw them. Before this run, the box's lifetime UdpInErrors was zero. Every drop in its history happened during the bench.

What that means for the numbers on the pricing page#

Two decisions came out the same way and for the same reason. The free tier stays at 100, and the relay does not move to a bigger machine. A bigger box with the same default socket would drop at the same point. The limit found is a sysctl (net.core.rmem_max) plus a setsockopt(SO_RCVBUF) in the relay, not a hardware ceiling.

The link question is still genuinely open. Nothing in the run got within two orders of magnitude of it.

Three things the tool got wrong#

Worth recording, because each one looked like a relay fault.

1. The echo host answers only the sender, so ingress equalled egress to the byte and the fan-out of a real eight-player lobby, where one packet in leaves seven times, was never measured. --lobby-size changed the number of lobbies and nothing else.
2. Past the drop point, senders stall on reliable backpressure. The 400-player run sent 45,798 of a planned 240,000 packets. So the tool's "per player" and "implied ceiling" figures went up as the relay failed, which is the opposite of what they mean.
3. The first 400-player run died on the bench box itself: Too many open files at lobby 31, from a 1024 file-descriptor limit on the machine sending the traffic. That reads exactly like a relay fault and is not one.

What changed#

The kernel setting is staged for the next relay restart, paired with a relay release so it costs one lobby-killing window instead of two. The bench's three defects are filed against the tool. The free tier number did not move, because the gate for it (a region must carry twice what is promised) was met before this run and the run found a fixable limit rather than a real one.