Patrick McHardy wrote:
BTW the Blue scheduler patch for 2.6 seems to be working nicely - but I haven't had the time to run the tests on it that I wished to, so I haven't posted anything further about it.
I have in the mean time read up on SFB, maybe I'll extend blue when I find the time.
Adding n curves gives you (in the worst case) a (n+1)-ary curve, you can calculate it like this:
sc1: m1 = 100kbit, d = 1s, m2 = 200kbit sc2: m1 = 50kbit, d = 0.25s, m2 = 300kbit sc3: m1 = 200kbit, d = 1.5s, m2 = 500kbit ----------------------------------------- m = { 350kbit d <= 0.25s 600kbit 0.25s < d <= 1s 700kbit 1s < d <= 1.5s 1000kbit d > 1.5s }
Right. I think there's a need for a small tool to make these calculations - and perhaps even to automatically be able to scale other curves to maintain the restrictions. But that is for the future, manual calculation will do for now.
Yes that would certainly be better.
I also seem to have a lot of difficulties in trying to simulate the behaviour of the qdisc.
[...]
Have you applied the patches from trash.net/~kaber/hfsc/tcsim ? With HZ=1000 and PSCHED_GETTIMEOFDAY as clocksource I got very good results.
I tried HZ=1000 and HZ=100 both, and the results were odd. But I think I didn't touch the clocksource at all. I will try later on with PSCHED_GETTIMEOFDAY as well.
PSCHED_GETTIMEOFDAY (or PSCHED_CPU in case of the kernel) are important for HFSC to work properly, PSCHED_JIFFIES has too low resolution.
Works ok here .. do you mean inside tcsim ?
No, I don't mean inside tcsim. Here is a full transcript:
***** shiro:~# export DEV=lo shiro:~# tc -s -d qdisc show dev $DEV shiro:~# ping localhost -c 4 PING shiro.i.naked.iki.fi (127.0.0.1) 56(84) bytes of data. 64 bytes from shiro.i.naked.iki.fi (127.0.0.1): icmp_seq=1 ttl=64 time=0.062 ms 64 bytes from shiro.i.naked.iki.fi (127.0.0.1): icmp_seq=2 ttl=64 time=0.059 ms 64 bytes from shiro.i.naked.iki.fi (127.0.0.1): icmp_seq=3 ttl=64 time=0.059 ms 64 bytes from shiro.i.naked.iki.fi (127.0.0.1): icmp_seq=4 ttl=64 time=0.060 ms
--- shiro.i.naked.iki.fi ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.059/0.060/0.062/0.001 ms
shiro:~# tc qdisc add dev $DEV root handle 1: hfsc default 1 shiro:~# tc class add dev $DEV parent 1: classid 1:1 hfsc rt m2 100kbps shiro:~# ping localhost -c 4 PING shiro.i.naked.iki.fi (127.0.0.1) 56(84) bytes of data. ^C --- shiro.i.naked.iki.fi ping statistics --- 0 packets transmitted, 0 received
shiro:~# tc -s -d qdisc show dev $DEV
qdisc hfsc 1: default 1 Sent 0 bytes 0 pkts (dropped 17, overlimits 0)
shiro:~# tc -s -d class show dev $DEV
class hfsc 1: root Sent 0 bytes 0 pkts (dropped 0, overlimits 0) period 0 level 1
class hfsc 1:1 parent 1: rt m1 0bps d 0us m2 800Kbit Sent 0 bytes 0 pkts (dropped 17, overlimits 0) period 0 level 0
shiro:~# tc qdisc del dev $DEV root shiro:~# ping localhost -c 4 PING shiro.i.naked.iki.fi (127.0.0.1) 56(84) bytes of data. 64 bytes from shiro.i.naked.iki.fi (127.0.0.1): icmp_seq=1 ttl=64 time=0.060 ms 64 bytes from shiro.i.naked.iki.fi (127.0.0.1): icmp_seq=2 ttl=64 time=0.060 ms 64 bytes from shiro.i.naked.iki.fi (127.0.0.1): icmp_seq=3 ttl=64 time=0.057 ms 64 bytes from shiro.i.naked.iki.fi (127.0.0.1): icmp_seq=4 ttl=64 time=0.059 ms
--- shiro.i.naked.iki.fi ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.057/0.059/0.060/0.001 ms
shiro:~# uname -a Linux shiro 2.6.3-shiro-1 #1 Sat Mar 6 21:03:38 EET 2004 i686 GNU/Linux *****
So, I don't know what's up with that. I will debug further.
I know what the problem is. Try: ip link set lo txqueuelen 1 or upgrade to 2.6.4. The problem got introduces when fixing an off-by-one in pfifo_fast, before it would enqueue one packet with a txqueuelen of 0. In 2.6.4 this behaviour is restored, although it's a misconfiguration anyway to use leaf-queues with a limit of 1 for anything but well-formed flows.
Anyhow, I will try now to come up with a working setup of HFSC for my personal use, and in the process I will try to document a sane method for coming up with the service curves and setting up the whole thing.
If that works out, more comprehensive documentation can come later.
Great, I'm looking forward to it.
Regards Patrick
This has been very helpful, thank you!
-- Naked
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
