n bench — how fast is a share, and why

What the six phases measure, why most share benchmarks lie, and how to read the verdict.

n bench //host/share measures what you actually experience when you use a network share, then

explains it: which link you're on, what the two ends agreed to, where the time goes, and what

is — and isn't — the bottleneck. The numbers are the evidence. The verdict is the product.

n bench //host/share          all six phases (~20 s, ≤96 MB of test data, asks first)
n bench <host>                phases 1–2 only: path + protocol. Any SMB server, no mount, writes nothing
n bench .                     this machine's own disk and pressure: the baseline every share is compared against
n bench //host/share --full   256 MB × 5 rounds when you need a confident answer
--yes    skip the "someone's disk" confirmation      --at <dir>   write via a specific mount point

Why most share benchmarks lie

• They measure caches. Writing a file returns before the bytes reach the server (write-behind).

Reading a file you just wrote comes from your own RAM. n bench fsyncs every write inside the

timing, reads a file from an *earlier* round, and bypasses the page cache when it reads

(fadvise DONTNEED on Linux, FILE_FLAG_NO_BUFFERING on Windows, F_NOCACHE on macOS).

• They average two different physical quantities. Small files measure per-operation latency —

round trips plus whatever the server does per file. Big streams measure throughput. Averaging

4 KB results with 1 MB results produces a number that means nothing. n bench reports the two

regimes separately and reasons about each.

• They use fixed sizes. 1 MB on gigabit is 8 ms — all overhead. n bench streams for a fixed

*time* (4 MB chunks, capped) so the number is stable on any link, from 2.4 GHz Wi-Fi to 10 GbE.

• They report the mean. The mean hides the 300 ms stall you actually feel. n bench reports

median and worst.

• They report a number without a reference. "44 MB/s" is meaningless until you know the link's

ceiling. n bench derives the ceiling from the negotiated link and shows every result as a

percentage of it.

• They don't tell you when to distrust them. n bench runs several rounds, discards the first

(warm-up), prints the round-to-round spread as a confidence gauge, and says plainly when a

result is noisy.

The six phases

1 · PATH — how am I reaching it?

Written before anything else because it explains most results on its own.

| Line | What it tells you |

|---|---|

| Target | Which address was measured and why. A LAN address is preferred over a Tailscale/VPN one, and it says so when your resolver only knew the slower route. |

| Interface | The local interface the kernel routes through; wired or wireless; negotiated speed, duplex, MTU. A gigabit NIC negotiated at 100 Mb/s is almost always a cable (gigabit needs all 8 wires) or a dead switch port. A 2.5 GbE NIC at 1 Gb/s means the switch or cable is the limit. |

| Wi-Fi | Band, channel, bitrate, signal. 2.4 GHz is slow and crowded; the bitrate sets a hard ceiling. |

| Ceiling | The best this link could ever deliver in MB/s, and the assumption behind it (wired ≈ 90 % of line rate; Wi-Fi ≈ 45 % of bitrate because it's half-duplex and shared). |

| RTT | 20 TCP connects to the SMB port — the round trip SMB pays on every request. Over ~20 ms is WAN/VPN territory and small-file work suffers most. |

| MTU test | A don't-fragment ping. If 1500-byte frames don't fit, a tunnel is shrinking the path and every big packet is split and reassembled. |

| Hops | From the reply's TTL; also reveals the remote OS (Windows starts at 128, Linux/macOS at 64). |

| NIC health | Drops and errors on the interface since boot. Errors mean corrupted frames: cable, port or card. |

| Tailscale | Direct peer-to-peer, or relayed through a DERP server on the internet. Relayed is the difference between LAN speed and a few MB/s. |

2 · PROTOCOL — what did the two ends agree on?

n bench speaks a raw SMB2 NEGOTIATE to port 445 — the first packet every client sends — so it

needs no mount, no password and no admin rights, and works against any SMB server (Windows, Samba,

a NAS).

• Dialect the server offers (3.1.1 is current; 2.x lacks multichannel, encryption and large reads).
• Signing enabled / required. Signing puts an HMAC on every packet: tamper-proof, but 20–50 %

of gigabit throughput, CPU-bound on both ends. Windows 11 24H2 requires it by default — the tool

says so rather than telling you to turn it off.

• Encryption ciphers available; multichannel; compression; max read/write sizes;

server uptime.

• SMB1 probe. SMB1 is deprecated (2014) and was WannaCry's way in. If a server still answers

it, that's flagged with the command to disable it.

• This client: what *your* mount actually negotiated (dialect, signing, cache mode, I/O sizes,

encryption) and, from Linux, what the server says about the volume behind the share (SSD, TRIM,

sector size) — so the verdict doesn't guess "maybe it's a slow disk" when the server has said it's an SSD.

3 · OPS — small files

64 × 4 KB: create → write → close → read → delete, one at a time. This is what copying a source

tree or a photo folder feels like. Reported as files/s and per-file median/worst, against what the

round trips alone would explain (~5 × RTT). A big gap means the server is doing work per file:

Defender scanning every file on close (Windows), or strict sync / VFS modules / a high log level

(Samba), or a slow metadata disk.

4 · THROUGHPUT — big streaming transfer

Rounds of fixed-time writes (random data, made unique per chunk so nothing compresses or dedups it,

fsync inside the timing) and cache-bypassed reads of the previous round's file. First round is

warm-up and excluded. Shown as MB/s, as a percentage of the ceiling with a bar, with the spread.

5 · BASELINE — this machine

The same ops and throughput tests on your own disk (the home directory — /tmp may be RAM), plus

this machine's pressure: cores against load (or CPU %), and how full the disk is. Without this,

"the share is slow" and "my disk is slow" are indistinguishable. n bench . runs this alone; run it

on the *server* when the verdict points there.

6 · VERDICT

The result's shape against the ceiling decides the story:

• wire-limited — reads and writes both ≥ 80 % of the ceiling. Everything is keeping up; only a

faster link would help (and it says whether your NIC could take one).

• write-side — reads fine, writes slow: the limit is on the server at write time. Suspects, in

order: Defender scan-on-close (Windows) or strict sync (Samba), the server's disk (unless it

reported an SSD), write-through.

