Possible? When it detects a voip call, throttle everything else to 1%?
-
"I'm paying for 1gig/50mbps but I've never seen more than 30mbps up."
Why would you not call your isp if your not getting close to 50? If you pay for gig and it drops to 150… Dude I would be complaining!!! Until they fix it - or move...
-
"I'm paying for 1gig/50mbps but I've never seen more than 30mbps up."
Why would you not call your isp if your not getting close to 50? If you pay for gig and it drops to 150… Dude I would be complaining!!! Until they fix it - or move...
It's cable internet, they call it "up to" 1gig/50mbps so when I call and complain they say "you can pay $1300/mo for our dedicated fiber service, then you will get 1gig/1gig" lol :(
Voip seems to be working great if I throttle at 125mbps/20mbps and nobody is complaining so far so I'll keep it at that for now.
-Jamie M.
-
You can still complain. I have unlimited minutes and speakerphone on my cell phone. I'm willing to help keep their call center busy.
-
Tell your ISP you're going to send them "up to" the amount of money they request each month.
-
Still not working very well. I have to keep moving the speed down and down and down. I'm at 100mbps now :(
Is there absolutely NO way for the traffic shaping to detect the voip call and have it throttle everything else?
-Jamie M.
-
Still not working very well.
What does that actually mean? I don't see any drops in your voip queue.
Is there absolutely NO way for the traffic shaping to detect the voip call and have it throttle everything else?
Not automagically. All pfSense has to work with are IP addresses and ports. There is no built-in DPI stuff to figure out the app from the packet.
In my first reply to you, I mentioned that I use a dozen voip phones here in my office and I have no problems at all using the PRIQ shaper which doesn't care about bandwidth – only packet priority. I'm surprised you didn't follow up on that.
-
@KOM:
What does that actually mean? I don't see any drops in your voip queue.
It never shows any drops in the voip queue. The problems are latency so big my sip provider drops the connection (or my voip phones time out connecting to the sip server) so all of a sudden I get an voicemail e-mail from my sip provider but my phones never ring. The other problem is garbled audio of course. As soon as I pause my download the audio returns to flawless, unpause my download and audio goes to crap.
@KOM:
Not automagically. All pfSense has to work with are IP addresses and ports. There is no built-in DPI stuff to figure out the app from the packet.
It doesn't need DPI. As you can see from the screenshot above it already "knows" there's a voip call in progress. When it detects that, throttle all the other stuff way down.
@KOM:
In my first reply to you, I mentioned that I use a dozen voip phones here in my office and I have no problems at all using the PRIQ shaper which doesn't care about bandwidth – only packet priority. I'm surprised you didn't follow up on that.
I didn't believe packet priority would work in my case because it's being buffered at my ISP, not my modem (I assume). I'll investigate that option more and give it a try, thanks.
Someone sent me a script on here for OpenWRT x86 that will automatically throttle everything else when it detects a voip call, might give that a try.
-Jamie M.
-
@KOM:
In my first reply to you, I mentioned that I use a dozen voip phones here in my office and I have no problems at all using the PRIQ shaper which doesn't care about bandwidth – only packet priority. I'm surprised you didn't follow up on that.
PRIQ seems to be working much better, thanks! I have WAN and LAN set to PRIQ, qVoIP priority 15, qP2P priority to 0. Is it true that putting in bandwidth numbers or percentages does nothing with PRIQ? Freaky.
The only thing I'm finding with PRIQ is that http and https doesn't work well when downloading, DNS timeouts (DNS PROBE FINISHED NO INTERNET) or page loading timeouts mostly. In the traffic shaping wizard I set HTTP and DNS to "Higher priority".
-Jamie M.
-
Is it true that putting in bandwidth numbers or percentages does nothing with PRIQ?
Yes. The wizard is meant to support several different shapers in a one-size-fits-all manner, so some options don't apply depending on which shaper you're using.
The only thing I'm finding with PRIQ is that http and https doesn't work well when downloading, DNS timeouts (DNS PROBE FINISHED NO INTERNET)
Are you remembering to use UDP as well as TCP with your DNS floating rules?
-
@KOM:
Are you remembering to use UDP as well as TCP with your DNS floating rules?
It looks like the traffic wizard created both TCP and UDP floating DNS rules:
Maybe I need to increase the priority of qOthersHigh?
-Jamie M.
-
I don't know if that will help because the problem is weird. I have a 100/100 connection, and I can pound our link without upsetting the voip calls. How you're managing to do it with 1000/50 is a mystery to me.
Where's Harvy66 when you really need him? ;D
-
@KOM:
I don't know if that will help because the problem is weird. I have a 100/100 connection, and I can pound our link without upsetting the voip calls. How you're managing to do it with 1000/50 is a mystery to me.
Where's Harvey66 when you really need him? ;D
My 8 year old Netgear 3700 took a crap. Just got my new Ubiquiti AC Pro last night. Been keeping an eye on this discussion. Need to make time to look over the new info.
-
Can you show us what the traffic load looks like when you're having the issues, and also show us your "Quality" graph? Can you show us your current queue configuration on your WAN?
-
Can you show us what the traffic load looks like when you're having the issues, and also show us your "Quality" graph? Can you show us your current queue configuration on your WAN?
I just ran a test. Voip was horrible:
Started my download at 04:11.
All my phones were offline by 04:12.
They stayed offline until 04:23 and when they came back up they had bad voice quality.
They went back offline at 04:27 and stayed offline until my download finished (04:45) at which time they came back up with perfect voice quality.Graphs (hopefully this is what you asked for):
-Jamie M.
-
Is your test a TCP download? What are the priorities of your queues? Can you show Status/Queues during the test to make sure it looks like the expected traffic activity?
Also, could you run a speedtes from DSLReports https://www.dslreports.com/speedtest and click the gear to make sure "Hi-Res BufferBloat" is set, and set to 32/32 streams.
I find it very interesting that the start of the load shows a delayed mirrored shape of the throughput and the latency. Bandwidth peaks around 300Mb, but the latency doesn't go back to normal until ~220Mb/s, where it goes to stead-state throughput and normal latency for a while. I also noticed that the inpass and outpass is 30:1 ratio, sounding like ACKs. The reason I asked about DLSReports is because the upload test will give an idea of what your max upload is before queuing starts.
-
I assume the file I'm downloading is over TCP (it's SFTP).
Priority of voip is 15, DNS is 14, ACK is 14, priority of p2p (which is showing I'm downloading over) is 0.
With pretty much zero activity on the network I couldn't complete a speedtest with 32 streams, kept saying "30 from 32 streams failed to start. See error:11" etc.
Here's a speed test with hi-res bufferbloat turned on but default number of streams: https://www.dslreports.com/speedtest/28043335
It took me about 5 tries to get that speedtest to complete without any streams failing to start.
When I'm downloading the Status/Queues doesn't show the right download/upload speeds I'm getting but I don't know if that's what it's supposed to show.
Taken as a double monitor screen shot so they are at exactly the same time:
Before my download test starts:
During my download test (voip call was still up but horrible voice quality):
-Jamie M.
-
Your upload test is showing massive queuing a hair over 10Mb/s and stays quote stable all along 10Mb/s. It seems that your upload is only 10Mb, not 50Mb. Try settings your wan to 10Mb/s and your LAN to 230Mb/s. Also, for all of your queues on your LAN interface, make sure "Codel" is checked as the active queue.
-
Try settings your wan to 10Mb/s and your LAN to 230Mb/s. Also, for all of your queues on your LAN interface, make sure "Codel" is checked as the active queue.
With LAN and WAN set to codelq (wan 10MBit/s, LAN 230Mbit/s): http://www.dslreports.com/speedtest/28056896
Couldn't get it to complete a test with the default streams (8), had to move it down to 4 streams.
-Jamie M.
-
There are still some large spikes on the upload graph, but overall everything looks much better. You may want to reduce your bandwidth even further, by small steps of like 0.1Mb, and see if you can get rid of those spikes. Diminishing returns at this point and it's up to you to play around and decide what's a good trade-off.
One thing I would like to mention is that because you're using priq, and your download is so asymetric of your upload, when downloading, you're going to be saturating your upload with ACKs. ACKs are lower priority than VoIP, so VoIP should work, but anything lower than ACK or DNS is going to effectively die.
Hopefully VoIP will continue to work now. Let us know.
