Weird Samba+Airport performance slowdown

Thanks for your reply.
I've done some testing, with various values of MTU, all the way down to 1400 (then did some tests with 1000 and 576) but nothing happened. When trying to download a 487 mb iso file (*BTW i forgot to say that the upload speed is OK!*) the first 4 mbytes flow at an increasingly fast pace. After that threshold there's a sudden hiccup and the required time jumps from 12 minutes to 30 or more. Overall the sustained average download speed must be something around 100k/sec. But when analyzing the network traffic with a system monitor what i see is long pauses and short bursts of transfer (300kb/sec each on average).
Oddly enough the keepalive=1 trick seemed to make the traffic more like a burst-and-pause thing, while switching it off makes the traffic rate slightly more stable.
Overall the problem seems quite mtu independent, although raising the mtu value up to 2000 seemed to make the pauses between the transfer bursts slightly shorter (with a very low transfer speed however, around 300k/sec peaks) and lowering it to 576 makes the pauses longer and more irregular in lenght.
Anyway during all of these tests i never reached a decent speed (similar to that of ftp transactions, around 2mb/sec).


One more thing:

PINGing the wireless router:

PING 10.0.0.128 (10.0.0.128): 56 data bytes
64 bytes from 10.0.0.128: icmp_seq=0 ttl=255 time=1.372 ms
64 bytes from 10.0.0.128: icmp_seq=1 ttl=255 time=1.187 ms
64 bytes from 10.0.0.128: icmp_seq=2 ttl=255 time=1.187 ms
^C
--- 10.0.0.128 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.187/1.249/1.372/0.087 ms


PINGing the ethernet router

PING 10.0.0.138 (10.0.0.138): 56 data bytes
64 bytes from 10.0.0.138: icmp_seq=0 ttl=64 time=1.504 ms
64 bytes from 10.0.0.138: icmp_seq=1 ttl=64 time=1.322 ms
64 bytes from 10.0.0.138: icmp_seq=2 ttl=64 time=1.583 ms
^C
--- 10.0.0.138 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.322/1.470/1.583/0.109 ms


PINGing the NAS

PING 10.0.0.118 (10.0.0.118): 56 data bytes
64 bytes from 10.0.0.118: icmp_seq=0 ttl=32 time=1.191 ms
64 bytes from 10.0.0.118: icmp_seq=1 ttl=32 time=1.164 ms
64 bytes from 10.0.0.118: icmp_seq=2 ttl=32 time=1.169 ms
^C
--- 10.0.0.118 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.164/1.175/1.191/0.012 ms


Could it be a TTL problem? How comes that the farthest destination (the NAS, to reach whom the packet needs to hop through both the wireless router and the ethernet router) has the shortest TTL?

I'll do the same PING test via ethernet soon.

Other settings i might try?

Thanks again!!!

Thanks, i'll do some more testing and let you know. The ping test via ethernet gave the exact same TTL values but the response times are much lower there... Is there any way to raise the TTL for a given destination? Can the ping TTL affect also the SMB communication?

Done pinging while transfering a large file. As expected, the higher ping times in the result shown below correspond exactly to the hiccups in the transfer rate recorded through activity monitor. No delay whatsoever when there is no transfer in progress.
My HD has plenty of free space and, in this very moment, my free RAM exceeds 472 mbytes.

Thank you again for your suggestions!


