AF> Do you know roughly how many active connections you have?
Up to 30K.
I think this could be the problem - If 30k connections all tried to send through 4mbit then a quick prod at xcalc tells me that each would get to send 1 1500 byte packet every 90 seconds.
However I just found propably reason of issue...
As p2p is both direction transfer most of it sends large ACK packets. After short investigation there are some facts:
1) 40% of p2p ACK packets have payload larger than 1KB, other are regular ACKs
2) 15% of all other traffic ACKs are longer than 1KB, 85% are regular ACKs.
Maybe - depends how you are testing, remember that all tcp packets have ack set after the initial handshake.
I know p2p like bittorrent does use a single connection in full duplex , but I never noticed it hurting upstream shaping - it does make downstream more bursty as the empty acks can get sent ahead of the piggybacked ones stuck in the queue and ack a large chunk of data.
I have priority class only for regular short ACKs, so other goes to custom p2p class. Cause ACKs have to be send after receiving some data propably that's why I can't slow down traffic to defined value. Every time customer receive p2p data, sends LARGE ACK. Outcome is that shaping p2p upload have impact on p2p download and vice versa or in other words, to shape upload, shape download also. Giving extra prio for large ACKs would be suicide. I suppose the only way to shape p2p is to dominate it by hard limits [up/down].
Please correct me if it's fake [and give an advise ;)].
Maybe limiting the number of connections per user would be best - if you can.
Andy.
_______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
