Wondershaper QoS discussion

[Styno]

Wondershaper does work on WL-500g. At first glance I suspect the problem to be with the bandwith parameters you provide (1300 and 300).

Lets focus on the upload stream only because that one is the most import:
You basically tell Wondershaper that your connection can do 300 kbit/s continuously, but in theory your connection can only do 256 kbit/s and in real life this would be only 200 - 220 kbit/s. This means that the script is planning more data on you line than it can handle, rendering the script useless.

Therefore you will have to change the script parameters to -lets say-: 1000 kb/s down and 200 kb/s up. This does indeed mean that you somewhat reduce the maximum speed of the line but gain a better responsiveness.

You can change the 'bulk' stream to use all available bandwith when none of the higher priority streams aren't using it (there are examples on how to do this in this thread) to improve efficiency.

Bottom line is: Bandwith management is a tradeoff between raw throughput and smooth streaming.

[akbor]

Hi Styno and thank you for the answer!

I also tried to reduce the upload speed at the script-call (like this: /usr/local/sbin wshaper start eth1 1000 180) and I tried ...

You can see, I've already tried your recommendation. It didn't work, my voice on the phone becomes stuttering, when I do some upload (FTP, SMTP, ...) in parallel. Do you probably have one more idea?

Regards

Robert

EDIT: in the meantime I tested all three possibilities (starting the script with "1000 200" down/upload):

1) filtering by the TOS

# high priority for VoIP traffic
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
   match ip tos 0x68 0xff \
   match ip protocol 0x11 0xff \
   flowid 1:10

tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
   match ip tos 0xb8 0xff \
   match ip protocol 0x11 0xff \
   flowid 1:10

or alternatley 2) filtering by the port (5004, RTP)

# high priority for VoIP traffic
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
   match ip dport 5004 0xffff \
   match ip protocol 0x11 0xff \
   flowid 1:10

or alternatley 3) filtering by the IP

# high priority for VoIP traffic
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
   match ip src 192.168.38.2 flowid 1:10

it simply doesn't work - either 1) nor 2) nor 3). Is it time to buy an AVM FritzBox?

[Styno]

Ok, Sorry I missed the line where you said you tried low bitrates as well...I also credit you for trying different things yourself!

On topic now: What about the possibility that you try to filter the wrong protocol? Afaik there are several implementations of VoiP (I could be very wrong here).

You can check if you've defined your VoiP child class correctly by watching the packet count: "wshaper status eth1". If you can see that VoiP data is transferred using the VoiP child class and the bulk data is transported using a different class then it is only a matter of shaping the child classes correctly. But when you can see that the VoiP data is sent using the 'catch all/bulk' child class then you need to focus on the correct seperation of VoiP data.

I hope you know what I mean...

[akbor]

Hi Styno and thank you again

I seem to think (or to post) as fast as you - see my post above, the EDIT part from yesterday evening. I thougth, that maybe my hardware or my provider didn't implement the service correctly. So I tried to filter depending on type of service, port number, IP address. No way.

Today evening I'll try to use the status parameter of the wshaper and I'll post the results.

So long

Robert

EDIT: after a short VoIP call and an email Tx "wshaper status eth1" shows following:

[admin@(none) sbin]$ wshaper status eth1
qdisc htb 1: r2q 10 default 12 direct_packets_stat 2
statistics truncated
 qdisc ingress ffff:
statistics truncated
 class htb 1:1 root rate 800Mbit ceil 800Mbit burst 1050044b cburst 1050044b
 Sent 1169272 bytes 6044 pkts (dropped 0, overlimits 0)
 rate 6702bps 5pps
 lended: 0 borrowed: 0 giants: 0
 tokens: 8204 ctokens: 8204

class htb 1:10 parent 1:1 prio 0 rate 100Kbit ceil 100000Kbit burst 1728b cburst
 129587b
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 lended: 0 borrowed: 0 giants: 0
 tokens: 110592 ctokens: 8294

class htb 1:12 parent 1:1 prio 0 rate 100000Kbit ceil 100000Kbit burst 129587b c
burst 129587b
 Sent 1169272 bytes 6044 pkts (dropped 0, overlimits 0)
 rate 6715bps 6pps
 lended: 6044 borrowed: 0 giants: 0
 tokens: 8291 ctokens: 8291

but to be honest, I have a problem to interpret this result... please help

[martijnvr]

Hi Akbor,

I just looked through the post-firewall script you attached to your first post. If the second line in this script really reads like:

/usr/local/sbin wshaper start "$1" 1300 320

