Hi Andy Furniss, On Tue, 05 Apr 2005 23:40:54 +0100, Andy Furniss <andy.furniss@xxxxxxxxxxxxx> wrote: > > > > 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. I plan to optionally reclassify unhandled traffic to another class if specified. So a default class may handle 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. Yes. I also think that low rate or small packet size stream will have problem. I didn't test that case yet. I read back your post and I think the best solution for you is use HTB + PRIO. Let interactive but low rate traffic have highest priority, and let bulk transfer have lowest priority and constrain them using HTB. TCP itself has some fairness: slower stream get faster, and faster stream get slower. The sliding window is for this. -- lark _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
