Cisco/Linksys E4200 overclocked to 532 MHz

DD-WRT Speed Tweaks: Do they Really Work? 20

For the past few years, I’ve maintained an article on this blog offers my recommendation for the best DD-WRT build and settings to get max speed from a Linksys E4200 router.

One of my recommendations in that article is to use the Administration: Commands tab in the DD-WRT GUI interface to create a start-up script that passes some more advanced tweaks to the router — ones that can’t be controlled through the standard checkboxes, radio buttons, and text fields. I’ve gathered these tweaks from other expert users over time… but DD-WRT tweaking seems to be almost as much art as science, and because I agreed with the fundamental theories behind those settings, I didn’t bother testing them rigorously.

Here is the start-up script I’m currently using on my E4200 router:

sleep 10
wl -i eth1 interference 3
sleep 10
wl -i eth2 interference 3
ifconfig eth0 txqueuelen 2
ifconfig eth1 txqueuelen 2
ifconfig eth2 txqueuelen 2
echo 262144 > /proc/sys/net/core/rmem_max
echo 262144 > /proc/sys/net/core/wmem_max
echo "4096 16384 262144" > /proc/sys/net/ipv4/tcp_wmem
echo "4096 87380 262144" > /proc/sys/net/ipv4/tcp_rmem
echo 1000 > /proc/sys/net/core/netdev_max_backlog
echo 16384 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
echo 16384 > /sys/module/nf_conntrack/parameters/hashsize

Today, however, as I was tinkering with one of my routers, I started to wonder just how effective were those “advanced” settings, and so I decided to do a few tests.

I chose a time of day (on a Saturday morning) when all off the teenagers in the house were either out of the house or asleep, to ensure that no video or audio streaming on the network would mess with my results. I also decided to use my desktop computer, which is hard-wired to the router. This meant that no wireless interference or other WiFi router settings would affect the results, and that this would be a more focused test of the settings’ effect on the router’s wired network speed.

After each tweak, I ran two back-to-back speed tests, one immediately following the other. I’m on a Comcast residental connection, so I used the same Comcast test server (in Seattle) for each test. I got a consistent 12ms ping time for each test.

Checking the Default Settings

Before starting my first test, I deleted my start-up script and rebooted the router. That left me with nothing but the speed tweaks available in the GUI as I recommend them in my article, as well as the default settings for those advanced settings from my start-up script (my router is also overclocked). I ssh’d to the router and checked the default values of those settings:

# cat /proc/sys/net/core/rmem_max

# cat /proc/sys/net/core/wmem_max

# cat /proc/sys/net/ipv4/tcp_wmem
4096 16384 65536

# cat /proc/sys/net/ipv4/tcp_rmem
4096 87380 87380

# cat /proc/sys/net/core/netdev_max_backlog

# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max

cat /sys/module/nf_conntrack/parameters/hashsize

 Test #1: No Start-Up Script

With the default advanced settings and only the GUI-available speed tweaks, my first test results were:

GUI Only Tweaks - Speed Test 1
GUI Only Tweaks - Speed Test 2

Test #2: First Batch of Tweaks

The first time I published my tweaks, they included only four non-wireless advanced settings. I decided to change those settings first and re-test. I issued these commands to the router:

# echo 262144 > /proc/sys/net/core/rmem_max
# echo 262144 > /proc/sys/net/core/wmem_max
# echo "4096 16384 262144" > /proc/sys/net/ipv4/tcp_wmem
# echo "4096 87380 262144" > /proc/sys/net/ipv4/tcp_rmem

And got the following speed test results:

First Batch of Tweaks -  Test 1
First Batch of Tweaks -  Test 1

Interesting. No significant difference in speed.

Test #3: Second Batch of Tweaks

More recently, I had added a few more recommended tweaks to my article, so I decided to add them next:

echo 1000 > /proc/sys/net/core/netdev_max_backlog
echo 16384 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
echo 16384 > /sys/module/nf_conntrack/parameters/hashsize

I ran my speed tests again:

Second Batch of Tweaks -  Test 1
Second Batch of Tweaks -  Test 2

Again — no significant difference in speed. Hmm…

Test #4: Buffer Bloat Tweaks

After reading some posts on dealing with buffer bloat on DD-WRT, I’d been tinkering with some of those recommended settings. I added one more tweak for the wired connection:

# ifconfig eth0 txqueuelen 2

Here are the speed test results:

Buffer Bloat Tweaks -  Test 1
Buffer Bloat Tweaks -  Test 2

Once again, Again — no significant difference in speed.


