[Gllug] Calculating 'real' bandwidth

[Russell Howe]

On Tue, Mar 13, 2007 at 03:56:35PM +0000, John Hearns wrote:
> Or indeed to run Netperf http://www.netperf.org/netperf/
> 
> I guess though that the server machine should be on a reasonable high 
> bandwidth leased line, ie. much higher bandwidth than the home ADSL.
> If you were to run it between two different home ADSL links you wouldn't 
> be measuring solely that one line.

Running it between two ADSL lines would be pretty disappointing since
one line would be receiving and the other sending, and due to the 'A' in
ADSL, and the fact that the asymmetry is always the same way (at least
on all the ADSL lines I've ever seen), you'd only ever see what the
max. speed of each end's upstream was.

Please feel free to point out the inevitable errors in the following. My
ATM knowledge is sketchy, as is my PPP knowledge, as is my ADSL
knowledge, and I know next to nothing about the UK's ADSL implementation
at all!

8128 Kbit/s of ATM data rate.. well, looking at my ATM pocket guide, and
assuming that we're talking AAL5 here (which AFAIK is about the only AAL
anyone ever bothers using these days), we have:

Pretty bad case, a TCP ACK

20 byte (160 bit) TCP header, no data (let's assume no options)
	2 bytes for the source port
	2 bytes for the destination port
	4 bytes for the sequence number
	4 bytes for the acknowledgement number
	1 byte for the data offset and reserved fields
	1 byte for flags
	2 bytes for the window information
	2 bytes of checksum
	2 bytes for the urgent pointer
	[no data]

Running total: 20 bytes

This then has an IP header added to it:

20 byte (160 bit) IP header (again, no options)
	1 byte for version & length of header
	1 byte for diffserv+ECN info
	2 bytes for the length of the datagram
	2 bytes of ID info
	2 bytes for flags & the fragment offset
	1 byte for the TTL value
	1 byte for the protocol number
	2 bytes for the IP checksum
	4 bytes for the source IP address
	4 bytes for the destination IP address

Running total: 40 bytes

This then gets encapsulated with PPP:
	2 bytes of header (0x0021)

Running total: 42 bytes

This then gets encapsulated within ATM using PPP over ATM (using AAL5,
which is all anyone seems to use these days):
	8 bytes of trailer in the CPCS-PDU
	46 bytes of padding to bring us up to a multiple (96) of 48 bytes

Running total: 96 bytes

This will then go out over ATM in 2 cells, 53 bytes each:
	5 bytes of ATM header in cell #1
	5 bytes of ATM header in cell #2

Running total: 106 bytes

So, without transmitting /any/ data, we have transmitted 106 bytes (OK,
OK, octets). So, by my reckoning, you can do about 77,283 TCP ACKs per
second on an 8192Kbit/s ADSL line, assuming that 8192Kbit/s is the raw
ATM rate.

So, how about a 1500 byte TCP packet?

Well, we have 20 bytes of IP header = 20 bytes
+ 20 bytes of TCP header            = 40 bytes
+ 1500 bytes of data                = 1540 bytes
+ 2 bytes of PPP header             = 1542 bytes
+ 8 bytes of CPCS-PDU trailer       = 1550 bytes
+ 34 bytes of padding to bring us
  up to a multiple of 48 bytes      = 1584 bytes
+ 5 bytes of ATM cell header for
  each 48 bytes of SAR PDU
+ 33 * 5 = 165 bytes                = 1749 bytes

So to transmit 1500 bytes of TCP, you need 1749 bytes of network
capacity, or in other words, ADSL has 16.6% overheard for TCP in the
best case scenario.

Well, the best case would strictly speaking be when you don't pad
anything out, so 1500 - 34 = 1466 bytes, which reduces the above to:
* 34 fewer bytes of data
* 34 fewer bytes of padding
* 5 fewer bytes of ATM cell header (one less cell)

Giving a final transmission size of 1676 bytes, a slightly more
respectable overhead of 14.2% by my reckoning.

So, you can transfer about 610 1466 byte TCP packets on your
8192Kbit/s ADSL link per second, equating to 894,260 bytes per second,
which is 873Kbyte/s or 7.15Mbit/s

However, if your MTU is 1500 bytes, and your TCP stack is happily using
the full MTU, you will get slightly less - 585 per second, equating to
877,500 bytes per second which is 856Kbyte/s or 7.02Mbit/s

A more interesting (to me, at least, YMMV) calculation is then "How much
of my upstream bandwidth do the ACKs take if I'm downloading at
856Kbyte/s?"

Well, we know how big an ACK is, and we know how many packets per second
need ACKing (585), so it's easy - 106 * 585 = 62010 bytes/s of ACKs,
which is 496,080 bits/s

Yep, that's right, 500Kbit/s of upstream is taken just ACKing your
downstream TCP traffic if you're going at full pelt!

If you were running optimally, it's slightly worse - at 610 TCP packets
per second, that's 64,660 bytes/s or 517,280 bits/s of upstream
bandwidth taken up by TCP ACKs

-- 
Russell Howe       | Why be just another cog in the machine,
rhowe at siksai.co.uk | when you can be the spanner in the works?
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug