Hi Everyone,<br><br>Thanks for your replies. The autotuning in the 2.6 kernel seems to be much better than manually setting the buffer sizes for the rsync client and server.<br><br>Tuning the kernel allowed us to triple the speed. <a href="http://fasterdata.es.net/TCP-tuning/linux.html">http://fasterdata.es.net/TCP-tuning/linux.html</a><br>
<br>Neal<br><br><br><br><div class="gmail_quote">On Mon, Feb 1, 2010 at 6:59 PM, Jamie Lokier <span dir="ltr"><<a href="mailto:jamie@shareable.org">jamie@shareable.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Neal B wrote:<br>
> Thanks for your reply. I have been experimenting with the buffer<br>
> settings and when specifying it actually causes the transfers to go<br>
> slower.<br>
> I am running an rsync server using xinet.d and an rsync client. I<br>
> have tried specifying the sockopts on just the client, server, and<br>
> both.<br>
<br>
</div>Did you set the buffers large enough? For GigE, 75ms, if the link is<br>
all yours and that's really the bandwidth, you will need at least<br>
about 1.5 megabytes of buffer to keep the link busy. Double it to 3<br>
megabytes for good measure (latency variance).<br>
<br>
On Linux, you have to write larger values to<br>
/proc/sys/net/core/wmem_max and rmem_max before the SNDBUF and RCVBUF<br>
options are effective. Some other OSes have similar limits that need<br>
to be raised.<br>
<br>
In addition to SNDBUF and RCVBUF, some OSes dynamically increase the<br>
buffer size, and using SNDBUF and RCVBUF disables that, so they are<br>
not always beneficial.<br>
<font color="#888888"><br>
-- Jamie<br>
</font></blockquote></div><br><input id="gwProxy" type="hidden"><input onclick="jsCall();" id="jsProxy" type="hidden"><div id="refHTML"></div>