FLAWLESS VoIP w/ Saturated Download - No Wasted Bandwidth!!
-
No ACK queue. For qVoIP{up,down} queue set m1 = 120Kb d=30 m2 = 75Kb
Easy enough. I assume that m1/d/m2 are located in the "realtime" Service Curve, not one of the others (upperlimit, link share)?
Can you please tweak the qlimit also of q{Wan,Lan}root and qVoIP{up,down} queue to something like 50 +-20% instead of 500.
Where can I make the change for qlimit? I did a quick search of the forums for "qlimit" and didn't see where I might be able to change that. It is not located in the GUI (that I can tell). I've hand edited /cf/conf/config.xml, but that file seems to be rebuilt by some other process. I looked at all of the files in /tmp, but none of them have a "qlimit" value either.
Which parent file can I edit to adjust the qlimit? When I know this, I can attempt these suggestions. Thanks again for your help.
-
Please set even m1 = m2 on the q{Wan, Lan}root queue.
After re-running the traffic shaper, there are no values for m1 or m2. All that are in this screen are:
Scheduler Type HFSC
Bandwidth = 800Kb (or 1200Kb for qwanRoot)
Priority = 0
name qlanRoot (or qwanRoot)
Scheduler Options: "This is a parent queue"(Also see attached .jpg for qwanRoot)
All other values are blank. Should I be populating m1 and m2? What value should I use?
-
Get a backup of your config after creating the configuration i told you.
You can get a backup from System->Backup or something similar.Edit that file and restore it back on the section where you got the backup.
This should allow you to make the changes made by hand to the config.xml be respected by pfSense.
And yes, i am talking about realtime specifications.
Try this and let me know.
Edit: Yeah you should fill them yourself. But for q{Wan, Lan}root this modifications should be done to the linkshare curve.
-
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.
