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.
I should add that I don't use any scripts or explicit nvram settings. I just Enabled QoS in the GUI, entered my Uplink and Downlink speeds, and added a MAC Priority entry for the device that I use for VPN access to my workplace. I set that priority to Express and left everything else at the default priority as shown in the GUI.
For link speeds, I have a connection rated at 1.5Mbps/384Kbps, but Internet speed tests show an effective rate of 1232/320. Most of what I've read says to use "85-90% of your rated speed" to allow headroom for QoS, but that doesn't make sense to me, as you can never get your rated speed anyway (quite apart from QoS). So for starters I just entered my effective (tested) rate in the GUI -- although that still doesn't seem to leave any room for rate manipulation by QoS. But it seems to work fine anyway. Go figure...
Hierarchical Fair Service Curve (HFSC) is based on a QoS and a CBQ algorithm which is used mostly on Unix operating systems. It is the first QoS algorithm to simultaneously support all three of real-time, adaptive best-effort, and link-sharing services.
This is a faster replacement for the Class Based Queueing qdisc (queuing discipline) in Linux.
HTBs help in controlling the use of the outbound bandwidth on a given link. HTB allows using one single physical link to simulate multiple slower links and to send different kinds of traffic on different simulated links. In both cases, one has to specify how to divide the physical link into simulated links and how to decide which simulated link a given packet is to be sent across.
In other words, HTB is very useful to limit a client's download/upload rate. Thus, the limited client cannot saturate the total bandwidth.
Note that this description of HTB was apparently copied verbatim into DD-WRT Help!
QoS works fine for me, but I want to control data throughput at certain times, not speed.
So you want to cap a particular MAC or IP address to a specific rate, but only during certain times of the day?
I see this in the iptables manpage here, so it looks like this can at least be done in theory:
Code:
time
This matches if the packet arrival time/date is within a given range. All options are facultative.
--timestart value
Match only if it is after 'value' (Inclusive, format: HH:MM ; default 00:00).
--timestop value
Match only if it is before 'value' (Inclusive, format: HH:MM ; default 23:59).
--days listofdays
Match only if today is one of the given days. (format: Mon,Tue,Wed,Thu,Fri,Sat,Sun ; default everyday)
--datestart date
Match only if it is after 'date' (Inclusive, format: YYYY[:MM[:DD[:hh[:mm[:ss]]]]] ; h,m,s start from 0 ; default to 1970)
--datestop date
Match only if it is before 'date' (Inclusive, format: YYYY[:MM[:DD[:hh[:mm[:ss]]]]] ; h,m,s start from 0 ; default to 2037)
–adjective
1. conferring a faculty, privilege, permission, or the power of doing or not doing something: a facultative enactment.
2. left to one's option or choice; optional: The last questions in the examination were facultative.
3. that may or may not take place; that may or may not assume a specified character.
4. Biology. having the capacity to live under more than one specific set of environmental conditions, as a plant that can lead either a parasitic or a nonparasitic life or a bacterium that can live with or without air (opposed to obligate ).
5. of or pertaining to the faculties.
I guess this is easier than saying, "All options are optional." LOL...
I ran the "Robson WRT54 Script Generator" that I linked to in page one of this thread and stuck in some dummy params that I thought might apply to your situation bandwidth-wise. The resulting code does a lot more than just add a few rules via iptables. Trying to figure out how to manually add a time-based rule to this code is beyond my ability.
I'm sure the developer could figure it out though. Maybe you could even talk him into adding time parameters to this tool. His email address is in the About menu of the program. Here's that download link again (this seems to be the "authoritative" location):
It looks like:
# System-1 Downloads
iptables -A FORWARD -d 192.168.100.1
# System-1 Uploads
iptables -A FORWARD -s 192.168.100.1
should set download and upload counters for 192.168.100.1 which is the cable modem.
The command: sudo iptables -L -v -n should list the counters for all chains.
If I can access the counters in my code I can adjust the bandwidth accordingly.
It looks like:
# System-1 Downloads
iptables -A FORWARD -d 192.168.100.1
# System-1 Uploads
iptables -A FORWARD -s 192.168.100.1
should set download and upload counters for 192.168.100.1 which is the cable modem.
The command: sudo iptables -L -v -n should list the counters for all chains.
If I can access the counters in my code I can adjust the bandwidth accordingly.
Hmm... I think you will need to follow the entire example on that link, i.e. you must create a new chain first, and then jump to that chain:
Note that I left the sudo command off the added code...are you really gonna do this on "another" Linux box when you already have a Linux router with DD-WRT?
Anyway, once you setup this bandwidth monitoring, how frequently are you gonna check it? And what are you gonna do to actually throttle bandwidth when the time comes to do that? And what happens if your sampling rate is not high enough and "the cows get out of the barn" so-to-speak?
(Edited to replace my misuse of "table" with "chain".)
I think I finally understand now that you are trying to cap certain clients based on total bytes transferred (either up or down or both) -- not a rate cap based on bytes/second. In that case, it should be relatively easy to work this out entirely within iptables on your router. Still not sure what exactly you plan to do when a client is approaching (or has already exceeded) that cap.
Just want to warn you all that HFSC is broken and BS isn't being cooperative. There are some other problems with all QoS like traffic hitting the imq0 device twice and lan traffic hitting imq0 even when QoS is set to WAN, but if I can't even get something fixed by providing the code myself then why bother with the rest.
The script generator has at least one minor problem with the interfaces it uses but it's far better than the built in QoS.
Also note that the iptables time match is not included in recent builds (cat /proc/net/ip_tables_matches) and even if you get a build that has it (maybe jbarbieri's rip from v23) then you'd probably still want to use cron jobs to change the tc classes. _________________ Read the forum announcements thoroughly! Be cautious if you're inexperienced.
Available for paid consulting. (Don't PM about complicated setups otherwise)
Looking for bricks and spare routers to expand my collection. (not interested in G spec models)
Also note that the iptables time match is not included in recent builds (cat /proc/net/ip_tables_matches) and even if you get a build that has it (maybe jbarbieri's rip from v23) then you'd probably still want to use cron jobs to change the tc classes.
That's good to know... should make life more interesting for the OP.
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.
I just went through this myself. Based on my experience with the QoS settings, QoS is broken in both v24 sp1 and v24 sp2. It actually appears to be worse in v24 sp2. I am using the http://www.whichvoip.com/voip/speed_test/ppspeed.html to test the results of my QoS settings, and doing real tests with my VOIP device while loading my Internet connection. Even when I enable a single IP based rule under QoS I experience high packet loss and terrible jitter. Something isn't right. I have a theory the buffers are too small. I read in a technical article that buffer sizes should be twice the latency. Which means if your latency is 50ms, you need a 100ms buffer. In my situation the buffer is roughly 10ms, but my latency is ~43ms. I wonder if the buffers are starving and the CPU is working overtime to keep up with too small of buffers and it even misses sometimes. Even when I'm using only 40kbps of upstream traffic my DD-WRT router's CPU will go to 100%.
I have verified the same QoS settings using another open source firmware package and my test results are perfect. So it is definitely related to DD-WRT's implementation of QoS.
Even when I enable a single IP based rule under QoS I experience high packet loss and terrible jitter. Something isn't right.
I looked at the tool you cited. Looks interesting but please be a little more quantitative about what you think is high packet loss and terrible jitter? What are the numbers that impact VoIP quality? I cannot see how 43ms latency or 100% CPU utilization is audible.
Even when I enable a single IP based rule under QoS I experience high packet loss and terrible jitter. Something isn't right.
I looked at the tool you cited. Looks interesting but please be a little more quantitative about what you think is high packet loss and terrible jitter? What are the numbers that impact VoIP quality? I cannot see how 43ms latency or 100% CPU utilization is audible.
On that little test I had two yellows and one red. The details showed very high packet loss and my jitter went fro 0.2ms to the mid 50s with DD-WRT QoS enabled.
I may reinstall DD-WRT and run a few test, snag the data and post it. Right now I switched to another open source firmware because for the time being I need QoS to work. This other software is producing perfect results on that test. DD-WRT is fully featured so I hope to return to it once the QoS issues are resolved.
