From: Andy Furniss <andy.furniss@dsl.pipex.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] HFSC default upper-limit trouble
Date: Sun, 10 Jul 2005 19:37:39 +0000 [thread overview]
Message-ID: <42D17903.9010605@dsl.pipex.com> (raw)
In-Reply-To: <42CC2D0E.5010903@kitas.arturas.net>
Artūras Šlajus wrote:
> Hello,
>
> I'm having such problem with HFSC with following config:
> + tc qdisc del dev eth3 root
> + tc qdisc add dev eth3 root handle 1: hfsc default 2
> + tc class add dev eth3 parent 1: classid 1:1 hfsc ls rate 512kbit ul
> rate 512kbit
> + tc class add dev eth3 parent 1:1 classid 1:2 hfsc ls rate 2kbit ul
> rate 400kbit
> + tc class add dev eth3 parent 1:1 classid 1:3 hfsc ls rate 32kbit ul
> rate 32kbit
> + tc class add dev eth3 parent 1:1 classid 1:4 hfsc ls rate 300kbit ul
> rate 300kbit
>
> Let's say i start to upload thru 1:3. the upper-limit applies, traffic
> doesn't do up more than 4kb/s. The 1:4 is still functional, but 1:2, the
> default class starts backlogging and dropping as hell:
Seems to work OK for me - are you saying that there is traffic using
default but no backlog until you use 1:3?
> class hfsc 1: root
> Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
> period 0 level 2
>
> class hfsc 1:1 parent 1: ls m1 0bit d 0us m2 512000bit ul m1 0bit d 0us
> m2 512000bit
> Sent 0 bytes 0 pkts (dropped 0, overlimits 0) <-- This is weird too ^_^
> period 2643 work 821712 bytes level 1
You need to do a tc -s qdisc ls to get the overlimits counter for 1:0.
>
> class hfsc 1:2 parent 1:1 ls m1 0bit d 0us m2 2000bit ul m1 0bit d 0us
> m2 400000bit
> Sent 477205 bytes 3874 pkts (dropped 0, overlimits 0)
> backlog 201p <-- HUH? (it goes even to 800p..1000p then it starts
> dropping)
> period 2494 work 456595 bytes level 0
Remember arp will end up stuck here too unless you filter it elsewhere.
If you want to make the queue shorter add a p/b fifo or something and
specify limit.
>
> class hfsc 1:3 parent 1:1 ls m1 0bit d 0us m2 32000bit ul m1 0bit d 0us
> m2 32000bit
> Sent 350599 bytes 558 pkts (dropped 0, overlimits 0)
> backlog 11p
> period 70 work 342761 bytes level 0
>
> class hfsc 1:4 parent 1:1 ls m1 0bit d 0us m2 300000bit ul m1 0bit d 0us
> m2 300000bit
> Sent 22356 bytes 214 pkts (dropped 0, overlimits 0)
> period 212 work 22356 bytes level 0
>
> The 1:1 shows no packets sent as you see.. Is this desirable behavior?
> The default class kinda becomes unusable. Can someone explain me such
> behavior?
This is normal Patrick said in a recent post -
"HFSC doesn't update statistics of upper classes because I didn't want to
walk up the entire heirarchy for each packet just for statistics."
Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
prev parent reply other threads:[~2005-07-10 19:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-06 18:16 [LARTC] HFSC default upper-limit trouble Artūras Šlajus
2005-07-10 19:37 ` Andy Furniss [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42D17903.9010605@dsl.pipex.com \
--to=andy.furniss@dsl.pipex.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.