P2P traffic not going into P2P queue
-
These values don't affect the statelimit. Btw, you can see historical logs of states at status>rrd graphs, system, states (if running a more recent snapshot). This graph was added some time ago.
-
These values don't affect the statelimit. Btw, you can see historical logs of states at status>rrd graphs, system, states (if running a more recent snapshot). This graph was added some time ago.
hmm, i don't seem to have that graph, i'm running the latest stable version: "1.0.1
built on Sun Oct 29 01:07:16 UTC 2006"what do those values do then? they won't 'grab' states, because of priority, from the ones that are being used by P2P?
i'll check my states tonight, but i'm 99% sure my states were at the limit, i seem to recall that they might've even went over by a couple at times.
-
This version doesn't have this graph. Just bump up the states to a higher value and check when your bt traffic started going. If you then see more than 10000 states used it most likely was your problem. The values if the trafficshaper only affect the bandwidth that is assigned to a queue but not the amount of states causing it.
-
Sounds good, I'll post back about how it went, thanks again hoba. you've been very helpful
-
ok i'm back home and tried downloading a torrent, however, the torrent wasn't busy enough and didn't fill up my states so my surfing was fine… i think you were right about the problem of me running out of states, i think that's when my http traffic goes to sh1t. i will report back once i can do a proper test with a busy torrent.
-
hi hoba,
well, it seems like the states thing wasn't the problem. I think the problem is that my qOthersDownH queue starts getting a lot of drops when th qP2PDown queue starts heating up… and therefore i think this causes all the delay on my http traffic. Again, this only happens when the torrent is really busy, any suggestions??
thanks
-
What does your ack queues look like when under load? Try bumping up the ack queue a few percentages. Acks shouldn't get dropped if possible.
-
my ack queues look fine under load… but i'll have another look tonight, i know my qwanacks queue is fine. not too sure how my qlanacks is, I remember that I bumped the qlanacks queue too much once and it choked everything so I had to bring it back down.
-
yep, my ack queues were fine… my states were fine, like under 5000 the only thing that looked out of the ordinary was that the qOthersDownH queue had quite a few drops, like about 100 something...
-
well, i tried moving the http rule to the top of the rule list… maybe that will make a difference... the P2P catch-all rule as at the bottom
-
hoba,
I seem to have run into that slow down again tonight, what seems to be happening is my qOthersDownH queue doesn't seem to want to 'take' the bandwidth away from my qP2PDown queue when it's maxed. Like it's being blocked or something, it doesn't want to take it's percentage of the bandwidth… any suggestions?? thanks again
edit: it seems when I reload my rules/queues it seems to clear up the 'blocking'.... like, the shaper works without hiccups when I reload the queues during a P2P download.
-
hoba,
I seem to have run into that slow down again tonight, what seems to be happening is my qOthersDownH queue doesn't seem to want to 'take' the bandwidth away from my qP2PDown queue when it's maxed. Like it's being blocked or something, it doesn't want to take it's percentage of the bandwidth… any suggestions?? thanks again
edit: it seems when I reload my rules/queues it seems to clear up the 'blocking'.... like, the shaper works without hiccups when I reload the queues during a P2P download.
Are you using miniupnp by chance?
-
-
Just checking.
-
Any more ideas on this one?
I'm having similar troubles, although possibly not in the usual way that one would expect to use the connection.
I have people downloading some pretty hefty files from me, but when that's not the case, I'd like BT to be using the upstream connection as best it can. I'm using μtorrent, it's set to use just one port, and I've currently got the scheduler set to ensure that there is some bandwidth available when I'm actually home and want to use the connection, as I can't seem to get the traffic shaper function the way I desire.
I'm quite willing to admit that I could well be being dim, and it's doing exactly what it's designed to do, I just haven't configured it correctly.
I've altered the qP2PUp and qP2PDown rules accordingly to reflect the port that μtorrent is targeted at, I've placed them at the top of the rules list, so there should be nothing stopping the traffic getting identified appropriately, and I've lowered the queue priorities and realtime bandwidth as much as is possible.
My problem is thus: I have a max upstream b/w of approx 55kB/s, and I've got μtorrent restricted to 50kB/s, yet when someone starts an HTTP download from me, I would expect μtorrent to grind to a halt, and ~55kB/s to be achieved, especially when using a multi-threaded download client, however μtorrent still maintains about a 30kB/s upload speed.
I'm open to both chastisement for being dim, and suggestions as to a solution if I'm not
What have I missed?!? -
@The:
Any more ideas on this one?
Many commercial router vendors said that it's impossible to bandwidth limit encrypted P2P traffic. Only one router vendor claims that they can limit encrypted Bittorrent & Obfuscated eMule traffic (don't remember the company name). I've been using MikroTik RouterOS from the beginning, and since some P2P clients implemented encryption, it's now only possible to block the encrypted traffic. I asked the MikroTik vendor and they said that it's impossible to bandwidth limit encrypted P2P traffic.
This problem forced me to add rules for all normal traffic, and one for the rest (unknown traffic).