Why is sshfs so slow over a long link? We mounted a Singapore server on a Timisoara server with sshfs, about 200 ms apart, and read files with dd. A 100 MB file came in at 1.32 to 1.34 MB/s over ten trials. A 1 GB file came in at 1.33 MB/s over five. When the rate stays the same at every file size, the round trip sets the speed: each trip carries a fixed amount of data, and a bigger file only adds more trips. KEIBIDROP read the same pairing on demand at 20 to 30 MB/s, because it keeps several blocks in flight at once. This post has the setup, the arithmetic, and the one variable we did not capture.
The setup
The reading side is a Timisoara VPS: Xeon Gold 6140, 4 vCPU, 16 GB, Ubuntu 24.04, 1 Gbit/s. The serving side is a Singapore VPS running Windows Server 2022 on 4 KVM vCPUs with 8 GB. The round trip between them is about 200 ms, datacenter to datacenter, with no Wi-Fi loss on either end. sshfs talked to OpenSSH on the Windows box with chacha20-poly1305 and compression off, and every other option at its default. Each trial started a cold client with dropped caches and read the file sequentially with dd. The server generated its content once. Measured on 23 July 2026.
A flat rate
| Path | Trials | Rate |
|---|---|---|
| sshfs, 100 MB file | n=10 | 1.32 to 1.34 MB/s, median 1.33 |
| sshfs, 1 GB file | n=5 | 1.33 MB/s, flat |
| KEIBIDROP on demand, same pairing | n=5 | 20 to 30 MB/s |
The ratio between the two tools is 15x to 23x on this pairing. The spread inside the sshfs rows is two hundredths of a megabyte per second, and the 1 GB file runs at the rate of the 100 MB file, so a fixed cost per file plays no part. The same two machines on the same link moved 20 to 30 MB/s for another reader, so the link, the disks and the CPUs have room for fifteen times more. What limits sshfs here is the wait between requests.
One round trip per chunk
A reader that asks for one chunk and waits for it before asking for the next can move one chunk per round trip. Its speed is the chunk size divided by the round trip time, whatever the link can carry. At 1.33 MB/s and a round trip near 200 ms, each trip here carried about 326 KB. A 1 GB file is about three thousand such trips, a 100 MB file about three hundred, and both run at the same rate.
The same arithmetic explains why sshfs feels fine on a local network. At a round trip of 1 ms the same chunk size gives hundreds of megabytes per second, so the link or the disk becomes the limit first. The problem appears only when the round trip grows, which is exactly the case of a remote office, a server on another continent, or a laptop on hotel Wi-Fi.
Keeping blocks in flight
KEIBIDROP fetches a file in blocks of 16 MiB. During a sequential read it keeps a window of upcoming blocks requested ahead of the reader, so several round trips overlap and the link stays busy while the reader consumes the current block. The window sizes itself to the reader: a media player keeps a small one and a bulk copy fills the link. A read that jumps to a new place still pays one round trip for the first block it touches, and the window arms again once reading turns sequential.
The same idea is available to any network filesystem: larger requests, more of them in flight, or both. The details of the KEIBIDROP engine are in how it works, and the tool-by-tool comparison with the conditions is on the sshfs comparison page.
The variable we did not capture
We did not read the effective max_read and readahead values from the sshfs mount, so the numbers above assume the defaults of that build. A mount with larger requests or deeper readahead may do better on the same link. We have not measured one, and the table makes no claim about it. The server file cache was warm for both tools in the same way.
Limits. This is one pairing on one night, with sshfs at its defaults. KEIBIDROP runs its engine on both machines, while sshfs needs only an SSH server on the far side, so on a server you cannot install software on, sshfs is still the tool that works.