Help with bandwidth % for ACK queues with Asymetric internet

[jhabers]

I have taken a look at that excel sheet and just cant wrap my head around it. Can anyone give me good numbers to put in for a 6M/500K and a 6M/384K lines?  I am getting drops in my Voip queue that I think is because its not taking into account asymetrical speeds.

Thanks :)
Jon

right now my office queues look like this (this is where I am getting drops on the VoIP):

Flags Priority Default Bandwidth Name 
    0  No  500 Kb    qwanRoot     
    0  No  6000 Kb    qlanRoot     
    1  Yes  1 %    qwandef     
    1  Yes  1 %    qlandef     
ACK    7  No  25 %    qwanacks     
ACK    7  No  25 %    qlanacks     
    7  No  25 %    qVOIPUp     
    7  No  25 %    qVOIPDown

[dusan]

@jhabers:

I have taken a look at that excel sheet and just cant wrap my head around it. Can anyone give me good numbers to put in for a 6M/500K and a 6M/384K lines?  I am getting drops in my Voip queue that I think is because its not taking into account asymetrical speeds.

Thanks :)
Jon

right now my office queues look like this (this is where I am getting drops on the VoIP):

Flags Priority Default Bandwidth Name   
    0   No  500 Kb    qwanRoot       
    0   No  6000 Kb    qlanRoot       
    1   Yes  1 %    qwandef       
    1   Yes  1 %    qlandef       
ACK    7   No  25 %    qwanacks       
ACK    7   No  25 %    qlanacks       
    7   No  25 %    qVOIPUp       
    7   No  25 %    qVOIPDown

As for ACK queue sizing, you would probably need to look at the result table
http://forum.pfsense.org/index.php/topic,2484.msg42645.html#msg42645

Since 6M/500K = 12 and 6M/384 = 16, rows 12 and 16 fit your needs.

Your VoIP is probably UDP so qWANack does not matter. qVoIPUp does. So, in addition to Bandwidth, try to setup a real-time queue with m1 = 200 kb/s, d = 6 ms, m2 = 25% and see if it's any better.

[jhabers]

Thanks dusan, dumb question but for the values you gave me for the ack queues, do i put those nubers in the real time m2 or in the bandwidth for the queue (the one at the top)

Thanks
Jon

[dusan]

@jhabers:

Thanks dusan, dumb question but for the values you gave me for the ack queues, do i put those nubers in the real time m2 or in the bandwidth for the queue (the one at the top)

That's not a trivial problem.

1. Actually, the numbers say that for 6M/384K ACK packets occupy 63.15% (or 51.28% if you believe in formulas) of uplink if uplink and downlink are both saturated by TCP only. (The underlying model is robust enough to cover virtually all TCP protocols so there are no needs to care about the specific TCP protocols in use.) In reality, however, there are UDP, ESP and other traffics which may reduce the ACK queue size requirements. It would be therefore reasonable if you start at about 40% and increment it a bit in case of need.

2. Real-time curve protects queue's bandwidth better. But real-time bandwidth is a resource that should be allocated very carefully. So, don't use the entire 40% of real-time bandwidth for the qWANack. Rather, set qWANack linkshare's m2 (i.e. the Bandwidth) = 40% and real-time's m2 = 5-10%.

3. The rest (70-75%) of real-time bandwidth should be allocated to other traffics, again, with great care. Therefore, for the most bandwidth demanding traffic (VoIP) I've recommended to try with 200 kb/s = 52%.