then you're definately not calling your own customized wshaper script. It should look like this:

/usr/local/sbin/wshaper start "$1" 1300 320

Furthermore, I find the values in the output of the wshaper status eth1 command a bit strange... 800Mbit? 100000Kbit? Are you sure you're calling the script with correct parameters?

Good luck!

[akbor]

Hello martijnvr!

You are right, it's a typing error, I must be blind... OK, this script call from post-firewall has newer worked. But.

I called the script also manually for testing it after changes with:

cd /usr/local/sbin

and then

wshaper start eth1 1000 250

Which script have I called? My modified copy from /usr/local/sbin/ or the other one, unmodified from /sbin/? I think the first one.

Values like "800Mbit? 100000Kbit?" are very suspicious for me too, but I don't know what do they mean exactley.

Regards

Robert

[Styno]

I called the script also manually for testing it after changes with:

cd /usr/local/sbin

and then

wshaper start eth1 1000 250

Which script have I called? My modified copy from /usr/local/sbin/ or the other one, unmodified from /sbin/? I think the first one.

If you want to run a script from the current directory then you need to put ./ in front of it. So to start the correct wshaper script, just type in /usr/local/sbin

./wshaper

or (maybe the best option to be sure)

/usr/local/sbin/whaper

Values like "800Mbit? 100000Kbit?" are very suspicious for me too, but I don't know what do they mean exactley.

Well 1 MBit is ~1000 x 1kBit and because most internet connections are roughly in the range of 256 Kbit to 10 Mbit, the numbers shown here seem a bit over the top. Which could also be a good reason for your shaping problems.

[akbor]

OK, I seem to be very close to the solution!

I really don't know if I had this stupid error (a space instead of a slash) in the "post-firewall" at the begin, but today I just have made "cat post-firewal" and I've seen the correct path.

In the meantime I found out that a script-call from the command line like

cd /usr/local/sbin
./wshaper start eth1 1300 230

provides good results with my last modification of wshaper (filtering according to IP address). But I think my wshaper-script doesn't start from "post-firewall" correctly. If I change the directory to "/usr/local/sbin" directly after reboot and make "./wshaper status eth1" then I get some strange output like that

[admin@(none) root]$ cd /usr/local/sbin/
[admin@(none) sbin]$ ./wshaper status eth1
qdisc htb 1: r2q 10 default 11 direct_packets_stat 3
statistics truncated
 qdisc ingress ffff:
statistics truncated
 class htb 1:11 parent 1:1 prio 0 rate 100000Kbit ceil 100000Kbit burst 129587b
cburst 129587b
 Sent 1949 bytes 31 pkts (dropped 0, overlimits 0)
 rate 45bps
 lended: 31 borrowed: 0 giants: 0
 tokens: 8291 ctokens: 8291

class htb 1:1 root rate 800Mbit ceil 800Mbit burst 1050044b cburst 1050044b
 Sent 1949 bytes 31 pkts (dropped 0, overlimits 0)
 rate 45bps
 lended: 0 borrowed: 0 giants: 0
 tokens: 8204 ctokens: 8204

If I make once call like "./wshaper start eth1 1300 230" I get a correct output like

[admin@(none) sbin]$ ./wshaper start eth1 1300 230
[admin@(none) sbin]$ ./wshaper status eth1
qdisc ingress ffff:
statistics truncated
 qdisc sfq 30: quantum 1514b perturb 10sec
statistics truncated
 qdisc sfq 20: quantum 1514b perturb 10sec
statistics truncated
 qdisc sfq 10: quantum 1514b perturb 10sec
statistics truncated
 qdisc htb 1: r2q 10 default 20 direct_packets_stat 0
statistics truncated
 class htb 1:1 root rate 230Kbit ceil 230Kbit burst 6Kb cburst 1893b
 Sent 108 bytes 2 pkts (dropped 0, overlimits 0)
 lended: 0 borrowed: 0 giants: 0
 tokens: 169404 ctokens: 51144

class htb 1:10 parent 1:1 leaf 10: prio 1 rate 230Kbit ceil 230Kbit burst 6Kb cb
urst 1893b
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 lended: 0 borrowed: 0 giants: 0
 tokens: 170962 ctokens: 52702

class htb 1:20 parent 1:1 leaf 20: prio 2 rate 207Kbit ceil 207Kbit burst 6Kb cb
urst 1863b
 Sent 108 bytes 2 pkts (dropped 0, overlimits 0)
 lended: 2 borrowed: 0 giants: 0
 tokens: 188229 ctokens: 55900

