AC86U SMB Tweaking

[Adamm]

So I recently purchased a 2TB WD Elements HDD for the purpose network storage, I formatted this drive ext4. I noticed pretty fast that SMB default values give terrible wireless performance (LAN tests though are great at 100MB/s+ transfer rates).

I decided to-do some tweaking and found some interesting results.

1) Default socket values | Write = 18MB/s - Read = 25MB/s

socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE SO_RCVBUF=65536 SO_SNDBUF=65536

2) Doubled Send/Receive buffers | Write = 30MB/s - Read = 40MB/s

socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE SO_RCVBUF=131072 SO_SNDBUF=131072

3) No buffers specified | Write = 50MB/s - Read = 80MB/s

socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE

Admittedly I can't say I've looked into this area too much, a quick search of the forum showed previous threads with similar recommendations about increasing the buffer size, but nothing mentioning removing the specified buffer all together which so far has given me the best performance. I'm also unsure of what SMB defaults this to when its not specified which is giving the above results or any potential downsides.

If anyone would like to chip in their findings in further improvements I'm all ears, and potentially we can have some of these tweaks added by default as stock performance is quite terrible.


For anyone wishing to replicate this, create the file "/jffs/scripts/smb.postconf" with the following content (and change the second part of the sed command to your desired config).

#!/bin/sh
CONFIG="$1"
sed -i "s~socket options.*~socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE~g" "$CONFIG"

After creating the file, chmod it and restart the nasapps service;

chmod +x /jffs/scripts/smb.postconf

service restart_nasapps

 

[skeal]

So I recently purchased a 2TB WD Elements HDD for the purpose network storage, I formatted this drive ext4. I noticed pretty fast that SMB default values give terrible wireless performance (LAN tests though are great at 100MB/s+ transfer rates).

I decided to-do some tweaking and found some interesting results.

1) Default socket values = 18MB/s

socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE SO_RCVBUF=65536 SO_SNDBUF=65536

2) Doubled Send/Receive buffers = 30MB/s

socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE SO_RCVBUF=131072 SO_SNDBUF=131072

3) No buffers specified = 50MB/s

socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE

Admittedly I can't say I've looked into this area too much, a quick search of the forum showed previous threads with similar recommendations about increasing the buffer size, but nothing mentioning removing the specified buffer all together which so far has given me the best performance. I'm also unsure of what SMB defaults this to when its not specified which is giving the above results or any potential downsides.

If anyone would like to chip in their findings in further improvements I'm all ears, and potentially we can have some of these tweaks added by default as stock performance is quite terrible.


For anyone wishing to replicate this, create the file "/jffs/scripts/smb.postconf" with the following content (and change the second part of the sed command to your desired config).

#!/bin/sh
CONFIG="$1"
sed -i "s~socket options.*~socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE~g" "$CONFIG"

After creating the file, chmod it and restart the nasapps service;

chmod +x /jffs/scripts/smb.postconf

service restart_nasapps

I did this on my arm7 router and it seems to speed things up considerably.

 

[bigeyes0x0]

I can confirm this improves my AC56U SMB speed by 10 to 20% as well.

 

[RussellInCincinnati]

...For anyone wishing to replicate this, create the file "/jffs/scripts/smb.postconf" with the following content (and change the second part of the sed command to your desired config)...

sed -i "s~socket options.*~socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE~g" "$CONFIG"...​

​

Not sure what this sentence intends for us to do to the "sed" command, exactly:

(and change the second part of the sed command to your desired config).​

 

[Adamm]

​

Not sure what this sentence intends for us to do to the "sed" command, exactly:

(and change the second part of the sed command to your desired config).​

The bolded part you would change to the socket config you wish to enable (I posted 3 examples above).

sed -i "s~socket options.*~socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE~g" "$CONFIG"

 

[quaz]

