Trying to get PRIQ working on 2.2.6 in Hyper-V
-
It looks like the Hyper-V support will not improve soon so HFSC shaping is not going to happen - but getting PRIQ to work as suggested on the Virtualization forum is not working so hot. It's turned a 50/5 broadband connection into a 9/4. We get great VOIP QOS, but everything else sucks.
Background: Right or wrong we need to run in Hyper-V. We actually have two of the 1U Atom C2758 systems. Each runs Hyper-V 2012 R2 (no GUI) with three VMS: pfSense, FreePBX and a small CentOS 7 instance running outbound Postfix. Hyper-V replication keeps the second 1U server ready as a (relatively) warm backup appliance.
Anyway our broadband connection is consistently tested at or above 50 Mbps down and 5 Mbps up. In the traffic shaper we choose 48 and 4.8 for the bandwidth limits and ask that 1.2 Mbps be reserved for VOIP traffic up and down.
I'm attaching a sequenced set of screen shots in case that puts some context to this. I.e. the images start with "01_" are status and speed tests without traffic shaping, the ones starting with "02_" are the steps through the traffic wizard and the "03_" images are the status and speed tests after the wizard has completed.
Can anyone see what we are doing wrong? What other information might help understand this?
Thanks in advance - Richard
-
Check your queue sizes? They default to 50, which is many times undersized.
-
Do you mean "Queue Limit" (in # packets)? I don't see a queue size. Here's a snapshot of the WAN qDefault queue.
Thank you!
-
Here are the results from monitoring the queue with pfTop, started just after I turned on an Traffic Shaping (using above steps) with PRIQ) and then ran a speed test. A"lot" of packets seem to be dropped in the qDefault and qLink queues, I guess not surprising given the download results.
pfTop: Up Queue 1-6/6, View: queue, Cache: 10000 12:52:30 QUEUE BW SCH PR PKTS BYTES DROP_P DROP_B QLEN BORR SUSP P/S B/S qACK priq 6 0 0 0 0 0 0 0 qDefault priq 3 25619 12M 230 296609 0 100 20K qVoIP priq 7 34 19020 0 0 0 0 0 qLink priq 2 29319 22M 82 83297 0 101 36K qACK priq 6 0 0 0 0 0 0 0 qVoIP priq 7 43 19375 0 0 0 0 0Reading up there is a good bit of warning to be sure and provide enought bandwidth to the WAN qACK queue but those seem OK.
I then changed priority on qDefault/qLink from 3 and 2, to 5. The results are not that different and speed test is still only about 8 to 9Mbps down and 3+ Mbps up.
pfTop: Up Queue 1-6/6, View: queue, Cache: 10000 13:00:47 QUEUE BW SCH PR PKTS BYTES DROP_P DROP_B QLEN BORR SUSP P/S B/S qACK priq 6 0 0 0 0 0 0 0 qDefault priq 5 25898 15M 292 328088 0 84 15K qVoIP priq 7 28 15654 0 0 0 0 0 qLink priq 5 28392 21M 83 94014 0 86 33K qACK priq 6 0 0 0 0 0 0 0 qVoIP priq 7 35 15403 0 0 0 0 0Nest changed Queue Limit (packets) on qDefault/qLink from 50 (default) to 2000. The drops on qDefault went away, and the drops were reduced on qLink , but no improvement on download speeds:
pfTop: Up Queue 1-6/6, View: queue, Cache: 10000 13:04:40 QUEUE BW SCH PR PKTS BYTES DROP_P DROP_B QLEN BORR SUSP P/S B/S qACK priq 6 0 0 0 0 0 0 0 qDefault priq 3 30594 19M 0 0 0 186 60K qVoIP priq 7 25 14026 0 0 0 1.0 506 qLink priq 2 29647 22M 28 33742 0 164 48K qACK priq 6 0 0 0 0 0 0 0 qVoIP priq 7 32 14110 0 0 0 1.0 415Any ideas?
-
Just FYI, you can't use PRIQ with the same priority on two queues. I'm surprised you were able to change two queues to '5'. Make them all different (between 1-7) and re-test.
-
Somewhat related to moikerz concerns; the complete lack of traffic through the *ACK queues is alarming and seems to say you might have some firewall rules that need tweaking.
-
moikerz and Nullity -
It will be the weekend before I can try those suggestions but thanks. I'll report back
And of course I also just found the February Gold webinar on PRIQ, not sure how I missed that.
-
I just tried several different configurations with the wizard and PRIQ:
-
Just prioritizing VOIP (pretty much what my initial post showed with the screen shots).
-
Proritizing VOIP, plus increased priority on HTTP and decreased priority on SMTP - an example from the February gold webinar
No improvement either way. Then taking moikerz point about my having set qLink and qDefault to the same priority (6), I tried setting them to 4 and 5 (and then 5 and 4) instead of the default 2 and 3. No improvement at all.
Looking at the firewall rules here's a summary of what I have:
-
53 NAT rules (4 disabled) with auto-created firewall rules on the WAN interface. The only thing slighly unusual is a PPTP on port 1723 and a PPPT GRE rule.
-
Firewall LAN only has 3 rules, the lockou rule and default IPv4 and IPv6 rule
-
Floating just has the two rules for the voip queue (see attachment).
The output from pftop still shows nothing in the aACK queues:
pfTop: Up Queue 1-6/6, View: queue, Cache: 10000 13:11:16 QUEUE BW SCH PR PKTS BYTES DROP_P DROP_B QLEN BORR SUSP P/S B/S qACK priq 6 0 0 0 0 0 0 0 qDefault priq 3 181K 72M 1249 1466K 0 595 93K qVoIP priq 7 1407 789K 0 0 0 0.2 102 qLink priq 2 170K 70M 228 274913 59 955 1M qACK priq 6 0 0 0 0 0 0 0 qVoIP priq 7 1840 777K 0 0 0 0.4 93Help! What am I missing … or what additional output can I provide to help figure this out?
Thank you - Richard
-
-
Bump. It's been a week, can anyone suggest what else to look at to better understand what's causing this to perform so poorly?
I just tried several different configurations with the wizard and PRIQ:
-
Just prioritizing VOIP (pretty much what my initial post showed with the screen shots).
-
Proritizing VOIP, plus increased priority on HTTP and decreased priority on SMTP - an example from the February gold webinar
No improvement either way. Then taking moikerz point about my having set qLink and qDefault to the same priority (6), I tried setting them to 4 and 5 (and then 5 and 4) instead of the default 2 and 3. No improvement at all.
Looking at the firewall rules here's a summary of what I have:
-
53 NAT rules (4 disabled) with auto-created firewall rules on the WAN interface. The only thing slighly unusual is a PPTP on port 1723 and a PPPT GRE rule.
-
Firewall LAN only has 3 rules, the lockou rule and default IPv4 and IPv6 rule
-
Floating just has the two rules for the voip queue (see attachment).
The output from pftop still shows nothing in the aACK queues:
pfTop: Up Queue 1-6/6, View: queue, Cache: 10000 13:11:16 QUEUE BW SCH PR PKTS BYTES DROP_P DROP_B QLEN BORR SUSP P/S B/S qACK priq 6 0 0 0 0 0 0 0 qDefault priq 3 181K 72M 1249 1466K 0 595 93K qVoIP priq 7 1407 789K 0 0 0 0.2 102 qLink priq 2 170K 70M 228 274913 59 955 1M qACK priq 6 0 0 0 0 0 0 0 qVoIP priq 7 1840 777K 0 0 0 0.4 93Help! What am I missing … or what additional output can I provide to help figure this out?
Thank you - Richard
-
-
You have no floating rules to classify traffic into the queues, other than the two VOIP rules, which are UDP only. This is why your qACK is empty. (ACK only works for TCP). Your VOIP rules are fine as they are.
Try identifying your PRIQ WAN up/down, and VOIP bandwidth, in Kbps instead of Mbps. There are some reports floating around of problems with Mbps definitions.
Disable Explicit Congestion Notification on all queues. An incorrectly-configured or over-saturated upstream switch/router will play havoc with you.
As always, clear your state table after adjusting the traffic shaper.
And be sure you do not have a Limiter configured :P
-
moikerz,
Thank you - it took me until tonight to be able to re-test with your suggestions. I tested after each of the following steps:
-
Setting the bandwidth in Kbps - PRIQ 50000 down 5000 up; VOIP 1000 down 1000 up. Tested.
-
Reset state table. Tested.
-
Unchecked Explicity Congestion Notification on all queues, then reset state table. Tested.
In each case the bandwidth tests through speedtest.net show between 8Mbps down and 4+ Mbps up.
Here is the output from pftop:
pfTop: Up Queue 1-6/6, View: queue, Cache: 10000 21:16:42 QUEUE BW SCH PR PKTS BYTES DROP_P DROP_B QLEN BORR SUSP P/S B/S qACK priq 6 0 0 0 0 0 0 0 qDefault priq 3 87069 33M 126 133488 0 69 8168 qVoIP priq 7 28 17724 0 0 0 0 0 qLink priq 2 168K 81M 184 196856 0 242 94K qACK priq 6 0 0 0 0 0 0 0 qVoIP priq 7 56 29484 0 0 0 0 0I then ran through the shaper with the same settings as above, but enabling the "Raise or lower other Applications" page and giving Higher Priority to Http/Https and RDP traffic. With or without "Explicit Congestion Notification" checked we still get 8Mbps download and 4.3 Mbps upload. But we do see some traffic in teh qACK queues. Here is the pftop output at the end:
pfTop: Up Queue 1-10/10, View: queue, Cache: 10000 21:30:32 QUEUE BW SCH PR PKTS BYTES DROP_P DROP_B QLEN BORR SUSP P/S B/S qACK priq 6 2187 120K 0 0 0 37 2312 qDefault priq 3 24690 11M 60 85001 0 351 388K qVoIP priq 7 8 5064 0 0 0 0 0 qOthersHigh priq 4 2232 976K 0 0 0 23 8680 qOthersLow priq 2 0 0 0 0 0 0 0 qLink priq 2 52395 27M 136 194579 0 379 72K qACK priq 6 1975 111K 0 0 0 19 1168 qVoIP priq 7 16 8424 0 0 0 0 0 qOthersHigh priq 4 2519 2052K 0 0 0 54 64K qOthersLow priq 3 0 0 0 0 0 0 0I'm attaching a screen clip of the floating rules (could not figure out how to filter from "pfctl -vvsr").
Any other ideas?
-