Thanks Derelict, will set the limiters and report results.

On your WAN

Scheduler Type: fairq
Bandwidth: 95% of your maximum. If you have really stable bandwidth, then possibly 98%. If you have very unstable bandwidth, then closer to 80%.

Create a default queue, set the length to 4096, check codel.

Results may vary. It should keep latency low.

I'll we glad when we can have our Cake and delete it too.

Okay. I will have to test those settings as well.  I saw the other post about Codel with UDP and dropping packets. Maybe that was some of my issue I was having.

Will have to test with putting UDP only queues under some other queueing and then using Codel for TCP only queues.

There were some complaints of packet loss in some of the games using UDP solely

Limiters + NAT -> broken. Search the fine bugtracker.

With all of the extremes this person is trying to do, it may be better to ask if there is any traffic they want getting through the firewall. I might assume that they only care about HTTP/HTTPS, but even HTTPS may be an issue for them because of filtering. Maybe they should start off with blocking all ports except 80/443.

https://forum.pfsense.org/index.php?topic=63531.0

thanks, i try this.

A major discrepancy of Fair Queueing is per-byte fairness vs per-packet fairness. According to DragonflyBSD's FAIRQ source-code, FAIRQ is per-byte fair… I think. Per-packet can be deceptively unfair, depending on expectations.

Limiting and shaping are two different things.  With a limiter, it is a hard cap regardless of maximum bandwidth.  With a shaper, low-priority queues will get to use all bandwidth until something more important comes along.  This is a simplified explanation of how it really works.

Thanks Deric. Your "1:79, 81:65535" suggestion is what I was looking for.

It's basically the same problem as in here…
https://forum.pfsense.org/index.php?topic=91299.0

Sam

My next venture is to learn more about debugging ALTQ so I can see more stats. I am assuming I will need to resort to a full FreeBSD to get more control of the system though. Learning more about FreeBSD is probably a good idea.

I bet that the bufferbloat/Codel mailing-list has some great info about how to simulate traffic for testing.

I have only played with netperf casually. The few worthwhile tests I ran I did with either multiple sessions of iperf, or multiple sessions of netcat/nc. Netcat is insanely powerful. Every few months since I learned of netcat I am amazed by how powerful the simple tool can be; "netcat host2 port < /dev/zero" to a listening netcat and bam, single stream TCP/UDP traffic. or send a file with the same method. or create a remote shell. That is just the standard uses.

There is gns3, but it is Cisco emulation primarily. Good userbase and polished interface.

There must be a good, simple simulator, right? Call DARPA maybe? ;)

The wizard attempts to make sure that VoIP traffic goes into qVOIP by directing your SIP server traffic to it, but it doesn't do it by DPI or any magic – just it's address.  If you already have your phones segmented off by themselves then it will be stupid simple.  Create an alias for your phone subnet, then modify the floating rule that directs the VoIP traffic and change the source to be your alias.  Done.  All traffic coming from your phone subnet will be shunted to qVOIP.

Keep sniffing while the queue is active and see which ports are triggering the rule.

1.  Traffic shaping forum is specifically for issues involving the traffic shaper.

2.  You likely had an environmental issue with your line after the storm.  I've seen cases of excess water shorting out a connection that fixed itself with the help of evaporation.

You could also try to make a tunnel specifically for the IPTV traffic –- Then you could shape traffic based upon which tunnel the traffic was received from.

@KOM:

I wonder how that TBR interacts with the PRIQ caveat that high priority queues will starve low priority queues of bandwidth if there is enough high traffic?  I believed PRIQ was absolute: higher priority goes first no matter what.

That is my understanding as well. The only thing that has changed for me is what controls the bitrate.

I had always wondered how PRIQ could have no rate-limiting, since it is practically a necessity for QoS.