Question on a simple traffic shaping excercise
-
I have some questions on my setup for Traffic Shaping.
I've been reading up on Traffic shaping from various forums posts, and guides, and I think I understand now the basics of PRIQ, CBQ, and HFSQ.My ISP grants me 600Mb/s downlink with 40Mb/s uplink.
I've ran numerous speedtests directly connected to their modem (and within pfsense without traffic shaping) and can normally obtain 620Mb/s down with 32Mb/s up.
I'm thinking I want to apply Traffic Shaping so that no singular device can consume all the traffic, which happened a while back when I was video conferencing for work and my roommate was uploading all their photos to Amazon. I assume what happened was they took all the uplink and starved my device in ACK & Send packets for video conferencing.My goal:
-
Don't allow any one device to consume all the bandwidth when others need it
-
Alllow any single device to use all the bandwidth when others don't need it
-
When competing for bandwidth give a single device priority over others
-
LAN to LAN traffic that goes through the gateway should not be limited
Tell me if i'm wrong but i'm thinking based on these goals, I would rule out Limiters since they are thresholds not fitting my second goal.
I think I would also rule out PRIQ since it could cause one queue (say my "MainQueue") to starve out the others below it which would be against my first goal.
I'm also staying away from HFSQ for now since it's a bit too complex for me at the moment.
Therefore I settled on CBQ, I figure I could setup a hierarchical Queue where bandwidth is shared 50/50 at max usage.Below is an example of my queue setup from pfsense where em1 is my WAN, and em0 is my LAN interface
QUEUE BW SCH PRIO PKTS BYTES DROP_P DROP_B QLEN BORROW SUSPEN P/S B/S
root_em1 40M cbq 0 173759 95692417 0 0 0 0 0 63 21557
qMainUpload 20M cbq 0 0 0 0 0 0 0 0 0
qOtherUpload 20M cbq 2 173759 95692417 332 473169 0 49816 1 63 21557
root_em0 1000M cbq 0 368980 489319K 0 0 0 0 0 34 2465
qInternet 600M cbq 2 0 0 0 0 0 0 0 0 0
qMainDownload 300M cbq 3 0 0 0 0 0 0 0 0 0
qOtherDownload 300M cbq 4 366265 486495K 3111 4685335 0 155951 1185 33 2411
qInternal 400M cbq 2715 2891619 0 0 0 0 0 1.0 53*I'm assuming to meet my 4th goal where traffic goes to gateway for VIPS, the qInternal would handle that so I don't limit my 1Gb\s LAN with 600Mb\s
After setting this up I made the qOtherDownload a default queue, and when I run a speedtest against the same server, instead of getting around 600Mb\s I get 225Mb\s.
Why is this? Shouldn't the qOtherDownload borrow from qMainDownload to get 600Mb\s? -
-
You may want to consider this alternative approach that uses limiters to dynamically & fairly share bandwidth among active hosts: https://forum.pfsense.org/index.php?topic=63531.msg364520#msg364520
-
This might be the route to go. I followed the screenshots and setup the limiters then applied it to default LAN rule.
When I do several speedtests (SourceForge, Fast, Speedtest) I can only obtain 230Mbps..If I remove the limiter on the Firewall Rule i'm able to get up to 520Mbps.
Why is the limiter restricting the bandwidth when it should be available? -
@terminalhit:
This might be the route to go. I followed the screenshots and setup the limiters then applied it to default LAN rule.
When I do several speedtests (SourceForge, Fast, Speedtest) I can only obtain 230Mbps..If I remove the limiter on the Firewall Rule i'm able to get up to 520Mbps.
Why is the limiter restricting the bandwidth when it should be available?Dunno. What's the CPU load during a speed test?
-
@terminalhit:
This might be the route to go. I followed the screenshots and setup the limiters then applied it to default LAN rule.
When I do several speedtests (SourceForge, Fast, Speedtest) I can only obtain 230Mbps..If I remove the limiter on the Firewall Rule i'm able to get up to 520Mbps.
Why is the limiter restricting the bandwidth when it should be available?Dunno. What's the CPU load during a speed test?
From the Admin Web Page, it jumps to about 30%. Here are the processor specs
CPU Type Intel(R) Atom(TM) CPU D2500 @ 1.86GHz
2 CPUs: 1 package(s) x 2 core(s)With the limiter I ran it and got 240Mb down.. Took off the Limiter and re-ran and got 504Mb down
-
Limiters are exactly what you want.
Try enabling fq_codel via CLI. Make it persistent with shellcmd.
-
@terminalhit:
This might be the route to go. I followed the screenshots and setup the limiters then applied it to default LAN rule.
When I do several speedtests (SourceForge, Fast, Speedtest) I can only obtain 230Mbps..If I remove the limiter on the Firewall Rule i'm able to get up to 520Mbps.
Why is the limiter restricting the bandwidth when it should be available?Increase the queue size I had this problem and resolved it (thanks to JIM) by increasing the queue size to 200,
-
Putting the queue size seemed to help. It looks like the throughput slowly increases . I wonder if the speedtest ran long enough if it would hit the 500Mb mark.
In regards to Codel, does that work with Limiters or the other type of traffic shaping? If so, how do you enable it and use it? I tried searching around, but I see older posts and not too familiar with setting it
For reference, here are the results with taking off the Limiter
-
Oh by the way also do this (also instructed be JIM),
setup a tunable on System > Advanced, Tunables tab to increase net.inet.ip.dummynet.pipe_slot_limit, try setting that to 500.
-
Oh by the way also do this (also instructed be JIM),
setup a tunable on System > Advanced, Tunables tab to increase net.inet.ip.dummynet.pipe_slot_limit, try setting that to 500.That might have helped, i'm able to get about 320. I'm thinking maybe it's just a slow climb to 500Mb with Limiters?
For the tunable, do I need to reboot to take affect?I might try and run a speedtest off of Azure/Amazon using iperf
-
Maybe try to keep increasing the queue size slowly till it reaches your speed
-
I would set the queue size to 1,000. The average packet size is about 600 bytes, or 4800bits, which is a bit over 1,000 packets for 10ms of buffer @ 500Mbit/s.
Your upload is much slower, you'll want a linearly smaller queue.