class htb 1:30 parent 1:1 leaf 30: prio 2 rate 184Kbit ceil 184Kbit burst 6Kb cb
urst 1834b
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 lended: 0 borrowed: 0 giants: 0
 tokens: 213703 ctokens: 63825

Do I do something wrong? My "post-firewall" is in /usr/local/sbin/post-firewal, it's executable and it contains following code

#!/bin/sh
/usr/local/sbin/wshaper start $1 1300 230

my modified wshaper is in the same directory and it's executable too. See image below.

I've also tried to put $1 in quotation-marks

#!/bin/sh
/usr/local/sbin/wshaper start "$1" 1300 230

with the same result..

Anybody some idea?

[Styno]

Perhaps you still have some invalid shaping settings in the webinterface? The output of the script which you started by hand looks good.

[akbor]

Yes, I have removed all the rules from "Bandwith Management" in the web interface, but I forgot to set the radio button to "No" (Enable Bandwidth Management? (No) ). So I did it and now the startup from post-firewal is working fine.

Result: a slightly modificated wshaper runs on my WL-500g. I still use my last modification - filtering according to the IP of my VoIP device. I think, if I'll have some free time I'll try to filter the VoIP data according to the port or to TOS again. But for the first time I have enough from Wondershaper

Styno, martijnvr I thank you a lot!

CU

Robert

[akbor]

Hello Guys that's me again...

I'll be blowed with the stupid thing. I think, wshaper starts now correctly from post-firewall but it still does not prioritize the traffic from my VoIP adapter

An example of the status information after reboot:

[admin@(none) sbin]$ ./wshaper status eth1
qdisc ingress ffff:
statistics truncated
 qdisc sfq 30: quantum 1514b perturb 10sec
statistics truncated
 qdisc sfq 20: quantum 1514b perturb 10sec
statistics truncated
 qdisc sfq 10: quantum 1514b perturb 10sec
statistics truncated
 qdisc htb 1: r2q 10 default 20 direct_packets_stat 0
statistics truncated
 class htb 1:1 root rate 230Kbit ceil 230Kbit burst 6Kb cburst 1893b
 Sent 15141 bytes 254 pkts (dropped 0, overlimits 0)
 rate 8bps
 lended: 0 borrowed: 0 giants: 0
 tokens: 169850 ctokens: 51590

class htb 1:10 parent 1:1 leaf 10: prio 1 rate 230Kbit ceil 230Kbit burst 6Kb cb
urst 1893b
 Sent 132 bytes 2 pkts (dropped 0, overlimits 0)
 lended: 2 borrowed: 0 giants: 0
 tokens: 169182 ctokens: 50922

class htb 1:20 parent 1:1 leaf 20: prio 2 rate 207Kbit ceil 207Kbit burst 6Kb cb
urst 1863b
 Sent 15009 bytes 252 pkts (dropped 0, overlimits 0)
 rate 8bps
 lended: 252 borrowed: 0 giants: 0
 tokens: 188723 ctokens: 56394

class htb 1:30 parent 1:1 leaf 30: prio 2 rate 184Kbit ceil 184Kbit burst 6Kb cb
urst 1834b
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 lended: 0 borrowed: 0 giants: 0
 tokens: 213703 ctokens: 63825

You can see, few packets were sent in the "high" class 1:10 and in the "middle" class 1:20. Ok, now the same information after a short VoIP call about 3-4 munutes:

[admin@(none) sbin]$ ./wshaper status eth1
qdisc ingress ffff:
statistics truncated
 qdisc sfq 30: quantum 1514b perturb 10sec
statistics truncated
 qdisc sfq 20: quantum 1514b perturb 10sec
statistics truncated
 qdisc sfq 10: quantum 1514b perturb 10sec
statistics truncated
 qdisc htb 1: r2q 10 default 20 direct_packets_stat 0
statistics truncated
 class htb 1:1 root rate 230Kbit ceil 230Kbit burst 6Kb cburst 1893b
 Sent 2493109 bytes 11851 pkts (dropped 0, overlimits 0)
 rate 10719bps 50pps
 lended: 0 borrowed: 0 giants: 0
 tokens: 149147 ctokens: 30887

class htb 1:10 parent 1:1 leaf 10: prio 1 rate 230Kbit ceil 230Kbit burst 6Kb cb
urst 1893b
 Sent 132 bytes 2 pkts (dropped 0, overlimits 0)
 lended: 2 borrowed: 0 giants: 0
 tokens: 169182 ctokens: 50922

