Sorry for the long response time. On Sun, 18 Apr 2004 00:13:49 +0100, Andy Furniss <andy.furniss@xxxxxxxxxxxxx> wrote: > I sortof workaround this using the connbytes netfilter patch to make the > first 80k of new connections go into a short queue limited to 1/3 - 1/2 > of my downstream bandwidth. I will try this soon.. I recently screwed my kernel over bad with patch-o-matic, so its fixing time at the moment :) > Ahh bittorrent - this is a special case. It uses full duplex tcp - so > may break some upstream shapers, you can assume that a fair number of > your peers have flooded modem buffers - so there could be quite a few > "unstoppable" packets headed your way. The worse thing about it, though > is that it runs it's own algorithm on allready open tcps - so existing > connections may go back into slowstart. Thats pretty bad.. But if i get this working, even with bittorrent, i guess that means it will probably work with anything! :) > > Would it be possible to lower the default window size, and thereby > > making tcp start up slower, or would this just lower the overall speed? > > It could help, but may also give you less of a share of a given > uploaders bandwidth. Reducing MTU may also help (if you run BT on linux > it may reduce rwin for you aswell). > > I don't think you can catch all BT traffic by marking the BT ports, I > see ipp2p - can you do it with this or maybe do per IP fairness for bulk > traffic? Im fortunate enough to be able to run a small network with only a few people, so theres no real bad things with people doing whatever they can to cheat. Also, ipp2p should catch torrent connections, and seems to be doing so. > Be carefull about priorotising acks - don't all TCP packets after syn > have ack set. Being lazy on a home setup I get away with giving small > packets priority - saves alot of marking :-) > > For ingress shaping - I find it nicer to shape per IP with htb and use > esfq classic to get per tcp fairness rather than esfq on dst which is > going to effectively make many bittorrent connections go into a FIFO, > which could make for more burstiness. I'll make a note, but shouldnt esfq make things more or less fair no matter how much traffic one client has over another? -- Patrick Petersen <lartc@xxxxxxxxxx> _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
