Gargoyle Forum

Hi all,

I still have a conceptual question about the current implementation of the qosmonitor.
I have a TPLink 1043 router with gargoyl and qos enabled. My ISP provides my a 16000/1024 ADSL line and I set the UL&DL limit accordingly. I did not changes the 3 standard classes so far
What I can see is, that with the standard classes you create 3 qdiscs with RED and additional 3 classes with HFSC for wan(engress) and imq(ingress). And in a case of congestion, which is a zero/one desicion by the qosmon, you change the HFSC limits ?
BTW is qosmon just having the two states = congestetd or not congested ... in in case of "congested" it resets the HFSC limits ?
Just now I tested the ping time towards google.de while I am downloading a torrent ubuntu release. When the torrent starts is increases the consumed BW to linespeed (16.000 MBit/sec) and the ping time grows from 24ms not congested to 120 ms while the torrent is running. As is seems from the classification, the layer7 filter does not classify bittorrent traffic correct, all traffic is counted as FAST. Maybe a default class with 50% max BW for all unclassifyed traffic is a better alternative ?



Bye Thomas

Hi all

Just to add some info to my previous posting, I set UL limit to 1024 and DL linmit to 16000.
But if I look at the HFSC classes that got created; I see:
class hfsc 1: root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
period 0 level 2

class hfsc 1:1 parent 1: ls m1 0bit d 0us m2 1000Mbit ul m1 0bit d 0us m2 1024Kbit
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
period 58611 work 4975001 bytes level 1

class hfsc 1:2 parent 1:1 leaf 8024: rt m1 160000bit d 20.0ms m2 80000bit ls m1 0bit d 0us m2 10000Kbit
Sent 17522 bytes 135 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
period 109 work 17522 bytes rtwork 12317 bytes level 0

class hfsc 1:3 parent 1:1 leaf 8025: ls m1 0bit d 0us m2 940000Kbit
Sent 4843254 bytes 66058 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 1p requeues 0
period 57441 work 4843188 bytes level 0

class hfsc 1:127 parent 1:1 leaf 802a: rt m1 67200bit d 10.0ms m2 2000bit
Sent 8722 bytes 89 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
period 0 work 8722 bytes rtwork 8722 bytes level 0

class hfsc 1:4 parent 1:1 leaf 8026: ls m1 0bit d 0us m2 50000Kbit
Sent 105569 bytes 1306 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
period 1294 work 105569 bytes level 0

Why are those m2 limit that high like 100MBIt ans 50 MBit ... and do not cerrespond to the limits I set before ?

Bye Thomas

If you study the way HFSC works you can see that link share can be allocated in percent. In my design 10Mbps = 1%. So these numbers correspond to the percent allocation you set in your classes.

I use the RT curve for the minimum bandwidth in (bps)
I use the LS curve for the percent allocation under load (%)
I use the UL curve for the maximum bandwidth in (bps)

Ok that sounds reasonable.
And how does qosmon come into the game ? Does it activly change the HFSC limits or does it just enable and disable HFSC shaping at all ?

Bye Thomas

It actively changes the UL of the root class as a function of the congestion it detects. All the LS of the leaf classes are on a percentage of that so they all ratio down.

The RT & LS limits of the leaf classes are stated in bps and are also limited by the UL of the root class.