Now since you tackled this, is there a function that can give me the RTT on a link. Assume that i am writing an application and i want to make my buffer dynamic according to the RTT of the link so i can always get the maximum of the network.
On 11/26/05, Yaman Saqqa <[EMAIL PROTECTED]> wrote:
Well, let me start off by giving the credit of the technical info Im
mentioning next to Brian Tierney.
Let's say you're writing a small program to tranfer file from one
machine to another on a 100Mbs network.
Let's consider two important equations:
Throughput = buffer size / latency
So to get a better throughput we want a higher buffer size and a lower
latency. Lower latency is usually imrpoved at network level so we'll
leave that at the moment.
Let's look at buffer size:
buffer size = RTT * bandwidth
A simple ping between the two machines can get you the Round Trip Time.
So for a 100Mbs bandwidth and say a (.3 ms) RTT on a LAN - I was
pinigin Ammar's box - an ideal buffer size = .0003s * 100Mbps = .03Mb
=~ 3900 Bytes. OK now let's look at the tcp buffer size on my Mac:
net.inet.tcp.sendspace: 32768
net.inet.tcp.recvspace: 32768
Hmm .. well that's 32K ... pretty good eh?
Yet the problem appears somewhere else. Let's say I'm transferring the
same file with the same bandwidth over a WAN link (Internet maybe,
VPN, you name it). My RTT can go up to something close to 300ms ...
well in this case:
buffer size (ideal) = .3s * 100Mbps = 3.75MBytes!!!!
How much do I have? 32K?
So when opening my socket I'd be really dumb not to play with the
system's TCP buffer size and push it up a lil' bit! With the C
language check the manpage of setsockopt.
Of course the OS usually has a maximum TCP buffer size that you can
ask you're Admin to increase it (use sysctl) On linux the kernel
variables look like this:
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
Bare in mind of course that we're tackling this problem from an
application point of view and for the specific case of High
Bandwidth/High Latency networks.
Hope that was beneficial!
On 11/22/05, Yaman Saqqa <[EMAIL PROTECTED]> wrote:
> Hi Guys,
>
> Anybody ever noticed how scp has always been significantly slower than for
> example a traditional FTP transfer? Well, I was reading an article about TCP
> performance tuning and it was discussing playing with the TCP buffer size
> (with socket options) so as to gain better bandwidth optimization (if any
> body is interested in the details I can spend 5 minutes on a sequel email).
> The interesting piece that I found is that OpenSSH suite (of which scp is a
> member) uses "statically defined internal flow control buffers" that limit
> the TCP buffer from getting larger which results in underutilization of the
> bandwidth! The Pittsburgh super computing center have their own patched
> version to overcome this.
>
> I just thought it was worth sharing as I have noticed this issue a couple
> of years back but just figured it out the trick!
>
> Happy Hacking
>
> --
> abulyomon
>
> www.KiLLTHeUPLiNK.com
--
abulyomon
www.KiLLTHeUPLiNK.com
_______________________________________________
General mailing list
[email protected]
http://mail.jolug.org/mailman/listinfo/general_jolug.org
--
Khamis Siksek
When they thought of finding another name for FreeSoftware, they thought of OpenSource and KhamisSiksek ...
.
.
.
They chose the wrong one :-(
_______________________________________________ General mailing list [email protected] http://mail.jolug.org/mailman/listinfo/general_jolug.org
