Re: [LARTC] New HTB-derived qdisc for accounting?

[Carl-Daniel Hailfinger <c-d.hailfinger.devel.2005@gmx.net>]

Patrick McHardy schrieb:
> Carl-Daniel Hailfinger wrote:
> 
>>Proposal:
>>----------------------------------
>>Another idea would be to create a qdisc HTBQ (HTB with quota)
>>derived from HTB with the following characteristics:
>>
>>htb_rate=min(htbq_rate, (alreadysent=>htbq_squota)?((htbq_quota-alreadysent)/remtime):htbq_rate)
> 
> 
> Why do you want to decrease speed as the quota is approached?

We have two phases (simplified):
1. Already sent traffic is less than htbq_squota
     -> Do not limit anything.
2. Already sent traffic is more than htbq_squota
     -> Limit the rate to something which allows the quota
        to be filled completely in the remainig time.

Most people stay below htbq_squota and do not notice
anything at all, i.e. they get full wire speed. Power users
will cause more traffic than htb_squota and be limited so
they can't get over htbq_quota. Since it is impossible to
send faster than htb_rate, htb_rate will stay constant if
it is fully utilized. If htb_rate is not fully utilized,
the speed will actually *increase* over time.

> Wouldn't a simple per-class quota or a quota-ematch work as
> well?

That would be easier, but I can't see how to realize the
process above with a quota-ematch. Especially the dynamic
rate adaption needs something more than just quota.
Probably one could combine quota-ematch with some userspace
hackery to achieve what I want, but it would require to
statically set up 65536 classes for a /16 network. Hm.
The only difference to my solution would be that we need
a quota ematch instead of a htb_quota qdisc and rate control
would be done in userspace.

So where can I find code doing a quota ematch?


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc