Source: https://guthlabs.ai/docs/instruments/latency-bandwidth-transfer-time-calculator/mechanism/

instrument mechanism / verified-clean

# Latency / Bandwidth / Transfer-Time Calculator mechanism

The inspectable method record for Latency / Bandwidth / Transfer-Time Calculator, kept separate from implementation and qualification.

Status: **VERIFIED_CLEAN**Lifecycle: **verified-clean**

## Model scope

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.

- 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.

## Units and conventions

- 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.

## Inspectable vector

One of 4 source-bound review vectors:

````
{
  "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."
}
````

## Failure boundary

**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.

## Other records

[01**Overview**](<https://guthlabs.ai/docs/instruments/latency-bandwidth-transfer-time-calculator/>)[03**Implementation**](<https://guthlabs.ai/docs/instruments/latency-bandwidth-transfer-time-calculator/implementation/>)[04**Qualification**](<https://guthlabs.ai/docs/instruments/latency-bandwidth-transfer-time-calculator/qualification/>)

## Sources and evidence

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

- `VERIFIED_LEDGER.json`

- `evidence-tranche4/tranche4-results.json`

- `BOUNDARY_HAZARD_CATALOG.json`