I pasted in my full start-up script (including the WiFi interference tweaks) once again and rebooted the router. I ended up running the final test three times because the second result was higher than the previous tests:

Full Script -  Test 1
Full Script -  Test 2
Full Script -  Test 3

Again, same as before… that second result most likely being a temporary burst due to slightly less usage on my neighborhood’s node.


So what can we conclude from this test? It might be too early to tell for sure, but any of the following is possible:

  • The suggested tweaks do nothing. I hope this isn’t the case, but we have to accept it as a possibility.
  • My current connection isn’t fast enough to take advantage of the tweaks. I’m leaning toward this one, actually. My residental network speeds are usually double what I got today, so maybe Comcast is having network issues (shocker!), or it’s even possible that these tweaks don’t really start flexing their muscles until you get to the 50Mb/s+ level.
  • My PC could be contributing to the results. This is also very possible, so I plan on repeating these tests from my laptop, using a wired connection. I can dual boot the laptop into Windows and Fedora, so I’ll run the tests again in both operating systems to see if that’s contributing, too.

Regardless, I was surprised (and a bit disappointed) at the results. For now, it seems that the settings aren’t doing any harm to my speeds, so I’ll remain optimistic and leave them in place until I get a chance to do more testing. I’ll update this article with my future findings.

Do you use speed tweaks on your DD-WRT router? Have they been effective for you?

