FLAWLESS VoIP w/ Saturated Download - No Wasted Bandwidth!!
-
To explain even better:
1- calculations of realtime service curve should only be applied to qVoIP{up,down}
2- m1 = m2 should only be applied to q{Wan, Lan}root linkshare service curve. -
m1 = m2 should only be applied to q{Wan, Lan}root linkshare service curve.
What values should I place in here? Am I using the same values for the q{Wan, Lan}root "Bandwidth" section, ie: m1=m2=1200Kb for qwanRoot, and m1=m2=800Kb for qlanRoot - or is there some other value to be placed here?
-
To explain even better:
1- calculations of realtime service curve should only be applied to qVoIP{up,down}
2- m1 = m2 should only be applied to q{Wan, Lan}root linkshare service curve. They should be equal to the bandwidth specification on the queue and make d = 200.
3- qlimit to all of the queues or at least those mentioned here -
hidden any luck with this?!
-
According to this source http://www.dslreports.com/forum/remark,10277184
the Vonage adapter may need more bandwidth: at least m2 = 87.2 kb/s and m1 = 174.4 kb/s (for D=10 ms). -
Thanks for all of the suggestions. That seemed to help quite a bit. If I set my root values to 1000 or 1100Kb, then the VoIP has acceptable quality. Setting it at 1200Kb is still a little choppy.
Unfortunately, one of these settings has caused some adverse side effects:
1.) some VoIP call-setup doesn't work and I get fast busy
What's the ETA for a build with the "new" shaper? Any other suggestions?
(Edit: webpage issue removed - unreleated to traffic shaping).
-
1.) some embedded images in webpages don't show up (server timeout, etc.)
2.) some VoIP call-setup doesn't work and I get fast busyWell can you tell me the settings you used?!
For 1200Kb that's normal if you're on DSL since you don't get it all.
So it seems that qlimit does it for you. I would suggest to increase the qlimit for the q{Wan, Lan}root as i said by 20 or even 30% and of the queue where http traffic goes.
To fix the webpages get back the qACK on both WAN and LAN and set its realtime to 100ms with a m2 of 20% for each of them. This should get back your web pages.One downside of the shaper in 1.2 is that you cannot control the qlimit and tbr of the tocken bucket which would give you the perfect setup for your environment.
Try to increase the m1 and m2 with what dusan suggested or if you don't mind some more to get propper quality and bandwidth. You can even try to increase the latency to some more since it seems you have a higher latency on your line. You can be safe till 50ms that is VoIP upperlimit on average.This is to give you a better setup on current pfSense. I am working on finishing it and even waiting for the bounty people to complete thier commitement so i cannot give a ETA for that, sorry.
-
According to this source http://www.dslreports.com/forum/remark,10277184
the Vonage adapter may need more bandwidth: at least m2 = 87.2 kb/s and m1 = 174.4 kb/s (for D=10 ms).I'm currently using Vonage 90 codec. When you say "at least", would that mean that using values higher than M1=87.2Kb and M2=174.4Kb should reserve more bandwidth for VoIP? Like I've mentioned before, I would love it if I could slow <everything>down while I'm on a VoIP call… wasted bandwidth during the call is completely acceptable and is exactly what I want to do. If that is the case, could I just use M1 & M2 numbers of 512Kb? </everything>
-
I would suggest you to reread the thread where ACK for HFSC queue is being discussed, the first thread on the sticky tags.
Then get an idea of what it means to have that high bandwidth.
But the safer bet it experimenting different values. You can get some more complex with upperlimit too but just read that and ask what you do not understand.
-
Well can you tell me the settings you used?!
I need to take a step back. When I restored the settings after hand-editing the config.xml, the pfSense box reloaded and my snort scripts were in the startup director (explains the great call quality).
Now that I have that disabled, here's the current status:
no ACk queues
qlanRoot/qwanRoot = 1000/800 (with linkshare set for m1 1000, d 200, m2 1000)
qVOIPUp/qVOIPDown = 25% Bandwidth, prio 7, Realtime M1 240Kb, d 30, m2 240Kb
qlimits on all the queues = 50 (default, voip, p2p, etc.)Still choppy voice. I'll read some more about the HFSC & ACK Queues as you've suggested. I'm about ready to throw in the towel and add $100 to the bounty to get the new shaper out. ;) I'll let you know what I come up with.
-
According to this source http://www.dslreports.com/forum/remark,10277184
the Vonage adapter may need more bandwidth: at least m2 = 87.2 kb/s and m1 = 174.4 kb/s (for D=10 ms).I'm currently using Vonage 90 codec. When you say "at least", would that mean that using values higher than M1=87.2Kb and M2=174.4Kb should reserve more bandwidth for VoIP? Like I've mentioned before, I would love it if I could slow <everything>down while I'm on a VoIP call… wasted bandwidth during the call is completely acceptable and is exactly what I want to do. If that is the case, could I just use M1 & M2 numbers of 512Kb?</everything>
In the realtime curve, every bandwidth requirement like m1 and m2 imply a delay requirement and to set it to higher value simply means to require lower delay. Actual delay in the worst case, however, cannot be guaranted to be shorter than link delay, which is the time needed to complete previous transmission request. For 1200 kb/s link with MTU = 1.5 kB = 12 kb, the link delay is not larger than 12/1200 = 0.01 s = 10 ms. By requiring lower delay (e.g. 1 ms), you won't get an absolute guarantee but you'll have higher chance that the actual delay will be short.
Requiring high real-time bandwidth does not mean wasting the link's bandwidth. Regardless of what m1 and m2 you specify, your codec always runs at constant bitrate of 87.2 kb/s (that's why is is named Vonage 90). The rest of bandwidth is allocated to other traffics.
-
One simple question:
Did you remove realtime specification from the other queues?! -
According to this source http://forums.whirlpool.net.au/forum-replies-archive.cfm/331189.html
there maybe also two problems.- Bad queue length limit. Beside previously mentioned 'qlimit' there may be other (hardware) queue length limits that may need tweak:
-
in pfsense machine's WAN NIC. Optimum may be 50-70.
-
in switch, if VoIP adapter is connected to pfsense machine through a switch. The best solution is to reconnect the adapter to pfsense machine directly.
- Bad packet fragmentation. Beside tweaking MTU, I don't know if there are other means to control fragmentation. For slow uplink (< 1200 kb/s) fragmentation may need tweak by reducing MTU in pfsense's WAN NIC. The default MTU (not counting Ethernet overhead) is 1500 bytes, which is optimal for normal data (web etc.) traffic. For the Vonage 90 the optimal is 200 bytes. One may need to choose a compromise between them.
-
You don't need to do 2) with altq since there is a tocken bucket which may compensate the MTU problems.
While to me 2) is somewhat 'ridiculously strange' ALTQ provides the means for it and according to my knowledge that is a problem with modern drivers which try to burst aggressively.
The shaper in pfSense 1.2 does not allow for this so you cannot tweak it.For 1) i cannot say other than drop the adapter and use some form of software VoIP client. Getting down to such details is somewhat paranoid behaviour so please do not scare people in such ways :). Though, it is true that enterprise class hardware and home users ones do really have 'big' differences.
-
Ok here is another one to try, slightly different setup!
qlanRoot: linkshare 1024Kb/s (this is parameter m2 no bandwidth set, if you can set m1 = 0 and d to your link latency might help).
qwanRoot: linkshare 800Kb/s (this is parameter m2 no bandwidth setif you can set m1 =0 and d to your link latency might help).
qVoIP{up, down}: linkshare( m1 = 1.3Kb, d = 5, m2 = 120Kb ) realtime( m1 = 1.3Kb, d = 5, m2 = 120Kb )
qACK{up, down}: linkshare(m1=500b, d = 100, m2 = 25%) 'it is b == bits/s
on the other queues do whatever you want just don't set realtime paramter.Can you please test this, i am very interested in your results and this might save you 100$ :).
-
Anybody tried this?!
-
Im watching this thread with great interest. If I get time Ill try it when I get home.
Im a voip system tester so have a few lines coming in here.
-
qlanRoot: linkshare 1024Kb/s (this is parameter m2 no bandwidth set, if you can set m1 = 0 and d to your link latency might help).
qwanRoot: linkshare 800Kb/s (this is parameter m2 no bandwidth setif you can set m1 =0 and d to your link latency might help).
qVoIP{up, down}: linkshare( m1 = 1.3Kb, d = 5, m2 = 120Kb ) realtime( m1 = 1.3Kb, d = 5, m2 = 120Kb )
qACK{up, down}: linkshare(m1=500b, d = 100, m2 = 25%) 'it is b == bits/s
on the other queues do whatever you want just don't set realtime paramter.Can you please test this, i am very interested in your results and this might save you 100$ :).
Sorry, I've been busy for the last few days. I'll try and get to this sometime today. I'll post back with the results. Thanks!
-
qlanRoot: linkshare 1024Kb/s (this is parameter m2 no bandwidth set, if you can set m1 = 0 and d to your link latency might help).
qwanRoot: linkshare 800Kb/s (this is parameter m2 no bandwidth setif you can set m1 =0 and d to your link latency might help).
qVoIP{up, down}: linkshare( m1 = 1.3Kb, d = 5, m2 = 120Kb ) realtime( m1 = 1.3Kb, d = 5, m2 = 120Kb )
qACK{up, down}: linkshare(m1=500b, d = 100, m2 = 25%) 'it is b == bits/s
on the other queues do whatever you want just don't set realtime paramter.qlanRoot/qwanRoot results
First off, if I set Bandwidth = (blank) and Linkshare = 1024Kb/800Kb, filter errors occur:There were error(s) loading the rules: /tmp/rules.debug:13: syntax error/tmp/rules.debug:16: queue qwanRoot has no parent /tmp/rules.debug:16: errors in queue definition /tmp/rules.debug:18: queue qwandef has no parent /tmp/rules.debug:18: errors in queue definition /tmp/rules.debug:20: queue qwanacks has no parent /tmp/rules.debug:20: errors in queue definition /tmp/rules.debug:22: queue qVOIPUp has no parent /tmp/rules.debug:22: errors in queue definition pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [13]: altq on xl0 hfsc bandwidth queue { qwanRoot }…
If I set Bandwidth = 0 and LInkshare = 1024Kb/800Kb, then I lock myself completely out of the pfSense box. I had to un-rack it, reset to factory defaults, and re-run through the configuration wizard. ???
qVOIPUp/Down results
Realtime m1 = 2Kb, D = 5, and m2 = 120Kb I get the following error:There were error(s) loading the rules: pfctl: m1 must be zero for convex curve: qVOIPUp/tmp/rules.debug:23: errors in queue definition pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [ m1 must be zero for convex curve]: …
If I remove realtime m1 and d, and leave 120Kb for m2 then the filter loads properly.
If realtime m1 = 0Kb, d=50, and m2 = 1024Kb then I receive the following error:
There were error(s) loading the rules: pfctl: linkshare sc exceeds parent's sc/tmp/rules.debug:19: errors in queue definition pfctl: linkshare sc exceeds parent's sc /tmp/rules.debug:21: errors in queue definition pfctl: linkshare sc exceeds parent's sc /tmp/rules.debug:23: errors in queue definition pfctl: linkshare sc exceeds parent's sc /tmp/rules.debug:25: errors in queue definition pfctl: linkshare sc exceeds parent's sc /tmp/rules.debug:27: errors in queue definition pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [ linkshare sc exceeds parent's sc /tmp/rules.debug]: …
Next, if Realtime m2 = 120Kb, and Linkshare m1 = 2Kb, d=5, m2=120Kb then:
There were error(s) loading the rules: pfctl: m1 must be zero for convex curve: qVOIPUp/tmp/rules.debug:23: errors in queue definition pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [ m1 must be zero for convex curve]: …
qwan/lan acks results
If I use Linkshare m1=2Kb, d=5, m2=120Kb I receive:There were error(s) loading the rules: pfctl: m1 must be zero for convex curve: qwanacks/tmp/rules.debug:20: errors in queue definition pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [ m1 must be zero for convex curve]: …
If I use Realtime m1=2Kb, d=5, m2=120Kb I receive:
There were error(s) loading the rules: pfctl: m1 must be zero for convex curve: qwanacks/tmp/rules.debug:20: errors in queue definition pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [ m1 must be zero for convex curve]: …
It looks like Realtime can only have m2 value, nothing for m1/d
Further, if I use a combination of Realtime m2=120Kb, and then Linkshare m1=2Kb, d=5, m2=120Kb I receive this error:
There were error(s) loading the rules: pfctl: m1 must be zero for convex curve: qwanacks/tmp/rules.debug:20: errors in queue definition pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [ m1 must be zero for convex curve]: …
By the way, 1.2Kb is not allowed, nor are "bits" an option in the GUI (thus, the reason why I used 2Kb instead).
The snort option (http://www.xmission.com/~hidden/aatqos/) looks a lot easier than this so far. ;D
It goes without saying that due to all these errors, I am unable to "test" anything. Any other ideas? Thanks again for all your help.
-
Those are all pfctl problems i will post a link to a pfctl which doesn't have these problems so you can test it again, if you want to do that.
From my testing this configuration is the way to go but seems PF guys have misunderstood some things about HFSC.
Btw, thanks for your help on this. I just want to test it as much as possible so on 1.3 you just need the wizard and get done.
qlanRoot/qwanRoot results
First off, if I set Bandwidth = (blank) and Linkshare = 1024Kb/800Kb, filter errors occur:There were error(s) loading the rules: /tmp/rules.debug:13: syntax error/tmp/rules.debug:16: queue qwanRoot has no parent /tmp/rules.debug:16: errors in queue definition /tmp/rules.debug:18: queue qwandef has no parent /tmp/rules.debug:18: errors in queue definition /tmp/rules.debug:20: queue qwanacks has no parent /tmp/rules.debug:20: errors in queue definition /tmp/rules.debug:22: queue qVOIPUp has no parent /tmp/rules.debug:22: errors in queue definition pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [13]: altq on xl0 hfsc bandwidth queue { qwanRoot }…
If I set Bandwidth = 0 and LInkshare = 1024Kb/800Kb, then I lock myself completely out of the pfSense box. I had to un-rack it, reset to factory defaults, and re-run through the configuration wizard. Huh
this might be a shaper rule generation error.
