On 16:46:18 Oct 24, Pierre Riteau wrote:
> Because the delay between the two machines is very low.
> It appears you need to read about bandwidth-delay product as well.
>
Actually it is quite a deep concept.
How TCP "guesses" the bandwidth is quite a challenge.
And often TCP gets it wrong.
It is Shannon's noisy channel coding theorem that determines the
bandwidth of any channel be it wired or wireless.
TCP "guesses" the speed at which it can send data using very
sophisticated algorithms and protocols.
Numerous papers have been written on this topic but the long and short
of it is this:
Your network bandwidth is often underutilized and the best way
to get the best out of it is to use multiple TCP connections(not
threads...please don't get me wrong here). This will solve the
problem when the bottleneck is in your LAN but otherwise it will
not help(at all) . In fact this is the technique employed by
all download accelerators including the downthemall FF
extension.
Now the TCP send and receive buffers that Otto suggested (BTW I
had the same problem as Sebastian and Otto helped me offlist)
help TCP's bandwidth guessing algorithm to accurately guess the
buffer sizes or to be precise the TCP window sizes to match the
bandwidth delay product in common scenarios(ADSL and roundabout
bandwidths). So I always add 65536 to my /etc/sysctl.conf.
IOW this value helps TCP to "fill the pipe" so to speak.
Now why doesn't OpenBSD ship with these values as the default? Long ago
sthen@ answered this. It would consume more kernel memory on the low end
hardware we support.
(Maybe it is time for us to take a look at the default value again)
You can read more about this here.
http://www.linuxjournal.com/article/9815
One way to look at the bandwidth delay product vis a vis available
bandwidth is this.
Let us take a satellite link for example. Satellites have very good
bandwidth as they operate in the higher microwave frequencies but the
packets have to travel 72,000 kms(36,000 x 2 Geo synchronous satellites)
and hence they have a latency of ~ 470 milliseconds.
Now how can TCP figure this out?
It looks at the round trip times of the three packets involved in the
three way handshake(let us keep it simple).
It exponentially increases its speed till it gets a packet loss. And
then it backs off.
It uses two parameters called alpha and beta internally. Anyway I hope I
did not bore you folks.
Many thanks.
-Girish
