On Sat, 24 Apr 2004 00:11:32 +0100, Andy Furniss <andy.furniss@xxxxxxxxxxxxx> wrote: > One possible problem - I don't think connbytes will patch with connmark > (which IIRC ipp2p uses). I have been told that it is possible to get > them to work, but patch will fail as they both change the same struct, > so it's a do it by hand job... Im usually all for the "do it by hand" thing, but im not really up for screwing with this yet i think :) Its correct that ipp2p uses connmark... That way it is only necessary to tag a connection once, then leave it. Great for those huge setups, where the ipp2p usage should be kept at a minimum.. Afaik its a bit heavy on ressources. [SNIP - torrent talk] > LOL - I think your idea about reducing rwin may help - easy on a small > setup where you have control. That was my idea, but so far ive only found out how to alter the window size on a per route basis. If it could just be extended a little by making new connections have a small size, then putting them back to normal after a while. But if i went all the way out there, i might just as well start a complete dynamic window chaning thing. [SNIP - more torrent and ipp2p] > Yes - so you don't need to mark all those ports then. Probably not, but i dont think the extra overhead will do any harm as long as its a puny adsl im dealing with :) I guess im not trusting ipp2p enough. > Yes esfq on dst will make things fair per IP address - but in the case > of ingress with the many tcps that BT uses dropping is important to get > the sender to back off. Esfq on dst is not really a fairness queue any > more WRT individual tcp connections, it may not make much difference, > but if you use htb for per IP fairness and esfq classic, then the drops > are a bit more likely to get at the most active connections. > > I modified esfq to drop from the head of a slot rather than the end - > which in theory should make things slightly nicer and changed hash to > use dst port. I really ought to make them into a switches (when I work > out how) I also intend to patch with the change to sfq that was recently > talked about on here. If it looks OK I'll put it up on my webspace > sometime - I don't really know what I am doing though :-) Sounds nice, share when you think its stable. Im all for betatesting too if you need any. > For us small bandwidth users a R(real)FQ would be nice - (e)sfq is OK > but it often hashes into the same slot and perturb causes packet > reordering which hurts more when used for ingress. I will try fiddling without esfq with fingers crossed - thanks. -- Patrick Petersen <lartc@xxxxxxxxxx> _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
