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/
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/
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
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/
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/