Propagation Delay Calculator

The calculator models RTT as a full request-then-response exchange, so the signal makes the trip twice (there and back) and a packet of the same size is transmitted twice (once each direction). That's why rttMs is exactly 2 × (propagation delay + transmission delay) rather than just 2 × propagation delay — it assumes the return packet is comparable in size to the outbound one, which overstates RTT for protocols where the response is a small acknowledgment.

Velocity factor depends on how much a medium's dielectric slows electromagnetic waves relative to a vacuum, and glass fiber's effective index and coax's dielectric insulation happen to produce similar slowdown factors even though the two technologies work on completely different principles (guided light versus electrical signaling). Cat6 copper's 0.64 is slightly lower still, reflecting its own insulation properties — none of these come close to free space's factor of 1.0.

It's the number of bits that are in transit on the link at any given instant — computed here as data rate times round-trip time, then converted to kilobytes. This is the theoretical minimum buffer or TCP window size needed to keep the link fully utilized without stalling while waiting for acknowledgments, which is why long-distance, high-bandwidth links ('long fat networks') need proportionally larger buffers.

Propagation delay in this calculator depends only on distance and the medium's velocity factor (a fraction of the speed of light) — data rate never enters that formula. Only transmission delay, the time to push a packet's bits onto the wire, shrinks as data rate increases, so for long-haul links like satellite or transoceanic fiber, propagation delay dominates and no bandwidth upgrade will meaningfully cut total latency.