Homelab Latency vs Bandwidth: Why Faster Fiber Doesn’t Fix SSH on Starlink

Starlink’s speed test looks like a promotion. Two hundred megabits down, sometimes more, a number that makes a rural DSL refugee weep. Then you SSH to the NUC to edit a compose file and the caret waits. You upgrade the dish. You buy a “priority” plan. You run another speed test. The caret still waits. Bandwidth was never the meter SSH uses. Round trip time, jitter, and the occasional 400 ms stare while a satellite hands you off — those are the meter. Faster fiber would help if you had fiber. A fatter Starlink pipe does not become fiber. It becomes a fatter pipe with the same light-time and the same bufferbloat personality.

I run a rack at the end of a Starlink hop and a VPS that owns the listening sockets. I have wasted money on throughput I do not feel in a terminal. This is the distinction I wish the order page printed next to the megabits.

What SSH actually waits on

An interactive session is a conversation of tiny packets. Each keystroke is a round trip if you are not using something smarter than raw OpenSSH in cooked mode. At 20 ms RTT, typing feels local. At 50–80 ms, which is a polite Starlink evening, it feels like a remote. At 120 ms plus jitter, you overtype. At a handover spike, you send a line twice. None of those numbers appear on the download bar.

scp and rsync of a 2 GB image will use the megabits. They will also start slow if the TCP window is shy, then fly. People do that once, feel rich, and assume vim will feel rich. vim is not a download.

Mosh exists because this problem is older than Starlink. It predicts keystrokes and survives roam. On a dish it is one of the few upgrades that matches the pain. tmux on the far side so a freeze does not kill the job is the other. I use both. I still feel the RTT when I tab-complete a long path. Physics is not a setting in the Starlink app.

Why “faster” Starlink is the wrong purchase for a homelab shell

Priority and the bigger dish change contention and rain behavior more than they change the path length to the satellite and down to a ground station. You can get luckier queues. You cannot get a fiber RTT to a city PoP on a quiet municipal ring. People who move from Starlink to fiber talk about SSH first, streaming second. That is the tell.

Bufferbloat is the homelab multiplier. A family member starts a 4K fetch, the buffer fills, your 60 ms becomes 300 ms, and the speed test still says you have “200 down” because the test is a flood. Cake or fq_codel on the router, or the Starlink router bypassed for a box that can do that, is a better SSH upgrade than a plan change. I have seen more shell improvement from queue discipline than from a hardware refresh.

Obstructions add a different latency: freeze, then a burst, then TCP recovery. The dish LED is happy enough. Your SSH is not. Trees are not a megabit problem. They are a conversation problem.

Fiber envy is still correct — for a different job

If you can get fiber, get it, for the RTT and the symmetry and the lack of a weather mood. Do not get it because a YouTuber showed a gigabit speed test and you thought your ansible pings would match. They will match better. They will not match because of the gigabit. They will match because 8 ms is not 60 ms.

If you cannot get fiber, stop buying Starlink as if it were fiber with a dish. Buy it as a wide, high-jitter pipe. Put bulk on it. Put interactive elsewhere if you can: a cheap VPS you SSH to first, then bounce, or a mosh hop, or do the edit in an editor that is local and sync the file. I keep a VPS as the place I land. The homelab is a second hop over Tailscale or WireGuard. The first hop has a sane RTT. The second hop is the dish. Splitting them is how I stopped shouting at bash.

Inbound was never the speed test either

CGNAT means you are not accepting SSH on 22 from the world no matter how fast the downlink is. Overlays, a VPS, a subnet router — that inbound story is Starlink CGNAT when inbound ports are the product. Faster Starlink does not open a port. I mention it because people buy throughput to “make the homelab reachable.” Reachable is an address problem. This piece is the caret problem after you are already reachable.

Ansible, git, and the other “not a speed test” jobs

A playbook with a hundred small SSH commands is a latency multiplier. Each task is a conversation. On fiber you do not notice. On Starlink the playbook feels haunted. I batch, I use mitogen or persistent connections when I remember, and I try not to run the full site from a café on the dish. One rsync of a built artifact beats fifty remote echo tasks.

git over SSH is usually fine: bursts, then idle. git with a million tiny pushes in a hook is not. CI on the homelab that SSHes home for every lint is how you invent a bad WAN. Put CI on a VPS. Let the dish be the place artifacts land.

Remote desktops are worse than SSH. They are a 30 fps conversation. Starlink will do a desktop. It will not do a good one when the house is streaming. If your “homelab access” is actually RDP, you are even more in the latency business than I am with vim. I would rather tmux. I have used RustDesk on the dish. I did not enjoy it during rain fade.

What I change before I change the plan

• Mosh or at least SSH with IPQoS throughput experiments I have mixed feelings about — mosh first.
• tmux named sessions so a stall is not a lost apt.
• Queue discipline on the router; do not let a fetch eat the dish.
• Edit locally, rsync, or use an editor that is not chatty per key if I must stay on OpenSSH.
• A VPS jump host with a good path; the dish is the last mile to the rack, not the first mile from my laptop in a city.
• Stop running speed tests as a mood. Run ping and mtr while someone streams. That is the SSH weather.

I still use Starlink because the alternative was worse copper. I do not use it as a personality. When I need a shell that feels like a room I am in, I sit in that room or I sit on fiber in town. When I need a shell from away, I accept 60 ms and I refuse to buy a fatter plan to treat the symptom.

Rain, night, and the lie of a single ping

A ping at noon is not the SSH you will have at 8 p.m. when the cell is busy, or at 4 p.m. when a storm is in the fresnel you do not get to see. I keep a day’s worth of RTT in my head before I call the link “fine.” One lucky 28 ms is a commercial. Interactive work needs the ugly percentile. If your p95 is 150 ms, your compose edit will feel like 150 ms no matter what the speed test printed at 11 a.m.

I have done support calls where the customer swore the dish was “faster than the office” and then could not type in nano. The office had 30 mbps and 12 ms. The dish had 220 and 70. They had bought the wrong number. I now ask for ping, not for megabits, when the ticket is a shell.

If you are choosing between a second Starlink kit and a microwave hop to a neighbor’s fiber, the hop wins for SSH even if it loses a speed test. I have wanted that hop more than I have wanted a second dish. Two dishes do not halve RTT. They may halve contention. Contention is not the whole caret.

The one-line version

Bandwidth moves backup images. Latency moves the cursor. Starlink sells the first and includes a middling, jittery second. Faster Starlink is still Starlink. Fiber fixes SSH because it fixes the conversation, not because it wins a speed test. If your homelab pain is the caret, spend on queues, mosh, and a jump host. Leave the megabit marketing for the night you pull a library. I pull libraries on the dish. I type around it. When I forget, I buy a plan I do not feel, and I remember the caret the first evening I try to edit docker-compose.yml from a train. The file is tiny. The RTT is not.