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    0
    

    Reading 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    0
    

    Nest 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  415
    

    Any 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   93
    

    Help! 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?

    @rnmixon:

    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   93
    

    Help! 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    0
    

    I 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    0
    
    

    I'm attaching a screen clip of the floating rules (could not figure out how to filter from "pfctl -vvsr").

    Any other ideas?