At the studio, the NAS share is fine. Bins open, clips scrub, nobody thinks about storage. Then you take the same project home, connect the VPN, and the same share turns into a different product: folders spin, scrubbing stutters, and a filename search is long enough to make coffee. So you run a speed test, and the speed test comes back fine. The line is fast. The share is slow. Both readings are correct, because the speed test measures the one thing that isn't the problem.
Round trips, not throughput #
SMB is a conversation. Opening a folder is not one request: it is a sequence of opens, attribute checks, and directory listings, each one a message to the server and a wait for the reply. Reading a file adds opens, locks, and a read per chunk. Most of those exchanges depend on the answer to the one before, so the waits stack up in single file.
On a LAN, each of those exchanges costs roughly 0.5 ms, so the chatter is invisible. Through a home VPN, a realistic figure is about 20 ms per round trip (these are the stated model assumptions we use on our performance page, not measurements of your line). Same protocol, same NAS, but every exchange now costs 40 times more, and the protocol makes hundreds of them before any actual media moves. That multiplication is most of the story, and bandwidth barely touches it.
one ask, two wires
modeled June 2026 · assumptions in the text
One minute of editing, counted #
Our performance page models one ordinary minute at the timeline as six moves: open a project bin of 2,400 items, scrub a hero clip (12 touches, about 48 MB), open a second bin, scrub a B-roll clip (8 touches, about 32 MB), come back to the first clip, then find one clip by name in a library of about 131 K entries.
On the plain-share model (one round trip per 100 directory entries, no persistent client cache, no library index), that minute pays 1,390 wire round trips and about 38 s of waiting at the home-VPN profile. The same minute against local metadata and a block cache pays 20 round trips and about 7.3 s. The labeling matters, so here it is exactly as the site carries it: this is a model, built June 2026, with its assumptions stated; the SMB lane is a category sketch, not a benchmark of any vendor's NAS or client.
the worked minute · waiting, drawn on one time scale
modeled June 2026 · category sketch, no vendor benchmarked
Where the 38 seconds go is the instructive part. The two bin listings cost 24 round trips each. The two first-touch scrubs cost what physics says they must: the round trips plus roughly 80 MB of blocks at line rate, and that cost is identical in both lanes. The revisit of the hero clip costs the share the full price a second time, because nothing was kept. And the name search is the massacre: with no index, the model walks the tree at one round trip per 100 entries, which is 1,310 round trips, about 26 s at 20 ms each, to find one clip.
Why more bandwidth barely helps #
The minute has two cost terms. Bytes divided by bandwidth: the share moves about 128 MB (the 80 MB of scrub data, plus the hero clip's 48 MB a second time on the revisit), call it 10 s at 100 Mbit. And trips times latency: the other ~28 s, pure waiting that happens one reply at a time, in sequence.
latency times chattiness
round trips × round-trip time = waiting
the studio 1,390 × 0.5 ms ≈ 0.7 s invisible inside a minute
home VPN 1,390 × 20 ms ≈ 27.8 s the whole problem
modeled June 2026 · same minute, same trip count
Upgrade the home connection to 1 Gbit and the first term drops to about a second. The second term does not move at all, because latency is set by distance and routing, not by the plan you pay for. That is why the upgraded line still feels broken: you bought a wider pipe for a problem that was never about width. The speed test measures the first term and tells you everything is fine. It is measuring the term that was already cheap.
The honest fix menu #
Vendor-neutral, including the ones that don't involve anything we make.
whole file vs blocks · one clip, drawn to scale
modeled June 2026 · assumptions in the text
What local metadata and a block cache change #
This is the part where we talk about our own product, flagged as such. JuiceMount keeps file metadata in a local SQLite mirror and file blocks in a local SSD cache, so the chatty half of the protocol never crosses the wire at all. The numbers below are the author's measurements on his own rig (Apple-Silicon Mac to TrueNAS over 10 GbE), with the methodology public, not independent benchmarks.
| Operation | Author-measured |
|---|---|
| Directory open, 100 K+-entry volume | 15–120 msthe same opens take 3–10 s through the raw FUSE mount the cache sits in front of |
| Filename search, ~131 K entries | ~29 ms |
| Cached revisit reads, off local SSD | 226–571 MB/s |
| Un-pinned read refusal, offline mode | 4–67 msinstead of a ~30 s NFS retry hang |
Feed those measurements into the same modeled minute and it comes out at the 20 round trips and roughly 7.3 s from earlier, and the honest accounting cuts both ways: the first-touch scrubs still pay the wire in full, once per block, exactly like the share does. The cache only wins on what it already holds. It turns out an editor's minute is mostly revisits, listings, and searches, which is precisely the part a cache and an index can hold.
The physics nobody escapes #
No mount, ours included, beats the line your ISP sells you. Away from the studio, every byte that actually moves arrives through that pipe at that pipe's speed, for every product in this category. The only winning move is to stop paying the wire twice for the same block: pay once on first touch, keep it on local SSD, and answer the listings and searches from an index that never left the laptop. That is the entire trick, and the remote wiring behind it is three Tailscale steps in the docs. Everything else is the speed test telling you the line is fine, and the line agreeing, and the share still spinning.
Where these numbers come from
- The worked minute and its assumptions: the round-trip model on our performance page, June 2026. Assumptions stated there: 0.5 ms/125 MB/s LAN, 20 ms/12.5 MB/s home VPN, 60 ms/6.25 MB/s road; one round trip per 100 directory entries on the share lane; category sketch, no vendor benchmarked.
- The 100 GB strip and its ~4 MB blocks: the block-paging demo on our performance page; the 3 × ~4 MB ≈ 12 MB sketch in this post is the same stated assumptions, worked by hand.
- Author-measured figures (directory opens, search, cached reads, offline refusal): the performance page ledger and docs/PERFORMANCE_METHODOLOGY.md, measured on the author's own rig.
- Dropbox whole-file behavior: their help page (online-only files automatically download on open), checked June 2026.
- Vendor caches on customer hardware: lucidlink.com/teamcache; Suite's cache docs and pricing page; iconik Storage Gateway overview and TrueNAS packaging; Shade's cache docs and pinning docs. All checked June 2026; the full facts pack is
docs/web/RESEARCH_ROUND2.mdin the repo.