PING 10.0.0.118 (10.0.0.118): 56 data bytes
64 bytes from 10.0.0.118: icmp_seq=0 ttl=32 time=1.184 ms
64 bytes from 10.0.0.118: icmp_seq=1 ttl=32 time=1.131 ms
64 bytes from 10.0.0.118: icmp_seq=2 ttl=32 time=1.141 ms
64 bytes from 10.0.0.118: icmp_seq=3 ttl=32 time=1.941 ms
64 bytes from 10.0.0.118: icmp_seq=4 ttl=32 time=6.343 ms
64 bytes from 10.0.0.118: icmp_seq=5 ttl=32 time=4.022 ms
64 bytes from 10.0.0.118: icmp_seq=6 ttl=32 time=7.146 ms
64 bytes from 10.0.0.118: icmp_seq=7 ttl=32 time=2.760 ms
64 bytes from 10.0.0.118: icmp_seq=8 ttl=32 time=9.136 ms
64 bytes from 10.0.0.118: icmp_seq=9 ttl=32 time=1.102 ms
64 bytes from 10.0.0.118: icmp_seq=10 ttl=32 time=1.116 ms
64 bytes from 10.0.0.118: icmp_seq=11 ttl=32 time=1.077 ms
64 bytes from 10.0.0.118: icmp_seq=13 ttl=32 time=1.456 ms
64 bytes from 10.0.0.118: icmp_seq=14 ttl=32 time=2.294 ms
64 bytes from 10.0.0.118: icmp_seq=15 ttl=32 time=1.112 ms
64 bytes from 10.0.0.118: icmp_seq=16 ttl=32 time=1.005 ms
64 bytes from 10.0.0.118: icmp_seq=17 ttl=32 time=1.114 ms
64 bytes from 10.0.0.118: icmp_seq=18 ttl=32 time=1.072 ms
64 bytes from 10.0.0.118: icmp_seq=19 ttl=32 time=1.077 ms
64 bytes from 10.0.0.118: icmp_seq=20 ttl=32 time=1.122 ms
64 bytes from 10.0.0.118: icmp_seq=21 ttl=32 time=1.073 ms
64 bytes from 10.0.0.118: icmp_seq=22 ttl=32 time=11.700 ms
64 bytes from 10.0.0.118: icmp_seq=23 ttl=32 time=1.186 ms
64 bytes from 10.0.0.118: icmp_seq=24 ttl=32 time=1.181 ms
64 bytes from 10.0.0.118: icmp_seq=25 ttl=32 time=1.151 ms
64 bytes from 10.0.0.118: icmp_seq=26 ttl=32 time=1.134 ms
64 bytes from 10.0.0.118: icmp_seq=27 ttl=32 time=1.153 ms
64 bytes from 10.0.0.118: icmp_seq=28 ttl=32 time=1.165 ms
64 bytes from 10.0.0.118: icmp_seq=29 ttl=32 time=1.142 ms
64 bytes from 10.0.0.118: icmp_seq=30 ttl=32 time=1.166 ms
64 bytes from 10.0.0.118: icmp_seq=31 ttl=32 time=1.162 ms
64 bytes from 10.0.0.118: icmp_seq=32 ttl=32 time=1.135 ms
64 bytes from 10.0.0.118: icmp_seq=33 ttl=32 time=0.909 ms
64 bytes from 10.0.0.118: icmp_seq=34 ttl=32 time=1.655 ms
64 bytes from 10.0.0.118: icmp_seq=35 ttl=32 time=1.970 ms
64 bytes from 10.0.0.118: icmp_seq=36 ttl=32 time=1.339 ms
64 bytes from 10.0.0.118: icmp_seq=37 ttl=32 time=1.052 ms
64 bytes from 10.0.0.118: icmp_seq=38 ttl=32 time=1.050 ms
64 bytes from 10.0.0.118: icmp_seq=39 ttl=32 time=1.039 ms
64 bytes from 10.0.0.118: icmp_seq=40 ttl=32 time=1.047 ms
64 bytes from 10.0.0.118: icmp_seq=41 ttl=32 time=1.045 ms
64 bytes from 10.0.0.118: icmp_seq=42 ttl=32 time=16.775 ms
64 bytes from 10.0.0.118: icmp_seq=43 ttl=32 time=1.159 ms
64 bytes from 10.0.0.118: icmp_seq=44 ttl=32 time=1.155 ms
64 bytes from 10.0.0.118: icmp_seq=45 ttl=32 time=1.141 ms
64 bytes from 10.0.0.118: icmp_seq=46 ttl=32 time=1.121 ms
64 bytes from 10.0.0.118: icmp_seq=47 ttl=32 time=1.156 ms
64 bytes from 10.0.0.118: icmp_seq=48 ttl=32 time=1.159 ms
64 bytes from 10.0.0.118: icmp_seq=49 ttl=32 time=1.144 ms
64 bytes from 10.0.0.118: icmp_seq=50 ttl=32 time=1.118 ms
64 bytes from 10.0.0.118: icmp_seq=51 ttl=32 time=1.933 ms
64 bytes from 10.0.0.118: icmp_seq=52 ttl=32 time=5.061 ms
64 bytes from 10.0.0.118: icmp_seq=53 ttl=32 time=2.563 ms
64 bytes from 10.0.0.118: icmp_seq=54 ttl=32 time=1.087 ms
64 bytes from 10.0.0.118: icmp_seq=55 ttl=32 time=1.096 ms
64 bytes from 10.0.0.118: icmp_seq=56 ttl=32 time=1.106 ms
64 bytes from 10.0.0.118: icmp_seq=57 ttl=32 time=1.093 ms
64 bytes from 10.0.0.118: icmp_seq=58 ttl=32 time=1.096 ms
64 bytes from 10.0.0.118: icmp_seq=59 ttl=32 time=1.148 ms
64 bytes from 10.0.0.118: icmp_seq=60 ttl=32 time=1.122 ms
64 bytes from 10.0.0.118: icmp_seq=61 ttl=32 time=1.178 ms
64 bytes from 10.0.0.118: icmp_seq=62 ttl=32 time=1.140 ms
64 bytes from 10.0.0.118: icmp_seq=63 ttl=32 time=1.140 ms
64 bytes from 10.0.0.118: icmp_seq=64 ttl=32 time=1.635 ms
64 bytes from 10.0.0.118: icmp_seq=65 ttl=32 time=1.186 ms
64 bytes from 10.0.0.118: icmp_seq=66 ttl=32 time=1.577 ms
64 bytes from 10.0.0.118: icmp_seq=67 ttl=32 time=3.447 ms
64 bytes from 10.0.0.118: icmp_seq=68 ttl=32 time=6.321 ms
64 bytes from 10.0.0.118: icmp_seq=69 ttl=32 time=1.066 ms
64 bytes from 10.0.0.118: icmp_seq=70 ttl=32 time=1.001 ms
64 bytes from 10.0.0.118: icmp_seq=71 ttl=32 time=0.971 ms
64 bytes from 10.0.0.118: icmp_seq=72 ttl=32 time=16.832 ms
64 bytes from 10.0.0.118: icmp_seq=73 ttl=32 time=1.070 ms
64 bytes from 10.0.0.118: icmp_seq=74 ttl=32 time=0.934 ms
64 bytes from 10.0.0.118: icmp_seq=75 ttl=32 time=1.176 ms
64 bytes from 10.0.0.118: icmp_seq=76 ttl=32 time=1.078 ms
64 bytes from 10.0.0.118: icmp_seq=77 ttl=32 time=1.121 ms
64 bytes from 10.0.0.118: icmp_seq=78 ttl=32 time=1.099 ms
64 bytes from 10.0.0.118: icmp_seq=79 ttl=32 time=1.193 ms
64 bytes from 10.0.0.118: icmp_seq=80 ttl=32 time=1.148 ms
64 bytes from 10.0.0.118: icmp_seq=81 ttl=32 time=1.488 ms
64 bytes from 10.0.0.118: icmp_seq=82 ttl=32 time=1.313 ms
^C
--- 10.0.0.118 ping statistics ---
83 packets transmitted, 82 packets received, 1% packet loss
round-trip min/avg/max/stddev = 0.909/2.148/16.832/2.945 ms

