Posted: Sat May 30, 2009 9:44 Post subject: Traffic management
I'm running v24 12060 (dd-wrt.v24-12060_NEWD_openvpn.bin) on a Linksys WRT 300n v1.0.
My ISP (NTL-Virgin cable) sets upload and download limits - data caps - at various times of day; if these are exceeded they reduce your bandwidth for a period.
I'd like to apply a data cap at the router - which could be run from an always-on linux box - is there any way of doing this?
Posted: Tue Jun 02, 2009 22:27 Post subject: Traffic Management - wshaper not working?
Thanks, that's a very good suggestion.
I'm testing it now by running the commands:
/usr/sbin/nvram set wshaper_uplink=177
/usr/sbin/nvram set wshaper_downlink=333
stopservice wshaper
startservice wshaper
When I check it by Telnetting into the router:
/usr/sbin/nvram get wshaper_uplink
/usr/sbin/nvram get wshaper_downlink
it returns the values I've set.
However looking at the Bandwidth Monitoring page, I can see no change in throughput. I even tried setting the up and down speeds to zero, with no evident change.
I also ran speedtest.net and found both up and down speeds unaffected by the wshaper settings.
So wshaper appears to be running with the correct settings, but not working.
I've looked for information about wshaper and the dd-wrt version, but it's scarce. Does anyone have any ideas why wshaper doesn't appear to be working?
Thanks. QoS is enabled to limit P2P activity, which is also why I need to control data volumes at certain times.
I can see my wshaper settings changing in the Uplink and Downlink fields on the NAT/QoS - QoS page, after I run the wshaper commands.
After playing around with it I found that wshaper settings are only applied when DHCP is restarted (DHCP Release and DHCP Renew from Status - WAN page).
Does anyone find different?
If the wshaper speed is set too high for the physical connection then DHCP won't connect - which has been an intermittent problem for some users, me included so hopefully this will help someone.
When wshaper is used it doesn't appear to negotiate the connection speed for DHCP so if the WAN is disconnected and the physical connection is running slower than wshaper's settings, DHCP will fail to reconnect.
Is there a way to disable wshaper's limits so it will connect and run at the actual maximum speed? Or can wshaper negotiate the connection speed?
I guess I need to include commands to restart DHCP when wshaper settings change - first time!
I'd also like to check total data throughput against the limit, but I'm not sure how to access the counter. I assume there's one as the Status-WAN page displays daily totals.
Hopefully all this will be useful to others who've logged similar questions!
I have read many complaints about QoS on this forum but I have never heard of the DHCP connection that you claim. I suspect that the problem is something else.
You might try doing these steps manually from the SSH command line. In particular does wshaper stop? (use the ps command to see). Unless it stops and restarts it will not read up the new values.
Now if the link is overloaded then it is possible that some packets (including DHCP) are being dropped. This can happen which could effect your DHCP negotiation I suspect. But this is kind of a separate issue. Can you post a screen shot of your QoS page? Is QoS on WAN or WAN&LAN? I hear WAN only works best.
I used Telnet to set the wshaper up- and download speeds:
root@DD-WRT:~# /usr/sbin/nvram set wshaper_uplink 200
root@DD-WRT:~# /usr/sbin/nvram set wshaper_downlink 2000
root@DD-WRT:~# /sbin/stopservice wshaper
root@DD-WRT:~# /sbin/startservice wshaper
PS doesn't show wshaper before or after restarting it.
Sometimes get wshaper_uplink or get wshaper_downlink doesn't return any value, and the only way I've found to resolve it is to disable QoS from the GUI and re-enable it.
Testing with Speedtest.net shows that after changing the speeds from the terminal the download speed is reduced, but the upload speed is not affected.
I couldn't get wshaper to reduce upload speed.
DHCP is still giving connection problems if the speed is set too high and QoS is on.
I see you are using HSFC traffic control method. I have read on this forum that this method only uses one of the speed parameters. I think it is the download number which is used. The other number has no effect at all. That may be confusing you.
I have also heard other people say that QoS is broken in releases between about January and now but this is unconfirmed as far as I am concerned.
I will tell you that mostly these QoS options effect upload packets so you should definitely be seeing the results there. There is more limited ability to control the download QoS. I don't think HSFC does much in this regard but I am not sure.
What about HTB? Did you try that method with the same result?
I read the HSFC was best for things like VOIP. I'd hope it doesn't work on just download. It's my upstream I need the QoS to be effective on.
Scott
From everything I've read you should be using HTB, as it controls traffic specifically by throttling upstream flow. The Help text within DD-WRT also mentions this.
I'm using a very basic QoS implementation here -- just giving priority for a specific MAC address -- and I can tell you that with HTB it's working as it should. I've tested this by running parallel video streams and internet speed tests, etc. on my LAN clients and no matter what I do, the dedicated MAC always comes out with far lower latency and nearly twice the data rate.
But it looks like OP is using L7 to try and identify particular traffic types. I don't know how well the filters he's chosen actually work in that regard. In my case, I'm running Cisco VPN on the MAC with priority. But from what I read about that L7 filter it wasn't working right, so I decided to just give my VPN MAC priority over all others on my LAN, and this suits my purposes fine (probably won't work for what either of you are doing though).
One note jrussell88 if you are using VoIP you should add "rtp" to your list. The SIP protocol is used only to initiate the call. After that the actual voice traffic is carried by RTP packets. See http://en.wikipedia.org/wiki/Real-time_Transport_Protocol if you want to learn more.
On the other hand SNR is suggesting to use the IP or MAC address to classify your traffic rather than the L7 type classification you are using. Might be a good area for experimentation.
SNR, what release of DD-WRT are you using? There are those that claim that QoS in releases after 1/29/09 does not function.
SNR, what release of DD-WRT are you using? There are those that claim that QoS in releases after 1/29/09 does not function.
Up until a few minutes ago I was using 12255. I'm now using 12262 (settings restore via a modified version of frater's script).
I actually tested my QoS setup with 12220 I think. Haven't done formal testing with the newer builds, but when I was still using 12255 last night and my kids were all online I still had no problem working over VPN on the device with the prioritized MAC.
For these purposes QoS totally rocks. No more complaining to the kids to ask them to stop watching YouTube. They can watch all they want now 'cause Daddy's in charge, LOL...
I've read several of those other threads that you mention complaining about QoS not working in v24. But most of them involve user-generated scripts that just seemed too much trouble for me to bother with. I always try to keep things as simple as possible, and in my case giving priority to an entire MAC instead of trying to narrow it down to just VPN traffic works just fine for me.
FYI, apparently in v24 the TCP-Vegas congestion algorithm was silently slipped into the build. And from what some of the senior members have been saying here, this alone apparently works good enough for VoIP priority, assuming you have a large enough pipe to begin with. In my case I don't have anywhere near the 8+ Mbit connections that these guys have. But based on what they say, you can supposedly configure QoS on top of TCP-Vegas with no problems, so that's what I went ahead and did.