class htb 1:20 parent 1:1 leaf 20: prio 2 rate 207Kbit ceil 207Kbit burst 6Kb cb
urst 1863b
 Sent 2492977 bytes 11849 pkts (dropped 0, overlimits 0)
 rate 10720bps 50pps
 lended: 11849 borrowed: 0 giants: 0
 tokens: 165720 ctokens: 33391

class htb 1:30 parent 1:1 leaf 30: prio 2 rate 184Kbit ceil 184Kbit burst 6Kb cb
urst 1834b
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 lended: 0 borrowed: 0 giants: 0
 tokens: 213703 ctokens: 63825

The number of packets sent in the "high" class is still the same. How can it be? I wrote the rule for filtering of the VoIP traffic in exactly the same way like the predefined rule for ICMP:

# My code: high priority for VoIP traffic (IP)
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
   match ip src 192.168.38.2 flowid 1:10

# ICMP (ip protocol 1) in the interactive class 1:10 so we
# can do measurements & impress our friends:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
   match ip protocol 1 0xff \
   flowid 1:10

And the rule for ICMP is really working, if I call something like "ping -t www.google.com" after that I'll get following status:

[admin@(none) sbin]$ ./wshaper status eth1
qdisc ingress ffff:
statistics truncated
 qdisc sfq 30: quantum 1514b perturb 10sec
statistics truncated
 qdisc sfq 20: quantum 1514b perturb 10sec
statistics truncated
 qdisc sfq 10: quantum 1514b perturb 10sec
statistics truncated
 qdisc htb 1: r2q 10 default 20 direct_packets_stat 0
statistics truncated
 class htb 1:1 root rate 230Kbit ceil 230Kbit burst 6Kb cburst 1893b
 Sent 2495319 bytes 11885 pkts (dropped 0, overlimits 0)
 rate 179bps 1pps
 lended: 0 borrowed: 0 giants: 0
 tokens: 169404 ctokens: 51144

class htb 1:10 parent 1:1 leaf 10: prio 1 rate 230Kbit ceil 230Kbit burst 6Kb cb
urst 1893b
 Sent 1464 bytes 20 pkts (dropped 0, overlimits 0)
 rate 37bps
 lended: 20 borrowed: 0 giants: 0
 tokens: 168960 ctokens: 50700

class htb 1:20 parent 1:1 leaf 20: prio 2 rate 207Kbit ceil 207Kbit burst 6Kb cb
urst 1863b
 Sent 2493855 bytes 11865 pkts (dropped 0, overlimits 0)
 rate 136bps
 lended: 11865 borrowed: 0 giants: 0
 tokens: 188229 ctokens: 55900

class htb 1:30 parent 1:1 leaf 30: prio 2 rate 184Kbit ceil 184Kbit burst 6Kb cb
urst 1834b
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 lended: 0 borrowed: 0 giants: 0
 tokens: 213703 ctokens: 63825

ICMP (ping) packets appears in the "high" class and I've sent exactly 18 packets.

I'm really in despair. What can be wrong with my filter rule?

Regards

Robert

[Styno]

Still hung over from last night, I'll give it a silly try:
- Is there a rule above the VoiP rule which could have put the data in the default rule?
Even sillier probably:
- Is the src IP for the VoiP rule correct?

[akbor]

Hi Styno,

I hope you are already better I wish I drank somthing last night, but instead of that I spent my time with Wondershaper

- Is there a rule above the VoiP rule which could have put the data in the default rule?

No, I've just inserted only one rule for the IP of my VoIP adapter. My earlier attempts to make a TOS-rule and a PORT-rule are commented out. Just have a look to the wshaper.txt in the attachment.

- Is the src IP for the VoiP rule correct?

The IP is in each case correct, see image below, my VoIP adapter gets the IP from WL-500g over DHCP, but according to its MAC that's always the same (Manually Assigned IP) IP address.

[akbor]

Well gentlemen,

after one more night with Wondershaper I said: "OK, then I'll build my own script with black jack and hookers"

So I began a critical review of the built-in wshaper from the Olegs FW 1.9.2.7-7e. I found out, that this script is identical to the HTB example from http://lartc.org/howto/lartc.cookboo...c.html#AEN2241. Of course, more parameters $5, $6, $7, $8 for an interactive script-call, a low-priority class "1:30" and four filter rules for this queue and something more were added by Oleg (or maybe somebody else?).

By the way, I wasn't able to use the class "1:30", I think the filter rules for this class don't work properly. If I called the script in this way:

./wshaper start eth1 1024 256 192.168.38.4 192.168.38.4

or

./wshaper start eth1 1024 256 "" "" "20 21" "20 21"

