Offload & Checksum Time Calculator

Why verified offload exists

A copy without a verify pass is a hope, not a backup. Every DIT and camera assistant who has watched a "successful" copy turn out to have a handful of silently corrupted frames — a flaky USB hub, a dying card reader, a cable that drops one packet in ten million — learns the same lesson: bytes moved is not bytes matched. Verified offload closes that gap. It re-reads the copied files from the destination, hashes them, and compares the hash against what was read off the card. Only then is the card safe to format. That verify pass is not paperwork; it is the entire reason the workflow exists, and it is also the phase most offload software hides inside a single progress bar, which is exactly why this calculator breaks it out.

The on-set 3-2-1, lite

Full 3-2-1 backup (three copies, two media types, one off-site) is a post-production luxury. On a moving set, the realistic minimum is two copies before a card gets wiped: the primary that goes to the edit or DIT cart, and a second copy — often a slower, larger shuttle drive — that exists purely so a single dead drive can't lose the day. That second copy is not optional insurance; it is the actual backup, and this tool treats it that way by defaulting it on.

The workflow model, phase by phase

The tool models four sequential phases. Copy: the card is read at its sustained rate and written to the destination at its sustained rate — whichever is slower governs, and the bar names it explicitly (e.g. "governed by: CFexpress read"). Verify: modern offload tools (Silverstack, Hedge, OffShoot) hash on write using xxHash64, a GB/s-class algorithm that is never the bottleneck, then run a verify pass that re-reads the destination and re-hashes — that re-read, at the destination's sustained rate, is what the verify bar measures. Second copy: sequential to a second destination, governed the same way by the slower of card read and that destination's write speed. Second verify: the same re-read-and-compare against the second destination.

Take the pinned worked example: a 1 TB card, CFexpress reader (1,400 MB/s) into a Thunderbolt NVMe drive (2,200 MB/s), xxHash checksums, with a second copy going to a 7200 rpm spinning HDD (160 MB/s). Copy: 10¹² ÷ (1,400 × 10⁶) ≈ 714 s ≈ 11.9 min, governed by the CFexpress read — the card is the slow side of that pair. Verify: 10¹² ÷ (2,200 × 10⁶) ≈ 455 s ≈ 7.6 min, governed by the NVMe read. Second copy: 10¹² ÷ (160 × 10⁶) ≈ 6,250 s ≈ 104 min, governed by the HDD write — now the card is the fast side, and the spinning drive owns the schedule. Second verify: another ≈104 min re-reading that same HDD. Total: roughly 3 h 47 m. The card itself accounts for well under fifteen minutes of that; the backup drive owns nearly three and a half hours of it.

Why sustained throughput isn't the line rate

The interface numbers in this calculator are pinned sustained figures, not the advertised line rate — and the gap between the two is often 30-60%:

Those sustained figures are what this calculator uses, deliberately below the marketing line rate for each connection — USB 3.2 Gen 2 advertises 1,250 MB/s but sustains closer to 800 MB/s in practice, and Thunderbolt's 5,000 MB/s ceiling rarely survives contact with a real NVMe enclosure moving mixed file sizes for an hour. Protocol overhead, controller and cable quality, thermal throttling on compact readers, small-file directory overhead, and — critically — a shared bus (a laptop's single Thunderbolt controller feeding two drives at once) all eat into the advertised number. This calculator uses sustained, real-world figures on purpose, because a schedule built on line-rate marketing numbers is a schedule that is wrong every single day.

xxHash vs MD5: the checksum speed trap

Algorithm choice matters more than most DITs assume. xxHash64 processes data fast enough that it is never the limiting factor on any interface in this table — hashing keeps pace with the drive. MD5, still the default in some older or simpler tools, is single-threaded and tops out at roughly 500 MB/s no matter how fast the drive underneath it is. Select MD5 in this calculator and watch the verify phase on a fast NVMe chain: the governing rate drops from the drive's 2,200 MB/s to a flat 500 MB/s, because the checksum, not the storage, has become the bottleneck. On a spinning HDD it makes no difference — the drive was already slower than 500 MB/s. On modern SSD and NVMe workflows, though, MD5 can roughly quadruple your verify time for no security benefit; use xxHash64 or BLAKE3 wherever the tool supports it.

Where the time actually goes

The uncomfortable truth in the worked example above: the fast card and the fast primary drive are not the schedule problem. The slow second-copy target is. Real offload tools like Silverstack, Hedge and OffShoot can parallelize the primary and second copy to shave real time off that total — this calculator models the conservative sequential case, which is the honest ceiling, not the best-case floor. If your backup drive is routinely the reason a wrap takes an extra two hours, the practical fix is not a faster checksum — it's a faster shuttle drive. Swapping a 7200 rpm HDD for a SATA or NVMe SSD on the second copy turns a 104-minute leg into single digits, and turns "backup while the truck idles" into "backup while you coil cable."

1. Enter how much footage is on the card and pick your source reader and destination interface.

2. Leave the second copy switched on if you back up twice at wrap, the way most sets do.

3. Read each bar and the bottleneck named on it, then price the upload leg with the File Transfer Time Calculator.