Resumable Chunked Upload Simulator

Upload Parameters

Chunk size 4 MB

Parallel workers 3

Network reliability 85%

Uplink bandwidth 12 Mbps

Live Readouts

Elapsed

0.0 s

Throughput

0.0 Mbps

Chunks done / total (retries)

0 / 16 (0 retries)

Legend

Queued chunk Uploading Backing off (retry) Stored in cloud Failed permanently

How it works

A file of fixed size is split into equal chunks, each uploaded through its own presigned-URL PUT request. A fixed pool of parallel workers pulls chunks off a FIFO queue; the shared uplink bandwidth B is split evenly across the workers currently transmitting:

rate_per_worker = B / n_active_workers   (Mbps)
attempt_time    = (chunk_size_MB * 8) / rate_per_worker   (s)

When an attempt finishes, it succeeds with probability equal to the network-reliability slider. A failed attempt is retried on the same chunk using exponential backoff, capped at 8 seconds:

backoff(k) = min(0.6 * 2^k, 8)  seconds,  k = retry count

After 5 failed attempts a chunk is abandoned and marked permanently failed — the same limit a real mobile upload SDK (e.g. AWS S3 TransferUtility, Google Cloud Storage resumable uploads) enforces before surfacing an error to the user. Only chunks that finish resumable and intact count toward throughput, so raising failure probability or shrinking the worker pool visibly drags down effective Mbps even though the raw uplink speed hasn't changed.

Chunk size — smaller chunks retry cheaper after a drop but add per-request overhead; larger chunks waste more work when a late attempt fails.
Parallel workers — more workers fill the uplink faster but each gets a thinner bandwidth slice, and a lossy link punishes many small partial retries at once.
Reliability — the probability any single attempt completes without a timeout/drop, mimicking mobile network handoffs.
Bandwidth — the total uplink capacity shared by all active workers.

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.