lfs-3.3.tar downloaded 10,000+ times
darkyeti at gmx.net
Mon Sep 30 04:24:39 PDT 2002
On 2002-09-29 12:16, Antony Stone wrote:
> It's impossible to do an exact calculation, because there's no fixed number
> of bytes inside an IP packet. There's a maximum number of bytes inside an
> ethernet frame, however, and that's 1500, so if we assume for the moment that
> everyone was downloading full-size ethernet frames, then out of every 1500
> bytes, 24 bytes are the IP header, and 24 bytes are the TCP header, so we
> have 1452 left over for data.
it might even be worse if the packet needs to traverse a network with an
mtu < 1500 (or whatever it was sent with).
the packet would be fragmented and each fragment sent with its own ip
header of 20 bytes (the tcp header is not repeated as the fragmentation
is done on the routing layer which doesn't know a thing about the
although that would not change the bandwidth used on the lfs server it
would increase the number of bytes to be downloaded by the individual
user who happens to sit in or behind (meaning that the ip packets travel
through it) a network with a mtu < 1500.
neverthless this would add (n-1)*20 bytes to the throughput for n fragments
for every single packet that needs to be fragmented.
iirc the minimum required mtu is 576. a single ip packet of 1500 bytes
can therefore be split up into three fragments. i leave it to you to
establish some kind of lower bound for the actual throughput.
all that would only hold true in a internetwork without packet loss or
delay. the lfs server would have to retransmit whole ip packets adding
to the load of the local network segment and decreasing the throughput
of the transfer.
ps: another interesting figure would then be the goodput measuring how
long the transfer of the actual data took.
rakshas at quietude // C23C1939 // 7793747 // rakshas dot de
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-chat' in the subject header of the message
More information about the lfs-chat