AC86U SMB Tweaking

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

Adamm

Part of the Furniture
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
Code:
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
Code:
socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE SO_RCVBUF=131072 SO_SNDBUF=131072
3) No buffers specified | Write = 50MB/s - Read = 80MB/s
Code:
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).

Code:
#!/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;

Code:
chmod +x /jffs/scripts/smb.postconf

service restart_nasapps
 
Last edited:

skeal

Part of the Furniture
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
Code:
socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE SO_RCVBUF=65536 SO_SNDBUF=65536
2) Doubled Send/Receive buffers = 30MB/s
Code:
socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE SO_RCVBUF=131072 SO_SNDBUF=131072
3) No buffers specified = 50MB/s
Code:
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).

Code:
#!/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;

Code:
chmod +x /jffs/scripts/smb.postconf

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

RussellInCincinnati

Senior Member
...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

Part of the Furniture
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

Occasional Visitor
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

Senior Member
Am I doing something wrong?
[email protected]:/tmp/home/root# sed -i "s~socket options.*~socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE~
g" "$CONFIG"
sed: : No such file or directory
[email protected]:/tmp/home/root#
 

Lotta Cox

Senior Member
Yes. Re-read post #1.
Doesn't the second part already have the third option? I have read it sooo many times o_O

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

Part of the Furniture
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

Part of the Furniture
Doesn't the second part already have the third option? I have read it sooo many times o_O
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).

Code:
#!/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;

Code:
chmod +x /jffs/scripts/smb.postconf

service restart_nasapps
 

Lotta Cox

Senior Member

Lotta Cox

Senior Member
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!
 
Last edited:

RMerlin

Asuswrt-Merlin dev
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

Senior Member
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

Regular Contributor
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):

Code:
# 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):
Code:
# 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):
Code:
# 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):
Code:
echo 4096 65636 3521536 > /proc/sys/net/ipv4/tcp_wmem
 
Last edited:

TheBestPessimist

Occasional Visitor
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

Regular Contributor
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:
Code:
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:
Code:
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.
 
Last edited:

Adamm

Part of the Furniture
To get the 384.4 tweaks to the maximum values that I mentioned above on 384.3 you could enter these commands:
Code:
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:
Code:
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.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top