Rsync slow as heck for everyone else???

Jar Jar Binks wrote:
Here we will see if we can reproduce your problem with our freebsd machine.

Please keep me informed. I would prefer to keep this in place3 as changing would be a hassle. I was able to reproduce the same behavior using VMWare, so you should be able to do this virtual if you need to.

Chris

Any results from testing? Are you seeing the same behavior?

cgreentx wrote:
Any results from testing? Are you seeing the same behavior?

We have it reproduced. We have some ideas and the guys are working on it.

cgreentx wrote:
Any results from testing? Are you seeing the same behavior?

Can you check the value of "delayed_ack" for your FreeBSD system? If you can change that option to equal 0, should be able to solve this problem for now. Here is for your reference:
sysctl net.inet.tcp.delayed_ack=0

We are working on a better solution now.

heh...isn't the darwin network stack similar/based-on to the bsd one? :)

-brendan

Someone call this problem as "delayed ACK stall", here is a very good doc about it, and you can find more by google it:

http://www.isi.edu/lsam/publications/ph ... node2.html

It is sure the delayed ACK settings in FreeBSD or BSD systems (like MACs) will cause slow performance with ReadyNAS. And it seems that can cause similar problem with other systems.

We will try our best to find a reasonable and generic solution in our system, but BSD users have to turn delayed ACK off before we reach that target. And turn that off also will give you best performance with ReadyNAS, and also might improve BSD network performance in general.

How will this affect normal use of the boxes? These machines serve up web/email/ftp for mlutiple sites and I want to be careful about settings that may impact other applications.

Chris Green

Initial tests on the local LAN using my test box are promising. I would like to know what impact this setting can have on other stuff before it is moved to production and I am curious if you can find something to work around it on the NAS side.

Chris

updates?

cgreentx wrote:
Initial tests on the local LAN using my test box are promising. I would like to know what impact this setting can have on other stuff before it is moved to production and I am curious if you can find something to work around it on the NAS side. Chris

Setting delay_ack to 0 shouldn't cause compatibility issue -- it's essentially saying ack on every packet instead of ack on possibly multiple packets. If anything, in some cases, turning off delay_ack may actually improve performance.