[LARTC] HFSC

[LARTC] HFSC

[Rick Goh]

[-- Attachment #1: Type: text/plain, Size: 324 bytes --]

Has anyone successfully patched HFSC (ported by Alex Goldney) into linux kernel and tested it?

I'm doing an analysis on the various queueing algo (red,cbq,wrr,tbf), Diffserv and I hope to put hfsc into the picture...

There is also CSZ but it was claimed that it is inoperational. is this still true??


Regards.


[-- Attachment #2: Type: text/html, Size: 932 bytes --]

[LARTC] HFSC

[syrius.ml]

hmm
HFSC ?
where can i find more informations and examples about the *linux* HFSC
?
http://trash.net/~kaber/hfsc/ does not help here

-- 
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HFSC

[Patrick McHardy]

syrius.ml@no-log.org wrote:
> hmm
> HFSC ?
> where can i find more informations and examples about the *linux* HFSC
> ?
> http://trash.net/~kaber/hfsc/ does not help here
> 

This is currently all there is. If you have some specific questions,
just ask (but please CC lartc). If anyone wants to write some
documentation I'd be happy to help, but I don't have time for it
myself.

Regards
Patrick
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HFSC

[syrius.ml]

syrius.ml@no-log.org writes:

> where can i find more informations and examples about the *linux* HFSC
> ?
> http://trash.net/~kaber/hfsc/ does not help here

the patch http://trash.net/~kaber/hfsc/ provides compiles correctly
when applied on
ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.4.7-now-ss020116-try.tar.gz
but not on ss010824.

# tc qdisc add dev eth0 root hfsc help
Usage: ... hfsc [ default CLASSID ]

# tc qdisc add dev eth0 root hfsc default 1:10
HFSC: Illegal "default"

(same results without the "root" option)


without talking about the wireless features, what's the difference
between http://trash.net/~kaber/hfsc and http://wsched.sf.net hfsc ?

what are rt, ls and ul service curves ?

-- 
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HFSC

[Patrick McHardy]

syrius.ml@no-log.org wrote:
> syrius.ml@no-log.org writes:
> 
> 
>>where can i find more informations and examples about the *linux* HFSC
>>?
>>http://trash.net/~kaber/hfsc/ does not help here
> 
> 
> the patch http://trash.net/~kaber/hfsc/ provides compiles correctly
> when applied on
> ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.4.7-now-ss020116-try.tar.gz
> but not on ss010824.
> 
> # tc qdisc add dev eth0 root hfsc help
> Usage: ... hfsc [ default CLASSID ]
> 
> # tc qdisc add dev eth0 root hfsc default 1:10
> HFSC: Illegal "default"

Default is just a class ID in the namespace of the qdisc,
so you can't specify a handle:

tc qdisc add dev eth0 root hfsc default 10

Regards
Patrick

> 
> (same results without the "root" option)
> 
> 
> without talking about the wireless features, what's the difference
> between http://trash.net/~kaber/hfsc and http://wsched.sf.net hfsc ?
> 
> what are rt, ls and ul service curves ?
> 

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HFSC

[Patrick McHardy]

syrius.ml@no-log.org wrote:
> syrius.ml@no-log.org writes:
> without talking about the wireless features, what's the difference
> between http://trash.net/~kaber/hfsc and http://wsched.sf.net hfsc ?
> 
> what are rt, ls and ul service curves ?
> 

Regarding this question (please CC me on further questions), the
wsched HFSC port is crappy, it seems to be ported mindlessly without
adapting some parameters to linux (I wonder why the guy got his diploma
for this), which will result in sub-optimal behaviour. Besides, my port
is merged in the mainstream kernel and requires no patching, but the
wsched scheduler includes infrastructure (I can not comment on quality
here) for adapting assigned bandwidth to real conditions for wireless
links.

Regards
Patrick
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

[LARTC] HFSC

[Lawrence MacIntyre]

Hi:

I am using a machine with the 2.4.26 kernel, and trying to compare the 
performance of the HTB qdisc with the HFSC one.  I have the following 
simple script that allows me to have a video stream on port 1234 while 
it limits a ttcp UDP stream so that the video stream is unimpaired.

#!/bin/bash

tc qdisc add dev eth0 root handle 1: htb default 12

tc class add dev eth0 parent 1: classid 1:1 htb rate 30mbit ceil 30mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 20mbit ceil 30mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 10mbit ceil 30mbit

tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 5
tc qdisc add dev eth0 parent 1:11 handle 30: pfifo limit 5

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 
1234 0xffff flowid 1:10
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 
5001 0xffff flowid 1:11

Now I would like to try H-FSC.  I'm not sure exactly how to go about 
this.  I thought that creating a ul class with two ls classes inside and 
then putting an rt class in one of the ls classes for the video might 
work, but I can't seem to get it to work.  For example,

#!/bin/bash

/usr/local/bin/tc qdisc add dev eth0 root handle 1: hfsc

/usr/local/bin/tc class add dev eth0 parent 1: classid 1:1 hfsc ul m1 
30mbit d 0 m2 30mbit ls m1 30mbit d 0 m2 30mbit

When the second command is executed, the machine simply drops all 
packets going through it.  I would like to try the 2.6 kernel, but my 
machine has an Adaptec SCSI controller that has a broken driver for the 
2.6 kernel.

I don't understand why this statement causes the machine to drop all 
packets on the eth0 interface.
-- 
     Lawrence MacIntyre     865.574.8696     lpz@ornl.gov
                Oak Ridge National Laboratory
High Performance Information Infrastructure Technology Group
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HFSC

[Patrick McHardy]

Lawrence MacIntyre wrote:
> /usr/local/bin/tc qdisc add dev eth0 root handle 1: hfsc
> 
> /usr/local/bin/tc class add dev eth0 parent 1: classid 1:1 hfsc ul m1 
> 30mbit d 0 m2 30mbit ls m1 30mbit d 0 m2 30mbit
> 
> When the second command is executed, the machine simply drops all 
> packets going through it.

Unlike HTB, HFSC drops unclassified packets. You need to setup filters
or use the "default" classification.

Regards
Patrick
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HFSC

[Lawrence MacIntyre]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

Thanks, Patrick.  That makes it a bit harder to manage from a remote 
machine.  I'll have to be very careful with that.  I'll try to figure 
out the implications of the default classification and send more email 
if I can't get it.

So I reordered the commands and changed them around.  It looks like I am 
either doing something strange or I have found a bug.  When I execute 
the following script, the UDP traffic on port 1234 continues for a few 
seconds and then stops.  When I examine the tc data, it shows no change 
in the periods or amount of bytes flowing after the flow stops.  I am 
enclosing the command  and the output.

Thanks again!

Patrick McHardy wrote:
> Lawrence MacIntyre wrote:
> 
>> /usr/local/bin/tc qdisc add dev eth0 root handle 1: hfsc
>>
>> /usr/local/bin/tc class add dev eth0 parent 1: classid 1:1 hfsc ul m1 
>> 30mbit d 0 m2 30mbit ls m1 30mbit d 0 m2 30mbit
>>
>> When the second command is executed, the machine simply drops all 
>> packets going through it.
> 
> 
> Unlike HTB, HFSC drops unclassified packets. You need to setup filters
> or use the "default" classification.
> 
> Regards
> Patrick

-- 
     Lawrence MacIntyre     865.574.8696     lpz@ornl.gov
                Oak Ridge National Laboratory
High Performance Information Infrastructure Technology Group

[-- Attachment #2: hfsc.conf.4 --]
[-- Type: text/x-troff-man, Size: 919 bytes --]

#!/bin/bash
/usr/local/bin/tc qdisc add dev eth0 root handle 1: hfsc 

/usr/local/bin/tc class add dev eth0 parent 1: classid 1:1 hfsc ul m1 80mbit d 500 m2 30mbit ls m1 80mbit d 500 m2 30mbit
/usr/local/bin/tc class add dev eth0 parent 1:1 classid 1:10 hfsc ls m1 50mbit d 500 m2 20mbit
/usr/local/bin/tc class add dev eth0 parent 1:1 classid 1:11 hfsc ls m1 20mbit d 500 m2 10mbit
/usr/local/bin/tc class add dev eth0 parent 1:1 classid 1:12 hfsc ls m1 10mbit d 500 m2 10mbit

/usr/local/bin/tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 1234 0xffff flowid 1:10
/usr/local/bin/tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 5001 0xffff flowid 1:11
/usr/local/bin/tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 22 0xffff flowid 1:12
/usr/local/bin/tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 22 0xffff flowid 1:12

[-- Attachment #3: data --]
[-- Type: text/plain, Size: 4157 bytes --]

[root@castor QoS]# ./tcshow.conf
class hfsc 1: root
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 period 0 level 2
 
class hfsc 1:11 parent 1:1 ls m1 20Mbit d 500us m2 10Mbit
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 period 0 level 0
 
class hfsc 1:1 parent 1: ls m1 80Mbit d 500us m2 30Mbit ul m1 80Mbit d 500us m2
30Mbit
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 period 492 work 7280180 bytes level 1
 
class hfsc 1:10 parent 1:1 ls m1 50Mbit d 500us m2 20Mbit
 Sent 7280180 bytes 5314 pkts (dropped 0, overlimits 0)
 period 492 work 7280180 bytes level 0
 
class hfsc 1:12 parent 1:1 ls m1 10Mbit d 500us m2 10Mbit
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 period 0 level 0
 
qdisc hfsc 1:
 Sent 7280180 bytes 5314 pkts (dropped 0, overlimits 6570)
filter parent 1: protocol ip pref 1 u32
filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
flowid 1:10
  match 000004d2/0000ffff at 20
filter parent 1: protocol ip pref 1 u32 fh 800::801 order 2049 key ht 800 bkt 0
flowid 1:11
  match 00001389/0000ffff at 20
filter parent 1: protocol ip pref 1 u32 fh 800::802 order 2050 key ht 800 bkt 0
flowid 1:12
  match 00000016/0000ffff at 20
filter parent 1: protocol ip pref 1 u32 fh 800::803 order 2051 key ht 800 bkt 0
flowid 1:12
  match 00160000/ffff0000 at 20
[root@castor QoS]# ./tcshow.conf
class hfsc 1: root
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 period 0 level 2
 
class hfsc 1:11 parent 1:1 ls m1 20Mbit d 500us m2 10Mbit
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 period 0 level 0
 
class hfsc 1:1 parent 1: ls m1 80Mbit d 500us m2 30Mbit ul m1 80Mbit d 500us m2
30Mbit
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 period 965 work 14246630 bytes level 1
 
class hfsc 1:10 parent 1:1 ls m1 50Mbit d 500us m2 20Mbit
 Sent 14246630 bytes 10399 pkts (dropped 0, overlimits 0)
 period 965 work 14246630 bytes level 0
 
class hfsc 1:12 parent 1:1 ls m1 10Mbit d 500us m2 10Mbit
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 period 0 level 0
 
qdisc hfsc 1:
 Sent 14246630 bytes 10399 pkts (dropped 32, overlimits 12895)
filter parent 1: protocol ip pref 1 u32
filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
flowid 1:10
  match 000004d2/0000ffff at 20
filter parent 1: protocol ip pref 1 u32 fh 800::801 order 2049 key ht 800 bkt 0
flowid 1:11
  match 00001389/0000ffff at 20
filter parent 1: protocol ip pref 1 u32 fh 800::802 order 2050 key ht 800 bkt 0
flowid 1:12
  match 00000016/0000ffff at 20
filter parent 1: protocol ip pref 1 u32 fh 800::803 order 2051 key ht 800 bkt 0
flowid 1:12
  match 00160000/ffff0000 at 20
[root@castor QoS]# ./tcshow.conf
class hfsc 1: root
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 period 0 level 2
 
class hfsc 1:11 parent 1:1 ls m1 20Mbit d 500us m2 10Mbit
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 period 0 level 0
 
class hfsc 1:1 parent 1: ls m1 80Mbit d 500us m2 30Mbit ul m1 80Mbit d 500us m2
30Mbit
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 period 965 work 14246630 bytes level 1
 
class hfsc 1:10 parent 1:1 ls m1 50Mbit d 500us m2 20Mbit
 Sent 14246630 bytes 10399 pkts (dropped 0, overlimits 0)
 period 965 work 14246630 bytes level 0
 
class hfsc 1:12 parent 1:1 ls m1 10Mbit d 500us m2 10Mbit
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 period 0 level 0
 
qdisc hfsc 1:
 Sent 14246630 bytes 10399 pkts (dropped 33, overlimits 12895)
filter parent 1: protocol ip pref 1 u32
filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
flowid 1:10
  match 000004d2/0000ffff at 20
filter parent 1: protocol ip pref 1 u32 fh 800::801 order 2049 key ht 800 bkt 0
flowid 1:11
  match 00001389/0000ffff at 20
filter parent 1: protocol ip pref 1 u32 fh 800::802 order 2050 key ht 800 bkt 0
flowid 1:12
  match 00000016/0000ffff at 20
filter parent 1: protocol ip pref 1 u32 fh 800::803 order 2051 key ht 800 bkt 0
flowid 1:12
  match 00160000/ffff0000 at 20
[root@castor QoS]# ./hfscdel.conf

Re: [LARTC] HFSC

[Patrick McHardy]

Lawrence MacIntyre wrote:
> Thanks, Patrick.  That makes it a bit harder to manage from a remote 
> machine.  I'll have to be very careful with that.  I'll try to figure 
> out the implications of the default classification and send more email 
> if I can't get it.
> 
> So I reordered the commands and changed them around.  It looks like I am 
> either doing something strange or I have found a bug.  When I execute 
> the following script, the UDP traffic on port 1234 continues for a few 
> seconds and then stops.  When I examine the tc data, it shows no change 
> in the periods or amount of bytes flowing after the flow stops.  I am 
> enclosing the command  and the output.

It is indeed strange. Only the qdisc drop counter is incremented, which
means the packets are still unclassified. What happens if you change
your filter to:

/usr/local/bin/tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 
match udp dport 1234 0xffff flowid 1:10 (match udp instead of ip)

Are you sure the packets are sent to port 1234 ?

Regards
Patrick
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HFSC

[Lawrence MacIntyre]

Patrick:

I tried that filter line, but it has incorrect syntax.  But that isn't 
the problem.  The problem is the HFSC part...  The traffic is indeed UDP 
port 1234, and the HFSC qdisc functions for a short period of time 
(between 5 and 60 seconds or so, and then stops passing any traffic on 
the eth0 interface.  You can look with ethereal, and the interface is 
totally silent.  Even weirder, if you wait, periodically (every several 
minutes or so) you get another period of working.  These are typically 
5-10 seconds.  What do I need to do to debug this?  The machine is a 
dual Xeon, if that matters.

Patrick McHardy wrote:
> Lawrence MacIntyre wrote:
> 
>> Thanks, Patrick.  That makes it a bit harder to manage from a remote 
>> machine.  I'll have to be very careful with that.  I'll try to figure 
>> out the implications of the default classification and send more email 
>> if I can't get it.
>>
>> So I reordered the commands and changed them around.  It looks like I 
>> am either doing something strange or I have found a bug.  When I 
>> execute the following script, the UDP traffic on port 1234 continues 
>> for a few seconds and then stops.  When I examine the tc data, it 
>> shows no change in the periods or amount of bytes flowing after the 
>> flow stops.  I am enclosing the command  and the output.
> 
> 
> It is indeed strange. Only the qdisc drop counter is incremented, which
> means the packets are still unclassified. What happens if you change
> your filter to:
> 
> /usr/local/bin/tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 
> match udp dport 1234 0xffff flowid 1:10 (match udp instead of ip)
> 
> Are you sure the packets are sent to port 1234 ?
> 
> Regards
> Patrick

-- 
     Lawrence MacIntyre     865.574.8696     lpz@ornl.gov
                Oak Ridge National Laboratory
High Performance Information Infrastructure Technology Group
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/