COSMOS data networks carry SDR sample streams, which are far more demanding than ordinary
traffic. The standard MTU on data interfaces is 9000 (jumbo frames). You normally get this
automatically — this page explains what you get, why the number matters, and how to change it
for your own experiment or custom image.
On a node running a current COSMOS image, the interfaces named DATA1, DATA2, DATA1a and
FH1/FH2 come up with MTU 9000. The control interface (CTRL) stays at the normal 1500 —
it carries management traffic, not samples.
Check it on a node:
ip -o link show | grep -E 'DATA|FH'
Nothing is required of you to get this. It is written into /etc/netplan/10-cosmos-roles.yaml
at every boot by the cosmos-ifname package, which also names the interfaces by role.
UHD derives its transport frame size from the interface MTU. Ettus documents MTU 9000 for
10 GigE, which yields a UHD frame size of 8000 (roughly 1000 bytes of overhead).
If the interface is set to 8000 instead, UHD derives a frame size below 8000 and the radio
link quietly runs under spec. Nothing errors — you simply get less headroom, which shows up
only as reduced performance at high sample rates. This is easy to miss and has caught us more
than once.
Do not try to "match" a 9000 MTU by raising the frame size to 8960. The documented pairing
is MTU 9000 → frame_size 8000.
An interface set to 9000 does not prove the path carries 9000 — a switch in between can be
capped lower. When that happens you get a PMTU black hole: ping works (small packets), but
scp and ssh hang partway through, because large packets are silently dropped.
Test with a do-not-fragment ping. A payload of 8972 corresponds to a full 9000-byte frame:
ping -c2 -M do -s 8972 <peer-ip>
Do not run this against a USRP X310 or USRP-2974. They answer at a false ceiling of about
8000 because of UHD protocol overhead on the radio side — that is the radio's limit, not the
network's, and you will conclude a switch is misconfigured when it is fine. Test against an
N310, another server, or your data-plane gateway.
Some experiments need a different MTU — for example when a device in the path cannot do jumbo
frames.
Do not edit /etc/netplan/10-cosmos-roles.yaml. It is regenerated on every boot, so your
change would disappear. Netplan merges its files in alphabetical order with later files winning,
so add a higher-numbered file instead:
sudo tee /etc/netplan/99-experiment-mtu.yaml >/dev/null <<'YAML'
network:
version: 2
ethernets:
DATA1:
mtu: 1500
YAML
sudo chmod 600 /etc/netplan/99-experiment-mtu.yaml
sudo netplan apply
This survives reboots, and it survives the role file being regenerated.
A runtime
ip link set DATA1 mtu 1500is not durable — systemd-networkd re-applies the
configured MTU on lease renewal, carrier flap and reboot, so your change can vanish
mid-experiment. Use the netplan file above.
If you are saving your own image, the same
rules apply, plus two things worth knowing:
Include the override in the image by creating the 99-*.yaml file before you run
/root/prepare.sh. Note that prepare.sh deliberately removes 10-cosmos-roles.yaml (it is
node-specific and gets regenerated on first boot) but leaves your 99- file alone.
Images saved before mid-2026 carry MTU 8000 on their data interfaces. If you are rebaking
an older image, upgrade the naming package first so the new default is baked in (1.13 also
fixes a bug where a MAC-less interface, such as an LTE modem, silently invalidated the whole
generated network configuration):
sudo apt-get update && sudo apt-get install --only-upgrade cosmos-ifname
dpkg -l cosmos-ifname # want 1.13 or newer
For full manual control of the interface configuration, put the line
# cosmos-ifname: hands-off in /etc/netplan/10-cosmos-roles.yaml and it will stop being
regenerated — at the cost of owning role naming yourself.
DATA_MTU in /etc/cosmos-ifname/ifname.conf decides it:
| Value | Behaviour |
|---|---|
auto (default) |
Use the MTU the network hands out over DHCP if it specifies one, otherwise 9000 |
dhcp |
Use only what DHCP specifies; set nothing if it is silent |
| a number | Force that value |
The default deliberately lets the network win where it states an intent. Some planes are
pinned to a non-jumbo value on purpose — the minicity data plane is held at 1500 because a
wireless-attached node there cannot carry jumbo frames — and auto respects that instead of
overriding it.