Problem with Qos and P2P traffic
-
Hello,
I'm trying for the last few weeks to setup a traffic shaping for p2p traffic.
The queues are perfectly detected but not dropping enough bandwidth.Here is a simple setup to try the issue:
LAN 4800kbit/s HFSC
–-------qLink Priority: 7 Default queue ECN Bandwidth: 99%
---------qP2P Priority: 1 Default queue ECN Bandwidth: 1%Anyone know why the queue qP2P still get close to max speed(90%) when qLink download something?
PS: Same bug for me: https://forum.pfsense.org/index.php?topic=73967.0
Config:
2.1-RELEASE (i386) nanobsd (1g)
Intel atom 330 - 1Go - 2 realtek cardsinternet-->modem--->pfsense--->server
Thanks.
-
Is there a way to drop a queue from full speed to very low speed very quickly?
Torrents with to many connections don't slow but with a few connections they slow down a lot.
Maybe a buffer problem from the nics?
-
I'm doing something wrong?
The ping go very high and lot off packet loss.
-
Packet loss is expected when you have drops from one queue to make bandwidth available to another queue. I have also struggled with HFSC for a few weeks. I finally gave up and switched to PRIQ on the advice of JimP. It's not very hard at all to make a few rules to move high-level traffic to the priority queue, and all else can go to the P2P queue.
-
From what I understand about PRIQ you can have the same thing happen as a higher priority queue gets processes ahead of a lower priority queue. So if your higher priority queues are always full then the packets for the lower queues get dropped.
I would be interested in seeing how you have the queues setup with PRIQ.
-
Yes, PRIQ can be harsh to lower queues, but unless you've got a link that's saturated much of the time and you don't need to guarantee a minimum service level for the low queues, it shouldn't be a problem in reality. In my config, I have only a few queues: VoIP is top (7), ACK next (6), HTTP/S, DNS and RTSP next (4), everything else last (3). I have a low queue configured with a limiter, but I don't use it. Having a default queue handle non-classified traffic is good enough for my needs at the moment.
-
I've tried with PRIQ, but same as before :(
The detection of the traffic type works just fine with HFSC and PRIQ
I've got LAN Side:
-
1% P2P
-
61% HTTP
-
20% ACK
-
4% Voip
-
4% Games
-
10% Other
In this configuration when there is only P2P, they get all the BW -> perfectly normal
But when there is P2P and HTTP, p2p still get all the BW if there is lot of connections(HFSC and PRIQ)BW download: 5000kbit/s
-
-
You could try setting a limiter for TCP traffic coming from your LAN similar to https://forum.pfsense.org/index.php?topic=63531.0
I did this in my setup and it does work. Does it limit all TCP streams , yes it does but at least it gets you a starting point to limit bandwidth and not let torrent's take it all.
-
But the problem is, I want the torrent to have full BW when there is no other DL.
The p2p traffic get drop a little, but still get all BW. Maybe it's impossible to do that?
-
Why are you applying the floating rule to the LAN interface? From what I understand of floating rules you dont want to apply them there.
-
To match the download traffic. I've got only 5Mbit/s.
I use pfsense for home usage that way:
internet->modem->pfsense->lanThe Upperlimit from HFSC Service Curve works fine.. i don't now why the bandwidth share doesn't.
-
I understand that you only have 5Mbit of download but for Floating rules I think you want to select the WAN interface not the LAN. Maybe try that and see if it makes a difference?
-
Because the WAN side have no LAN ip address, i need to match a LAN ip address and not port. The only way is to put the floating rule on the LAN side.
-
You dont have the quick option checked on the rules. Have you done that? If you do not have that option checked it still processes the rest of the rules.
-
I've try but nothing change.
-
sorry i can't be of more help. I dont worry about P2P in my setup as I have the limiter defining a hard set bandwidth that all TCP streams share equally. I dont care if it is P2P or straight HTTP download , they only get x% of the bandwidth to share among all the clients requesting it.
I would search this forum and others to see what other people have tried.
-
Are you really on 2.1? You might want to consider upgrading to current. No use wasting time trying to work with a bug that may have already been fixed.
I also noticed that you have drops on your P2P queue but not many others. This shows me that your other queues are getting higher priority as expected. Sideout is right in that your floating rules shouldn't target a particular interface. That's what makes them floating rules.
Did you go through the wizard or did you build your queues manually?
-
Thanks sideout for your help!
I've this version:
2.1.2-RELEASE (amd64)
built on Thu Apr 10 05:42:41 EDT 2014I create the rules via the wizard then change manually some speed settings.
-
I am on 2.1.3 built on May 10th.
-
I will try to do it again via the wizard and see what append.