Please share your thoughts, questions, comments, and feedback below!

  • ramosel

    Steve, I am pleased by your testing but not surprised by the results. I had done some of the same in past weeks. Nice work. Did you leave any configuration in place long enough to see if all, some or none of the tweaks helped improve the transmit errors that have been so prevalent in these latest Betas? I did each test for 24hrs but saw no appreciable differences in TX errors.

    • Hi, ramosel. Thanks. No, I didn’t leave the settings in place very long, as I wanted to try and do all my tests as close to each other as possible to eliminate other network factors outside of my control. If I re-ran the tests tonight, they might be wildly different than this morning, based on neighborhood usage. Please keep me informed if you do further testing, and I’ll do the same here (and on the DD-WRT Forums).

  • Jerry Pasker

    You probably weren’t testing your settings. You were more than likely testing the speed test servers and random internet congestion. I know you tested when things were idle, but the internet is never idle. And the speed test server is never idle either. Most of the test was on networks where you had no control. When I owned and operated a fixed broadband wireless ISP for 10 years, people would go out and try to re-align their own equipment using various speed tests, and would always end up up pointing miles off center from a tower, before calling us, upset. Their aiming pattern more or less followed a random walk. Their tests were just random from the speed-test server load. And the equipment we used had a operational threshold of 3db. So it basically worked perfect or didn’t. But they didn’t know that, or understand that, and assumed signal quality and speed were directly related when they weren’t. Anyway, one day I took the time to educate one “computer networking expert” who had letters behind his name and let me know it!! He was quick to argue with me on how I aligned it, because *HIS* speed tests were very slightly higher! Since I always like to teach, I thought up a good teachable moment. So to prove my point I had him run 10 tests in a row with some random time between each test, without touching anything, and we saw results that varied by 20%. He decided that speed tests were worthless for dish alignment, all on his own without me having to say “I told you so.”

    Anyway, since you are/were “tweaking” settings and looking to gain super-tiny results, the only way you can know for sure is to set aside a local linux box, with basic DNS to fake the DNS you need for the speed test stuff, and with a local speed test server app on it, set up to basically emulate your ISP, and take internet noise out of the mix. Yes, a test lab.

    • Hi, Jerry. Thanks — great feedback. You’re right, of course, that the Internet is never idle, and the only way to have a “pure” test for anything is to create a “pure” environment. But if these tweaks can’t yield noticeable results even with some quick and dirty real-world testing, then their potential benefits are so minor that it’s probably not even worth the bother. Sigh. 🙂

      • Jerry

        What you did successfully test was that in “real world testing” the tweaks have no measurable effect. And that’s a conclusive test! It’s like adjusting the suspension, air-fuel mixture and gear ratios in a car and then seeing if your commute time improves. Your adjustments may help or hurt, but not in a way that gives a noticeable end result, unless you’re on a race track. I bet if you built a test server rig, (the internet equivalent of your own private test track) you’d see results from the tweaks.

        • I bet you’re right. 🙂

          • ReD-BaRoN

            Have you investigated what each setting actually does, and whether they are more applicable to single flows vs multiple flows? ip connection tacking, for example, isn’t going to help with single speed test flows.

  • Alligosh

    Actually, none of those settings will effect a single stream, and most of them are how the IP stack will handle things when you get tons of simultaneous connections. I have seen some of those to amazing things on busy servers, but I doubt you will see much difference with less than a few dozen active connections (possibly not until you have a few hundred).

    • Hey other Steve. 🙂 I agree. I’m now convinced these won’t do much for residential applications, and while they won’t do any damage, they’re pretty much wishful thinking. 🙂

  • ramosel

    Steve, I broke the script up into the same 3 parts and put a different piece on each of my e4200s (one got the full load). I gave them a few days to soak and saw no appreciable improvement or difference in TX errors. For kicks, I back revved two of them to Kong 22000 last night and they have been running with zero and 2 TX errors since. So there is something in these betas that just isn’t right. I’m beginning to wonder if the values in the script are even being applied? Since the older Kong build will let me run wl0.1 with security, I may just back rev the others and leave the betas until Seb and the gang get a bit more stability with the beta releases. I may repeat this testing with Kong22000.

    • Would love to hear what you find out!

      • GaryD

        Hi Steve, I’m stumped with recent speed issues related to using a VPN through “Private Internet Access (PIA).” They have very strong support and have responded on a timely manner to my tickets but we are all stumped on how to fix this. We’ve tested everything we can on their end and the client. I have an E4200v1 with KingKong Build 22000M which has been rock solid for 2 years so I don’t want to change it. Everything is static. I get well over 100MB speeds without the PIA on at the PC. It drops to 8MB with PIA on and this has been consistent for several weeks. We have done all speed tests to the same PIA server. All tests were done with WinMTR. At one time, I may have modified something in the router that now causes the speed reduction. Can you let me know if DD-WRT should have certain settings that would impact PPTP or any other protocol? I did turn off UPnP which I thought may have caused the issue. I recently turned it back on with no gains. Comcast and PIA are stumped as to the sudden drop in speed only when PIA is on and it doesnt matter what system I use. I’ve tested 3 laptops, one Linux Media Center device, oen iPAd and they all have the same consistent speed issues.

        Thanks much – Gary

  • All your tweaks are doing nothing of value, and could be doing harm.

    1) Speedtest is a lousy test. It does not run long enough, it has been extensively gamed, and worse, it does not test up + down + ping at the same time, but each separately. Do a speedtest – over ethernet, not wifi – and do your own ping or mtr in another window while running it. You will see, as on a typical cablemodem – buffering skyrocket to 600ms or more in both directions on the test.

    That is bufferbloat, and is fixable using the dd-wrt QoS system, not via txqueuelen.

    2) In my part of the (openwrt) universe we have the sqm-scripts that use fq_codel, which for example, we can demonstrate results against cablemodems here, using the netperf-wrapper “rrul” series of tests.

  • Rick Moseley

    Steve, I did back rev 2 of my 4 E4200s to Kong 22000 and was able to see reduced errors and was able to apply security to my guest (wl0.1) and have it work fine. Since I don’t see much (almost no) wireless congestion in my home I didn’t see that the settings in question made any difference for me. Finally after a month of no updates, Seb release a couple of betas last week and 26866 seems to be a good step in the right direction. 48hrs soak time, same hardware, same settings and no TX/RX errors. Likewise the Guest SSID works now with security enabled… woohoo!. so this afternoon I played just a bit with the script segments and really could not see any difference. Good news is they don’t seem to cause any slowing either. But again, I see little or no congestion on my network. I’m going to move ahead with putting 26866 on the rest of my APs

  • Pingback: My Cisco Linksys E4200 DD-WRT Settings for Max Speed()

  • djrobx

    I realize this is an old article but I wanted to share my results since my service is faster than my router.

    I have 300/20 mbps service through time warner. My Buffalo WZR-1750DHP can *almost* run at my service’s full speed of 350mbps. With the latest beta defaults I see about 300-310mbps speed typical on a test. I get about 350mbps direct with the modem. If I apply the “second batch of tweaks” I start to see 330-340mbps. So that improves my speed by about 30mbps; worthwhile for me.

    The second batch didn’t make any difference.

    If I apply the buffer bloat tweak, my download is not impacted, but my upload is reduced by a small amount (18mbps instead of 22-23). I suspect a slightly larger TX queue value would be better in my case.

    • Thanks for the update. Thought I’m a bit confused — you said the second batch improves your speed, but then the second batch didn’t make any difference?

      • djrobx

        Sorry, I fixed the post. I think my brain jumbled the “Test 2” and “1st batch”. TLDR: “Test #2, First Batch” improves my speed by 30mbps. Test #3, Second Batch, makes no difference for me.