WAND Network Research Group University of Waikato Crest Of Arms

Factors limiting bandwidth

This tool was written by my friend Perry from WAND, and allows you to check the top speeds possible due to limitations I have been meaning to tidy up the template, but have been too busy, and thought it was just far too cool to keep hidden. Phase 2 would be to make it look more "ADSLgeek-like" and then automatically detecting all these settings.

This page calculates the theoretical maximum TCP throughput based on the specified parameters. You are unlikely to achieve this speed in the real-world due to other protocol overheads and competing traffic.

Based on upstream ack bandwidth:

Upstream bandwidth Bits/s
Upstream bandwidth 16,000.00 Bytes/s
ACK size Bytes
ACKs/s 400.00 packets/s
Delayed acks Count
MSS Bytes
Bytes/ack 2,920.00 Bytes/ack
Maximum tcp download bandwidth 1,168,000.00 Bytes/s
9,344,000.00 Bits/s

Based on window sizes:

RTT ("ping") ms
Window size Bytes
Bandwidth delay product 1,051.20 Byte seconds
Maximum tcp download bandwidth 292,000.00 Bytes/s
2,336,000.00 Bits/s

Based on packet loss

MSS 1,460.00 Bytes
RTT 60.00 ms
RTO 240.00 ms
Delayed Acks 2 acks
Packet loss %
Maximum tcp download bandwidth 660,451.52 Bytes/s
5,283,612.19 Bits/s

Limit (based on all the above)

Maximum tcp download bandwidth 292,000.00 Bytes/s
2,336,000.00 Bits/s
Limit reason Window Size

Notes:

  • My math is horrible, check what I'm saying! This is all off the top of my head, it's probably WRONG.
  • Windows uses 40 byte acks, Linux 52. if ethernet is run on the slowest link, the minimum size for an ack becomes 46 bytes. (ethernet has a 60 byte minimum packet size, and a 14 byte header)
  • You'll NOT get the theoretical maximum throughput as limited by upstream bandwidth, as this assumes one tcp connection under perfect conditions. Multiple connections will be slower
  • Linespeeds are often serialisation rate, over the top of that you have framing, FEC, and other crap. What bandwidth you'll actually recieve is not obvious.
  • Most hosts send delayed acks every 2 acks, some every ack (1). When dealing with massively assymetric links, hacking your stack to support 3 would seem to be the best solution (and it's a reciever solution, not a sender one too as an added bonus)
  • Default Window sizes for various OS versions
    Windows 98 8192
    Windows 2000 17520
    Linux 65535
    FreeBSD 65536
    Windows XP* 17520
    MSDN** 8760
    * windows XP apparently has some undocumented way of selecting this
    ** This uses the algorithm from an MSDN article which seems waay too low.
  • Windows size limited downloads are limits per TCP connection, so P2P apps can exceed this limit.
  • windows 2000+ and linux can both have windows larger than 64k, 98 can't,
  • MSDN article including the selected window size for windows 2003
  • How to tweak your window sizes
  • Throughput calculation formula
  • RFC3448: TCP Friendly Rate Control (TFRC): Protocol Specification. -- Formula used for Throughput under packet loss.
Originally by Perry Lorier