Works great on my AC68U running 382.2beta3 (because of my VPN I need to overclock my router, so I'm stuck with this firmware), a 20% speed increase with double buffer.

 

[Lotta Cox]

Am I doing something wrong?
admin@RT-AC86U:/tmp/home/root# sed -i "s~socket options.*~socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE~
g" "$CONFIG"
sed: : No such file or directory
admin@RT-AC86U:/tmp/home/root#

 

[ColinTaylor]

Am I doing something wrong?

Yes. Re-read post #1.

 

[Lotta Cox]

Yes. Re-read post #1.

Doesn't the second part already have the third option? I have read it sooo many times

socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE

sed -i "s~socket options.*~socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE~
g" "$CONFIG"

What is it supposed to be with the third option?

 

[sfx2000]

Be careful - the SAMBA defaults are conservative to protect data...

That being said... if one wants to walk on the wild-side... this gets the best bang in our testing with Win7/8/10 and MacOS...

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536​

 

[ColinTaylor]

Doesn't the second part already have the third option? I have read it sooo many times

I think you're missing the most important part:

For anyone wishing to replicate this, create the file "/jffs/scripts/smb.postconf" with the following content (and change the second part of the sed command to your desired config).

#!/bin/sh
CONFIG="$1"
sed -i "s~socket options.*~socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE~g" "$CONFIG"

After creating the file, chmod it and restart the nasapps service;

chmod +x /jffs/scripts/smb.postconf

service restart_nasapps

 

[Lotta Cox]

I think you're missing the most important part:

Gotcha thanks!

 

[Lotta Cox]

I used WinSCP to make the file, edit, and chmod it.
With option 3, I transferred a movie file. Speed went from 235mb/s to 500mb/s. Nice!

 

[RMerlin]

Also note that I noticed very different test results with Samba when testing with Ethernet vs Wifi. Some optimizations were great for one but seriously reduced performance for the other.

 

[Lotta Cox]

Also note that I noticed very different test results with Samba when testing with Ethernet vs Wifi. Some optimizations were great for one but seriously reduced performance for the other.

My ethernet speeds are good with option 3 too. I will keep an eye on it.

 

[LostFreq]

Not setting the SO_RCVBUF and SO_SNDBUF socket options may be a good idea because on Linux there is TCP buffer auto-tuning which only works if you don't set socket buffer sizes, so it is more effective not to set SO_RCVBUF and SO_SNDBUF with TCP connections. This should allow Linux to find the optimal buffer size for the actual latency on the socket.

OpenVPN also used to set the buffer sizes to 64 KB by default in the past, but from version 2.3.9 it relies on the operating system defaults instead. You can read some of the discussion here: https://community.openvpn.net/openvpn/ticket/461

On my RT-AC86U I see these auto-tuning TCP buffer limits (min, default, and maximum number of bytes to use):

# grep . /proc/sys/net/ipv4/tcp_?mem
/proc/sys/net/ipv4/tcp_rmem:4096    87380   3521536
/proc/sys/net/ipv4/tcp_wmem:4096    16384   3521536

and these are limited by the maximum buffer sizes (384.3):

# grep . /proc/sys/net/core/?mem_max
/proc/sys/net/core/rmem_max:278528
/proc/sys/net/core/wmem_max:278528

Asus increased these values for HND in release/src/router/rc/sysdeps/init-broadcom.c with 384_20379 (384.4 alpha):

# grep . /proc/sys/net/core/?mem_max
/proc/sys/net/core/rmem_max:524288
/proc/sys/net/core/wmem_max:524288

If you agree that the optimal TCP buffer size for a given network link is buffer size = RTT * bandwidth then a fixed 64KB buffer size would limit your throughput on a wireless link with some latency, for instance if the RTT would be 2 ms then:
64KB = 0.002 * 31.25 MB/s

If you remove the SO_RCVBUF and SO_SNDBUF socket options from the Samba config, you could instead increase the default initial size of the send buffer used by TCP sockets to the value currently used for SO_SNDBUF in the Samba config, that would give you the best of both worlds (maybe do this in the same place in init-broadcom.c):

echo 4096 65636 3521536 > /proc/sys/net/ipv4/tcp_wmem

 

[TheBestPessimist]

RT-AC87U 380.68_4

Speeds better both on wireless and on wired with "socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE" (basically w/o "SO_RCVBUF=65536 SO_SNDBUF=65536").

As a delta between the speeds (as reported by windows 10 copy window): i seem to get about 10MBPS more than before, but i have not actually timed the copy.

 

[LostFreq]

Admittedly I can't say I've looked into this area too much, a quick search of the forum showed previous threads with similar recommendations about increasing the buffer size, but nothing mentioning removing the specified buffer all together which so far has given me the best performance. I'm also unsure of what SMB defaults this to when its not specified which is giving the above results or any potential downsides.

On the AC86U I assume that would default to:
an initial receive buffer size of 87380, auto-tuned by the kernel up to 278528 (or 524288 for 384.4)
an initial send buffer size of 16384, auto-tuned by the kernel up to 278528 (or 524288 for 384.4)

If anyone would like to chip in their findings in further improvements I'm all ears

To get the 384.4 tweaked maximum values that I mentioned above on 384.3 you could enter these commands:

echo 524288 > /proc/sys/net/core/rmem_max
echo 524288 > /proc/sys/net/core/wmem_max

And you could increase the default initial size of the send buffer used by TCP sockets with this command:

echo 4096 65636 3521536 > /proc/sys/net/ipv4/tcp_wmem

Note that you have to restart Samba after these commands and that the changed values will be reset by a reboot.

As RMerlin pointed out, testers should compare results for both a wired and a wireless connection (as these have different bandwidth and latency). And it would also be interesting to test both read speeds and write speeds.

 

[Adamm]

To get the 384.4 tweaks to the maximum values that I mentioned above on 384.3 you could enter these commands:

echo 524288 > /proc/sys/net/core/rmem_max:524288
echo 524288 > /proc/sys/net/core/wmem_max:524288

And you could increase the default initial size of the send buffer used by TCP sockets with this command:

echo 4096 65636 3521536 > /proc/sys/net/ipv4/tcp_wmem

These values are already present at-least when no buffers are specified.

As RMerlin pointed out, testers should compare results for both a wired and a wireless connection (as these have different bandwidth and latency). And it would also be interesting to test both read speeds and write speeds.

Unfortunately I can't easily test wired speeds due to my setup (I could but its a hassle). Not only that but I assume my mechanical HDD would be the bottleneck, someone with an external SSD would be preferable. I did update the OP with read speeds though for reference.

 

[LostFreq]

These values are already present at-least when no buffers are specified

Which firmware version are you using? Can you give the output of

cat /proc/sys/net/ipv4/tcp_wmem