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
[email protected]
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