(192.168.38.4 is the IP of my FTP server in my local network) I didn't observe any traffic in the class "1:30" at all. A status-call showed always "Sent 0 bytes 0 pkts (dropped 0, overlimits 0)" in this class. Do anybody disagree in this point?

Well, then I considered following points of the existing built-in script:

-> Why should we spend 100% bandwidth for pings, ssh and acknowledges? I think, for my purpose (1 channel VoIP) and these all things together 50% (128 kbit in my case) at least are enough.

-> Why we don't use "rate" and "ceil" for min. (guaranteed) and max. (if available) data rates?

-> How can it be, that we have a "stochastic fairness" and three concurrent classes with 100%+90%+80% (= 270% in worst case?!) guaranteed rate?

-> Why do the bulk class and the low-prio class have the same prio = 2?

-> Why do all rules in the high-prio class have the same prio = 10?

-> Why do the rules in the low-prio class have priorities 14, 15, 16, 17?

-> Why does the default rule for the bulk class have the prio = 18?

So I tried to redefine the three classes. The high-prio class will get prio 1 and a bandwidth of 50% to 100%, the bulk class will get prio 2 and 40% to 100% of the bandwidth, the low-prio class will get prio 3 and the rest (10%-100%) of the bandwidth. The sum of the (guaranteed) rates is 100% exactly:

                      +-------+
                      | qdisc |
                      +-------+
                          |
       +---------------------------------------+
       |            root class 1:1             |
       |        rate 100% / ceil 100%          |
       +---------------------------------------+
         |                 |                 |
  +-------------+  +---------------+  +-------------+
  |hi class 1:10|  |main class 1:20|  |lo class 1:30|
  |  rate 50%   |  |    rate 40%   |  |  rate 10%   |
--|  ceil 100%  |--|    ceil 100%  |--|  ceil 100%  |--
| |  prio 1     |  |    prio 2     |  |  prio 3     | |
| +-------------+  +---------------+  +-------------+ |
|        ^                 ^                 ^        |
---------(------SFQ--------(-----------------(---------
         |                 |                 |
  +------------+    +------------+    +------------+
  |filter rules|    |filter rules|    |filter rules|
  |tc filter...|    |tc filter...|    |tc filter...|
  +------------+    +------------+    +------------+

Then after countless experiments with different filter rules I found only one working way to prioritize my VoIP-tarffic:

# high priority for VoIP traffic (by Port)
tc filter add dev $DEV parent 1:0 protocol ip prio 1 u32 \
   match ip sport 5004 0xffff \
   match ip protocol 0x11 0xff \
   flowid 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 1 u32 \
   match ip sport 5060 0xffff \
   match ip protocol 0x11 0xff \
   flowid 1:10

My mistake (see recent posts) was, that I used the destination port "dport" in the rule. With the source port "sport" it works really. Now I use 5060 for SIP signalling and 5004 for RTP stream because my ATA really uses these ports. Of course they can vary depend on the VoIP hardware and provider. Now I can see an increasing number of packets in the status output when I phone! Yess!

The rule containing the TOS (0x68 for SIP, 0xb8 for RTP ??) doesn't work with my VoIP adapter. I don't know exactly why, but I suppose that my adapter doesn't write the TOS to the outgoing packets correctly. I left this rule in the script although, maybe it will work with an other adapter. EDIT 29.08.06:Today I found out, my supposition was correct. I found a configuration field for my VoIP adapter "QoS Layer3" initialized by default with 48 decimal. I didn't know that QoS Layer3 bases on TOS. Now I set this field to 184 (0xb8) and it seems to work correctly with Wondershaper.

The rule containing the source IP doesn't work at all. And I don't have any idea why. I removed this rule from my script.

I gave some different priorities for rules in the high-prio class: prio 1 for VoIP-rules and for ICMP, because I think ICMP produce only few traffic; prio 2 for acknowledges, etc.; prio 3 for ssh.

I corrected the rule priority in the bulk class to 1, but I think it doesn't matter, because there is only one rule.

I didn't have any time yet for experimenting with the low-prio class. I can only say, I couldn't get it working at all. I don't use any filesharing clients, maybe if I'll have some time, I'll write some rule for slowing down my FTP server in this class, so I'll get more priority for SMTP uploads...

I didn't have time for an intensive test yet, I can only say my modified script seems to work

My values for bandwidth and prio may be suboptimal - so I am pleased about your (fair!) comments and suggestions!

be good

Robert

[Styno]

Nice to see you got the hang of it, akbor. Good job!