Dear Community Members,

After struggling quite a while with the current qos-scripts (and luci-app-qos), I decided to modify the package and simplify it.

You can find the result here: https://github.com/zcecc22/qos-scripts-v2

Most of the changes have been carried out in the "tcrules.awk" file which is responsible for setting up the HSFC lines. The idea of the modification was to remove the obscure calculations present in it originally and leverage the parameters passed from the "qos" config file directly.

Now, all traffic classes defined in config file will yield a Realtime and Linkshare service curve. If desired, the service curve are passed a delay (the packetdelay in ms) which gives an m1 of 0 and d of X ms. m2 takes the avgrate parameter for the RT SC and priority for the LS SC.

Overall, this file gives more control as shown in my sample qos file.

I look forward your feedback, feel free to ask for support.

You can find the result here: https://github.com/zcecc22/qos-scripts-v2

This link dead

I released a new QOS script based on the previous one but tuned for better latency. Unfortunately, the new script breaks compatibility with qos-script.

You can find the new script here along the setup instructions:

https://github.com/zcecc22/qos-nxt

Interesting. I might test that at some point (although the regular qos-scripts seems to work ok for me).

I browsed through the scripts and have some feedback for you:
- using /etc/rc.local as the main component of the qos script sounds a bit strange. That file is meant to be a general purpose script for user commands and I guess that many users already have something there. Might be better to name this clearly like /usr/sbin/qos-nxt or something.
- currently two scripts need possibly to be edited before this can be used. And one of them is a subscript called by the main script. It might be better to concentrate all settings in the "main" script and pass the needed parameters to the called scripts. (You might also consider adapting this to use uci config for parameters. That might make it easier to use.)
- You might also consider combining the scripts to one larger script, maybe with clearly marked sections. That would make it more compact.

EDIT:
I made a test build with BB trunk for my WNDR3700v2 and your scripts worked ok. Roughly similarly as qos-scripts. Your scripts cut bulk upload maybe a bit more aggressively during very high loads, maybe improving browsing experience a bit. (I have 100/10 Mbit/s connection, so I used Ubuntu downloads by torrent to generate full load for testing, maybe about 80/9 Mbit/s.)

(Last edited by hnyman on 26 Jan 2014, 00:02)

Thanks for your scripts zcecc22.

I use them and I like them very much, I managed to browse again while torrenting!
I have one corner case and I think that is can be addressed...
When I download a torrent with many seeders, my downlink is saturated and I cannot watch on-line videos. Normal browsing works OK, but a little lagging.

Since I am not an tc/networking expert, I have some questions/ideas:

1) Why don't you split downlink into 2 classes (bulk/express)?
2) why limit the number of flows and not use the default value (1024)? (both uplink and downlink)
3) what's the point of 2 classes in ingress (one father/one child) and everything going to child? one class is not enough?

$TC class add dev $DEV parent 1: classid 1:1 htb $LQ rate ${CEIL}kbit ceil ${CEIL}kbit
$TC class add dev $DEV parent 1:1 classid 1:11 htb $LQ rate ${CEIL}kbit ceil ${CEIL}kbit prio 1 

a luci-app for configuration and monitoring would make this more accessible to many users.

any idea if it works properly under BB? I would guess yes.

(Last edited by drawz on 1 Sep 2014, 19:00)