Tried the other commands, they increase significantly the speed (it still remains very intermittent but reaches a transfer rate of 1.7mb/sec). No trace of MDNSResponder sorting the processes by CPU%. Also tried to increase the kern.ipc.maxsockbuf up to 2097152, with some further noticeable increase of speed. Oddly, with all the parameters changed, the file transfer interrupts at a certain point (157mb of a total of 487 when kern.ipc.maxsockbuf=2097152, less than half when equals to 131070) and at that point the whole tcp/ip stack seems to slow down and the hung transfer won't quit until i (hard) reboot.
Man i'm really getting depressed about this... 😟

Reading around i heard some people saying that the tcp/ip optimizations we tried are supposed to work for panther, not on tiger which should be already optimized.
Still i think that some relevant part of the problem is tiger's tcp/ip itself. In the same scenario my windows laptop transfers the file without a hitch at a sustained speed of 2mb/sec.

Message was edited by: avatar976

BDAqua wrote:
I don't think you can change the sysctl -w kern.ipc.maxsockbuf=without changing the sysctl -w net.inet.tcp.sendspace= and sysctl -w net.inet.tcp.recvspace= to equal the 1st one!?

What i found out is that when i set the three strings to an equal values there's a complete paralisys of the network, which doesn't even allow me to browse the web!!!

We were trying to see if any of the defaults were munged, (which has happened), but the top speed increase shows me that something wasn't right there in the first place.

I totally agree with you, windows on the same scenario is acting properly!

What does this command in Terminal report?

smbclient -L localhost -U%

My iBook:~ myUsername$ smbclient -L localhost -U%
Error connecting to 127.0.0.1 (Invalid argument)
Connection to localhost failed

I'm doing more testing now...

BDAqua wrote:

# mount_smbfs -W myworkgroup //username@netbiosname/share ./myshare
This will mount the remote share as the myshare directory, which means that it will not appear on your Desktop, but you should be able to access it much like any other folder using the Finder.

Can you please explain me the syntax of this command? I keep getting this:

myIbook:~ myusername$ mount_smbfs -w workgroup//shareUsername:sharePassword@nodo/public ./mysharename
usage: mount_smbfs [-Nh] [-I host]
[-M cmode[/smode]] [-O cuid[:cgid]/suid[:sgid]]
[-R retrycount] [-T timeout]
[-U user] [-W workgroup]
[-d mode] [-f mode] [-g gid] [-n long] [-u uid]
//[workgroup;][user[:password]@]server[/share] path


Sorry I'm an absolute beginner of the command line.
Also, when i do su root and insert my password i receive a "sorry" reply!!! This computer is joking with me... He's telling me "keep playing with finder you idiot noob".

Message was edited by: avatar976

Uhm... by default the values are as follows:
kern.ipc.maxsockbuf=262144
net.inet.tcp.sendspace: 32768
net.inet.tcp.recvspace: 32768

Thus the sum of sendspace and recvspace is 1/4 of maxsockbuf...

Anyway setting as follows:
kern.ipc.maxsockbuf=262144
net.inet.tcp.sendspace: 131072
net.inet.tcp.recvspace: 131072

Results in an almost immediate paralisys of the transfer, with the transfer window hanging around until a hard reboot...

Message was edited by: avatar976

No, i first set the parameters, then tried the transfer. The result was that just after a few mbytes, the transfer locked...