Hi Andy Furniss,
On Mon, 04 Apr 2005 16:23:30 +0100, Andy Furniss <andy.furniss@xxxxxxxxxxxxx> wrote:
Because this per-flow queue is new, you can add things useful to it.
It does look good :-) I'll test when I get time.
The attached is the latest. The last one doesn't sync time: queue has a variable time slot length; every flow has it own ticks.
This new patch against 2.6.11 sync queue and flows' time. Every new flow has it jiffies set to q->jiffies and use that as start. As q->jiffies and flow->jiffies increament in HZ step, time is synced. This will improved accuracy.
But HZ is too long for token calculation. Sometimes, one of flow borrows too much and get no enough penalty, so another flow hurts. But anyway, per flow queue provides better fairness in my test, either in short time period or long time period.
Looking forward to your feedback :)
It works OK for me - though I would really need it to be variable rate to use really - but as you say it's designed for your needs.
I noticed that it drops icmp so you need to be careful about what you send to it.
If you limit connections and use them all up then alive but not always active connections will get locked out - there is a netfilter connection limit already.
As you say above it's not always fair - I didn't test that much it seemed OK apart from if htb limited it ie.
htb rate higher than sum of rates but less than sum of ceils made it unfair to a flow with smaller packet size.
Andy. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
