Playing with fq_codel in 2.4
-
So I have found what was the problem — I have been applied this patch on already configured limiters and queues. Now I removed all queues, leaved limiters and applied patch again and then recreated queues — all went OK.
It looks like we have problems with parsing old config? Tried also latest 2.4.4 and behavior is the same.BTW, That's what I'm trying to achieve https://forum.pfsense.org/index.php?topic=63531.0
-
That may require more testing from me, then, if it is ignoring or otherwise not parsing those limiters once the patch is applied. I'll have to take a look some time
-
Config.xml parts with ipfw configuration
Original, before applying patch:<dnshaper><queue><name>Upload</name> <number>1</number> <bandwidth><bw>265576</bw> <bwscale>Kb</bwscale> <bwsched>none</bwsched></bandwidth> <enabled>on</enabled> <mask>none</mask> <maskbits></maskbits> <maskbitsv6></maskbitsv6> <delay>0</delay> <queue><name>UploadQueue</name> <number>1</number> <enabled>on</enabled> <mask>srcaddress</mask> <maskbits>32</maskbits> <maskbitsv6>128</maskbitsv6></queue></queue> <queue><name>Download</name> <number>2</number> <bandwidth><bw>275576</bw> <bwscale>Kb</bwscale> <bwsched>none</bwsched></bandwidth> <enabled>on</enabled> <mask>none</mask> <maskbits></maskbits> <maskbitsv6></maskbitsv6> <delay>0</delay> <queue><name>DownloadQueue</name> <number>2</number> <enabled>on</enabled> <mask>dstaddress</mask> <maskbits>32</maskbits> <maskbitsv6>128</maskbitsv6></queue></queue></dnshaper>Original after applying patch:
<dnshaper><queue><name>Upload</name> <number>1</number> <bandwidth><bw>265576</bw> <bwscale>Kb</bwscale> <bwsched>none</bwsched></bandwidth> <enabled>on</enabled> <mask>none</mask> <maskbits></maskbits> <maskbitsv6></maskbitsv6> <delay>0</delay> <queue><name>UploadQueue</name> <number>1</number> <enabled>on</enabled> <mask>srcaddress</mask> <maskbits>32</maskbits> <maskbitsv6>128</maskbitsv6></queue> <sched>fq_codel</sched> <param_fq_codel_target>5</param_fq_codel_target> <param_fq_codel_interval>100</param_fq_codel_interval> <param_fq_codel_quantum>1514</param_fq_codel_quantum> <param_fq_codel_limit>10240</param_fq_codel_limit> <param_fq_codel_flows>1024</param_fq_codel_flows> <aqm>codel</aqm> <param_codel_target>5</param_codel_target> <param_codel_interval>100</param_codel_interval> <ecn>on</ecn></queue> <queue><name>Download</name> <number>2</number> <bandwidth><bw>275576</bw> <bwscale>Kb</bwscale> <bwsched>none</bwsched></bandwidth> <enabled>on</enabled> <mask>none</mask> <maskbits></maskbits> <maskbitsv6></maskbitsv6> <delay>0</delay> <queue><name>DownloadQueue</name> <number>2</number> <enabled>on</enabled> <mask>dstaddress</mask> <maskbits>32</maskbits> <maskbitsv6>128</maskbitsv6></queue> <sched>fq_codel</sched> <param_fq_codel_target>5</param_fq_codel_target> <param_fq_codel_interval>100</param_fq_codel_interval> <param_fq_codel_quantum>1514</param_fq_codel_quantum> <param_fq_codel_limit>10240</param_fq_codel_limit> <param_fq_codel_flows>1024</param_fq_codel_flows> <aqm>codel</aqm> <param_codel_target>5</param_codel_target> <param_codel_interval>100</param_codel_interval> <ecn>on</ecn></queue></dnshaper>New fully working:
<dnshaper><queue><name>Upload</name> <number>1</number> <bandwidth><bw>265576</bw> <bwscale>Kb</bwscale> <bwsched>none</bwsched></bandwidth> <enabled>on</enabled> <mask>none</mask> <maskbits></maskbits> <maskbitsv6></maskbitsv6> <delay>0</delay> <sched>fq_codel</sched> <param_fq_codel_target>5</param_fq_codel_target> <param_fq_codel_interval>100</param_fq_codel_interval> <param_fq_codel_quantum>1514</param_fq_codel_quantum> <param_fq_codel_limit>10240</param_fq_codel_limit> <param_fq_codel_flows>1024</param_fq_codel_flows> <aqm>codel</aqm> <param_codel_target>5</param_codel_target> <param_codel_interval>100</param_codel_interval> <ecn>on</ecn> <queue><name>Upload_Q</name> <number>1</number> <enabled>on</enabled> <mask>srcaddress</mask> <maskbits>32</maskbits> <maskbitsv6>128</maskbitsv6> <aqm>pie</aqm> <param_pie_target>15</param_pie_target> <param_pie_tupdate>15</param_pie_tupdate> <param_pie_alpha>125</param_pie_alpha> <param_pie_beta>1250</param_pie_beta> <param_pie_max_burst>150000</param_pie_max_burst> <param_pie_max_ecnth>99</param_pie_max_ecnth></queue></queue> <queue><name>Download</name> <number>2</number> <bandwidth><bw>275576</bw> <bwscale>Kb</bwscale> <bwsched>none</bwsched></bandwidth> <enabled>on</enabled> <mask>none</mask> <maskbits></maskbits> <maskbitsv6></maskbitsv6> <delay>0</delay> <sched>fq_codel</sched> <param_fq_codel_target>5</param_fq_codel_target> <param_fq_codel_interval>100</param_fq_codel_interval> <param_fq_codel_quantum>1514</param_fq_codel_quantum> <param_fq_codel_limit>10240</param_fq_codel_limit> <param_fq_codel_flows>1024</param_fq_codel_flows> <aqm>codel</aqm> <param_codel_target>5</param_codel_target> <param_codel_interval>100</param_codel_interval> <ecn>on</ecn> <queue><name>Download_Q</name> <number>2</number> <enabled>on</enabled> <mask>dstaddress</mask> <maskbits>32</maskbits> <maskbitsv6>128</maskbitsv6> <aqm>pie</aqm> <param_pie_target>15</param_pie_target> <param_pie_tupdate>15</param_pie_tupdate> <param_pie_alpha>125</param_pie_alpha> <param_pie_beta>1250</param_pie_beta> <param_pie_max_burst>150000</param_pie_max_burst> <param_pie_max_ecnth>99</param_pie_max_ecnth></queue></queue></dnshaper> -
any progress on fixing traceroute?
-
any progress on fixing traceroute?
What is broken? If it's broken where do you have reported it? ???
-
@w0w:
any progress on fixing traceroute?
What is broken? If it's broken where do you have reported it? ???
it was reported on here earlier by someone else: https://forum.pfsense.org/index.php?topic=126637.msg765566#msg765566
could it be issue with the way I have set up the firewall rules as floating (same as person in the post I linked to above)
If I do traceroute I see all the hops show up as the destination ip. -
I am not sure if it's IPFW/dummynet problem, I think it's should be reported on redmine as soon as new Limiters GUI is merged with master branch.
Do you really need this floating rule? -
it was reported on here earlier by someone else: https://forum.pfsense.org/index.php?topic=126637.msg765566#msg765566
could it be issue with the way I have set up the firewall rules as floating (same as person in the post I linked to above)
If I do traceroute I see all the hops show up as the destination ip.It's unclear that this is a problem with limiters themselves. It only happens if you use a floating rule to assign the queue. If you use the default allow rule on the interface to assign the queue, the traceroute problem does not occur.
-
Only reason I have it as floating is because I have 6 vlans. I will set it one by one in each vlan and hope this goes away.
-
Only reason I have it as floating is because I have 6 vlans. I will set it one by one in each vlan and hope this goes away.
Yea, I hear you. Floating is much more convient. I have 5 local nets, although using interface specific rules I only bother with 4 of them. The last network is very low traffic and I don’t want to drop packets there anyway.
-
Just finished setting up the rules and traceroute is fixed now. :)
-
https://github.com/pfsense/pfsense/pull/3941
PR was accepted and needs to be tested now.
-
! amazing !
-
https://github.com/pfsense/pfsense/pull/3941
PR was accepted and needs to be tested now.
Sorry I am not on development releases but has limiter info page also been updated to show schedulers information?
like suggested earlier in this thread:
@w0w:
Patch for Limiter Info page with schedulers information and refresh interval of 500ms
--- diag_limiter_info.php Wed Sep 07 00:26:47 2016 +++ diag_limiter_info.php Sun Oct 01 08:20:33 2017 @@ -40,5 +40,5 @@ echo $text; - $text = `/sbin/ipfw queue show`; + $text = `/sbin/ipfw sched show`; if ($text != "") { - echo "\n\n" . gettext("Queues") . ":\n"; + echo "\n\n" . gettext("Shedulers") . ":\n"; echo $text; @@ -72,3 +76,3 @@ events.push(function() { - setInterval('getlimiteractivity()', 2500); + setInterval('getlimiteractivity()', 500); getlimiteractivity(); -
Not yet, that's gonna need to be a separate PR. I'm thinking of maybe making a Queue-like page for that instead of text-based readouts.
-
any idea when this will show up in 2.4 development snapshots?
-
Can someone please guide me how to setup the shellcmd if Im using more than 1 queue per pipe as in:
(I have placed different weights to identify where queues are placed)pipe 1 config bw 5000Kb queue 1 config pipe 1 weight 10 mask src-ip6 /128 src-ip 0xffffffff queue 2 config pipe 1 weight 20 mask src-ip6 /128 src-ip 0xffffffff pipe 2 config bw 1024Kb queue 3 config pipe 2 weight 30 mask dst-ip6 /128 dst-ip 0xffffffff queue 4 config pipe 2 weight 40 mask dst-ip6 /128 dst-ip 0xffffffffusing the setup above i get this when running ipfw sched show
[2.4.3-RELEASE][root@pfTest.localdomain]/root: ipfw sched show 00001: 5.000 Mbit/s 0 ms burst 0 q00001 50 sl. 0 flows (256 buckets) sched 1 weight 10 lmax 0 pri 0 droptail mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 sched 1 type FQ_CODEL flags 0x0 0 buckets 0 active FQ_CODEL target 5ms interval 100ms quantum 1514 limit 10240 flows 1024 ECN Children flowsets: 2 1 00002: 1.024 Mbit/s 0 ms burst 0 q00002 50 sl. 0 flows (256 buckets) sched 1 weight 20 lmax 0 pri 0 droptail mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 sched 2 type FQ_CODEL flags 0x0 0 buckets 0 active FQ_CODEL target 5ms interval 100ms quantum 1514 limit 10240 flows 1024 ECN Children flowsets: 4 3If you pay close attention you can see that the queues 1 and 2 from pipe 1 are assigned to sched 1 and 2... look for the weight value and youll see better.
im using this command:
ipfw sched 1 config pipe 1 type fq_codel && ipfw sched 2 config pipe 2 type fq_codelhope you guys can help me!
-
@matt_ said in Playing with fq_codel in 2.4:
https://github.com/pfsense/pfsense/pull/3941
PR was accepted and needs to be tested now.
Could I download this to my box for testing, or to a test VM? I am super excited to have a less hacky way to implement fq_codel.
-
@cplmayo
Yes, you can. What is your pfSense version? -
@w0w I am on the latest release
