Latency / Bandwidth / Transfer-Time Calculator

Inspectable records

Ledger state

The current ledger marks this instrument verified clean within the source-bound verification corpus.

Area

Computing & Information

Tranche

tranche-4

Evidence ID

t4-016

Ledger rows

1

No ledger note is attached.

Review findings

The existing honest label is directionally correct, but the instrument should be labeled as an idealized serialization and bandwidth-delay model unless a precise RTT contribution model is added. The exact ambiguity requiring resolution is whether transfer_time means size/bandwidth only or total time including RTT, and, if RTT is included, how many RTTs are to be added.

Formula and scope findings

• t=size/bandwidth is the standard serialization time, assuming size and bandwidth use consistent units, but it does not include the claimed round-trip latency contribution.
• The specification does not define how RTT contributes to total transfer time: adding one RTT is not universally correct, because the number of RTTs depends on protocol behavior, handshakes, acknowledgements, slow start, and transfer size.
• BDP=bandwidth×RTT is standard when bandwidth is in bits per second and RTT is in seconds; the result is an amount of data, normally reported in bits or converted to bytes.
• effective_throughput=min(bandwidth,window/RTT) is the standard idealized window-limited model, but only when bandwidth and window/RTT are converted to the same rate units.

Unit assumptions

• Size must be converted to bits when bandwidth is in bits per second; byte-based sizes require multiplication by 8.
• Bandwidth and effective throughput are assumed to be reported in bits per second unless explicitly converted to bytes per second.
• RTT is assumed to be in seconds for both BDP and window/RTT calculations; millisecond inputs must be divided by 1000.
• TCP window size is assumed to be a byte quantity; it must be converted to bits before comparing window/RTT with a bit-per-second bandwidth, or the result must be reported in bytes per second.
• SI prefixes and binary prefixes must remain distinct: MB=1,000,000 bytes, MiB=1,048,576 bytes, while Mbps means 1,000,000 bits per second.

Boundary hardening

BREAK_CLAIMED · SELF_FLAGGED

A zero-bandwidth input makes transfer time undefined and must be rejected explicitly. The unit-ambiguity vector also produces materially different results if GB/MB are interpreted as binary rather than SI prefixes, so the interface must enforce or display the selected convention.

Errata and corrections

No applied erratum is attached to this unique-name record.

Inspectable example

4 review vectors are recorded. One source-bound sample is shown below.

{
  "inputs": {
    "file_size": 10,
    "file_size_unit": "MB",
    "bandwidth": 100,
    "bandwidth_unit": "Mbps",
    "RTT": 80,
    "RTT_unit": "ms",
    "TCP_window": 1,
    "TCP_window_unit": "MB"
  },
  "expected_outputs": {
    "transfer_time_s": 0.8,
    "BDP_bits": 8000000,
    "BDP_bytes": 1000000,
    "effective_throughput_bps": 100000000
  },
  "working": "10 MB = 10,000,000 bytes = 80,000,000 bits. Transfer time = 80,000,000 bits ÷ 100,000,000 bits/s = 0.8 s. RTT = 80 ms = 0.08 s. BDP = 100,000,000 bits/s × 0.08 s = 8,000,000 bits = 1,000,000 bytes. Window rate = 1,000,000 bytes ÷ 0.08 s = 12,500,000 bytes/s = 100,000,000 bits/s. Effective throughput = min(100,000,000, 100,000,000) = 100,000,000 bits/s."
}

Related workflows

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

• VERIFIED_LEDGER.json · VERIFIED_CLEAN
• evidence-tranche4/tranche4-results.json
• BOUNDARY_HAZARD_CATALOG.json