i'm just trying to slow the traffic (it's for my master|degree|pedigree thesis, so i don't want to waste all my life on this) without changing the window size.
How do we fit this thing into the linux QOS architecture anyway?
i'm writing a scheduler that just delay the ack rate (it's in a very preliminar state, so nearly nothing was done).
now i'm looking for a place where to put the flow information (in a
conntrack module, maybe?)
Have a look at the BWMGR qos product. They have some interesting thoughts.
Basically their idea seems to be that you only need to get the window shaping (or ACK shaping) roughly right. The fine tuning happens just as now with the queue simply filling up a little. Seems to me that this is right, if you just get the window even +/- 50% of the target bandwidth then you can do fine tuning by delaying ACK and buffering data. The trick is basically to avoid the huge splurge of data during slow start which can cause queuing on the ISP end.
Otherwise I am broadly speaking very happy with the default QOS. It's just this queueing which occurs when a bunch of connections all start together which is the problem. This isn't really just a bittorrent issue though because a busy webserver would likely see the same conditions?
Are we all on the same page as to what the problem is? Any more thoughts on how to tackle it? I'm still not convinced that delaying ACK's is really any better than the current option to buffer incoming data. I guess the receiving machine TCP stack gets it earlier so the app looks more responsive, but other than the lower lag I don't see much difference really?
Curious to hear how your project gets on though! Please keep us informed!
Ed W
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
