# QoS script for the OpenWRT firmware

## SteveX

Hello,

I found this script for the OpenWRT firmware and wanted to modify it for my Gentoo server.  From what it looks like and what I have read it seems to be good but I do not know anything on this subject other than what has been posted on this forum.  I do have a myshaper script with a VoIP addition for my Vonage / Cisco ATA.  I was hoping that people who were more familiar with QoS could comment on the quality of the OpenWRT QoS script:

Forum link:

http://forum.openwrt.org/viewtopic.php?id=4112&p=14

Sources:

http://files.eschauzier.org/20-qos-htb

http://files.eschauzier.org/20-qos-hfsc

http://files.eschauzier.org/qos.conf

Thanks,

Steve

----------

## frostschutz

I can only comment on the HTB part, as I have no experience with HFSC. If you have a complete understanding of HFSC, you may be able to get better results with it than with HTB; however, there is no documentation for the HFSC scheduler anywhere (except for a theory paper that's not easy for the end user to understand), which is the main reason for it not being very popular.

Anyway, about the HTB structure of this setup... it's not a bad script by all means, but it's nothing special either. It contains many elements that I would not recommend using (prio for HTB classes, SFQ queue for interactive classes), they can introduce lag which is unnecessary. They seem to have put a lot of thought into classification of traffic, though. That's something I've pretty much avoided so far, because I followed a different shaping approach (I'm mainly shaping on a per-user basis in the network, to achieve fair share of available bandwidth).

----------

## SteveX

Thanks for the reply.  Based on your comments it sounds like the script would not scale well.  If the script can introduce lag it sounds like the quality of the script would depend on the processor running the script along with how large the LAN is.  My home LAN which has no teenagers and heaviest network activity would be VoIP with the occassional download and upload of large files along with VPN it sounds like this script could suit me.  The quality of my VoIP with my current script can breakup up when I am uploading large files.

I'll just give them a whirl and see what happens.

Thanks again,

Steve

----------

## RE

 *frostschutz wrote:*   

> I can only comment on the HTB part, as I have no experience with HFSC. If you have a complete understanding of HFSC, you may be able to get better results with it than with HTB;

 

Interestingly, this seems to be a popular belief. I have not found any evidence or solid investigation proving this statement, however. In fact, the qos-re and qos-re-hfsc scripts are the first attempts that I know of to do a fair comparison of the two disciplines. So far, I have not experienced any difference in performance, nor have the other users that have experimented with the two packages.

Also see my response to a similar reaction in the OpenWRT forum: http://forum.openwrt.org/viewtopic.php?pid=27049#p27049

 *frostschutz wrote:*   

> however, there is no documentation for the HFSC scheduler anywhere (except for a theory paper that's not easy for the end user to understand), which is the main reason for it not being very popular.

 

It turns out that the paper makes hfsc probably the best documented queuing discipline available. Getting into the nitty gritties may require some extensive studying, though.

 *frostschutz wrote:*   

> It contains many elements that I would not recommend using (prio for HTB classes, SFQ queue for interactive classes), they can introduce lag which is unnecessary.

 

This doesn't make sense to me. The prio feature of htb is the main mechanism to decouple delay from bandwidth, and guarantuees VoIP packets are sent out with an absolute minimum of delay (See chapter 6 of the HTB user manual http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm). SFQ gives multiple connections in one class fair access to the outgoing line. It avoids one overactive connection to overwhelm the others in a class, thus limiting delay. Case in point is that early versions of the script used pfifo, and the sfq did give a (albeit barely) noticable improvement.Last edited by RE on Tue May 30, 2006 8:10 am; edited 1 time in total

----------

## RE

 *SteveX wrote:*   

> Based on your comments it sounds like the script would not scale well.

 

The script was specifically designed to scale with line speed. All parameters for the queuing disciplines are optimized based on the up and down link speeds, as well as the MTU. The result is solid performance over a wide range of conditions.

----------

## frostschutz

Okay. I didn't know about that particular behaviour of HTB; I thought that prio affected distribution of available bandwidth exclusively. I've read the docs several times and even worked with HTB for a long time, and still missed that. Thanks for pointing it out!  :Smile:  My guess right now is that the bad delay I experienced actually was caused from the class going overlimit.

----------

