P2P traffic not going into P2P queue
-
Hi, I've got all the rules for my traffic shaping set up with the right ports and everything, but for some reason BitTorrent traffic that's supposed to be going into the P2P queue goes into the default queue. Any advice?
-
Use the Catchall-Option for P2P when runing the Wizard. Some Clients use random ports or fall back to other well known ports.
-
I know the ports of my bittorrent clients (22182 and 18253.) They've been added into the traffic shaper config yet are still being fed into the P2P queue… and I'd rather not use p2pcatchall on the off chance that someone uses an unrecognized protocol that gets mixed in with the P2P traffic.
-
You probably have to reset states after changin trafficshaer configuration. Queues are assigned on initiating traffic, so if you want to completely apply a new ruleset to already established links you need to reset states.
-
Already done that. For some reason a little bit's going into the P2P queue but most seems to go into the default queue. Looking at the state table most is coming from my IP, 192.168.1.50:22812 but it doesn't seem to be shaped.
-
If the oposite end listens on port 80 or something else it might get caputured by one of the other rules. Rules are applied on a first match basis. Maybe you need to reorder some rules.
-
Most bittorrent clients use the specified ports for inbound connections only, outbound connections end up going out on random ports. The catchall is very useful for catching all the outgoing connections that aren't on your specified ports.
-
when you're using bittorrent, should the qwanacks queue go up a bit?
my qwanacks queue goes up to about 60Kb/s when i'm using bittorrent, the qP2PUp/Down queues seem to be catching all of the BT traffic though.
-
Every tcp traffic causes ACKs. As bittorrent causes quite a lot of connections it will cause some ACKs as well. This is normal.
-
Every tcp traffic causes ACKs. As bittorrent causes quite a lot of connections it will cause some ACKs as well. This is normal.
sounds good, that's what i expected, thanks hoba ;)
can I get in another quick question?
the traffic shaping seems to work great most of the time but sometimes i have the following problem, i'll start my torrent and then my web traffic will just not respond. but if i reload the filters the web traffic is fine and will be fine for the remainder of the torrent. this doesn't seem to happen all the time either. it looks like all queues are catching the right traffic. my http traffic is set to qOthersH (up/down) and right now it's got about 30% bandwidth. is there anything i can do to alleviate this??
sorry, turned out to be a pretty long question
-
Are you running out of states? At the statuspage how many states do you see there (should be something like x/10000). The default setting is 10000 states but you can raise this limit depending on RAM at system>advanced (nearly at the bottom of the page).
-
Are you running out of states? At the statuspage how many states do you see there (should be something like x/10000). The default setting is 10000 states but you can raise this limit depending on RAM at system>advanced (nearly at the bottom of the page).
oh, i didn't know that… what exactly are states? like the number of connections?
what will raising it do?edit: i have a P4 2.4 CPU and 512 RAM, how many states should I raise it to?
-
First check if you hit the limit at status>system. States are current connection, right. Unless you run a lot of packages or packages like snort you can savely bump the limit up to 20000 or 30000. Question is if that makes sense for your connection depending on speed.
-
First check if you hit the limit at status>system. States are current connection, right. Unless you run a lot of packages or packages like snort you can savely bump the limit up to 20000 or 30000. Question is if that makes sense for your connection depending on speed.
I think I do hit the limit when I do torrents. I'll try this tonight, would it help if I used those m1,d,m2 values in my qOthersHdown queue (the one that my HTTP rule is tied to)?
thanks so much for your help btw
-
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).