• read-side — the reverse: the server serving data (a cold HDD, a busy server, small rsize).
• both — the path or the protocol: Tailscale relay, encryption or signing, the Wi-Fi radio,

fragmentation, a server that's simply overloaded — or your own disk, if the baseline is no faster.

Each suspect comes with the exact command to check or fix it, labelled as inference ("in order of

likelihood"), followed by what the evidence *cleared*, the noise paragraph, and the cleanup line.

Using it on a home network

• "Is it the Wi-Fi?" Run it once on Wi-Fi, once on a cable. Phase 1's ceiling and Phase 4's

percentage settle it in a minute.

• A cable or switch port that's silently gone bad. Phase 1: "NIC can do 1000 Mb/s but negotiated 100".
• Before/after a change — new switch, new cable, moving a server to a faster port, enabling

jumbo frames, changing a Samba setting. Same command, compare the numbers *and* the spread.

• The server, not the network. Reads at 97 % of the wire and writes at 39 % is a server-side

signature; the verdict tells you to run n bench . *there*, which reports its cores, load and

disk fullness.

• Security posture as a side effect. SMB1 still enabled? Signing off on a server that should

require it? Insecure guest logons enabled on a Windows client? Phase 2 says so.

• Tailscale users: if a share feels slow from your laptop, Phase 1 will tell you whether you're

going through a relay — and that the LAN address would be ~100× better when you're at home.

A real example: a share served at 12 MB/s and 26 ms per file over a clean gigabit LAN. Phases 1–2

cleared the wire, MTU, signing and VPN; Phase 3 showed per-file time far beyond the round trips;

the verdict pointed at the server. n bench . on the server: *2 cores · load 13.9 · oversubscribed

×7 · disk 97 % full.* The SMB daemon wasn't busy — it was starved, waiting in the run queue behind a

browser and a torrent client. No network tool would have found that; a benchmark that only prints

MB/s wouldn't have either.

Honest limits

• Results are noisy by nature: other transfers, backup jobs, thermal throttling, an antivirus scan

mid-run. The spread is printed for exactly this reason; over 25 %, rerun. --full runs longer.

• Without an agent on the far end, n bench measures *the share as you experience it*. It can

infer where the time goes, but it cannot see the server's CPU or disk directly — hence "run

n bench . on the server".

• Linux/macOS need the share mounted to write to it (n mount //host/share); Windows can use the

UNC path directly. Live session details on Windows need an elevated window.

• It writes to someone's disk and uses someone's network. It asks first, uses a temp folder

.netscrew-bench-<random>/, keeps to ~96 MB by default, and always removes what it wrote.

Roadmap

• --json for tracking a share over time.
• n bench serve on the far end for a raw TCP throughput test independent of SMB (like iperf3),

which would separate "the network" from "the file server" directly.

• Per-host memory of the confirmation, if the prompt grates.