Re: [LARTC] Re: HFSC

[Patrick McHardy <kaber@trash.net>]

Nuutti Kotivuori wrote:
> 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\x1000 and PSCHED_GETTIMEOFDAY as clocksource I got very
>>good results.
> 
> 
> I tried HZ\x1000 and HZ\x100 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 ttld time=0.062 ms
> 64 bytes from shiro.i.naked.iki.fi (127.0.0.1): icmp_seq=2 ttld time=0.059 ms
> 64 bytes from shiro.i.naked.iki.fi (127.0.0.1): icmp_seq=3 ttld time=0.059 ms
> 64 bytes from shiro.i.naked.iki.fi (127.0.0.1): icmp_seq=4 ttld 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 ttld time=0.060 ms
> 64 bytes from shiro.i.naked.iki.fi (127.0.0.1): icmp_seq=2 ttld time=0.060 ms
> 64 bytes from shiro.i.naked.iki.fi (127.0.0.1): icmp_seq=3 ttld time=0.057 ms
> 64 bytes from shiro.i.naked.iki.fi (127.0.0.1): icmp_seq=4 ttld 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@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/