pfSense Gold Subscription

Author Topic: playing with fq_codel in 2.4  (Read 12663 times)

0 Members and 1 Guest are viewing this topic.

Offline w0w

  • Sr. Member
  • ****
  • Posts: 522
  • Karma: +29/-6
  • kernel panic attack
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #15 on: April 06, 2017, 09:52:05 am »
As for GUI I was thinking about building some package, but I am not any kind of php programmer and  the best would be mainstream implementation into pfsense by professionals, core team.
We can also vote for bounty and see what happens.

Offline moscato359

  • Jr. Member
  • **
  • Posts: 91
  • Karma: +10/-6
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #16 on: April 11, 2017, 12:16:55 pm »
It's literally an on/off setting, and a kernel module

Offline w0w

  • Sr. Member
  • ****
  • Posts: 522
  • Karma: +29/-6
  • kernel panic attack
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #17 on: April 14, 2017, 01:46:30 am »
It's literally an on/off setting, and a kernel module
Not so simple. You need to enable limiters at least and use it in pf rule. So it's a lot of GUI and code change if we going to make it on the traffic shaper side. If we going to make it on the limiters side, then yes it's much more simpler, we need scheduler type selection and bandwidth OR delay limiting. Since I use delay limiting for pipe, it's not enough to use only bandwidth limit. 
BTW delay limiting with 0ms gives me the best result with bufferbloat test, since enabled, I have tested it multiple times per day and it's always A/A+ regarding to ISP mainstream router load.
The best thing that comes with delay setting is that you don't limit your traffic when it's really don't need to be limited. For example my real bandwidth varies from 250 to 300Mbit and sometimes to make it work without bufferbloat I need to limit bandwidth down to 100. I am not sure why delay limiting helps in this case but it really works at least with my ISP and I have no bandwidth limit on my side.

Offline Nullity

  • Hero Member
  • *****
  • Posts: 973
  • Karma: +96/-9
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #18 on: April 14, 2017, 03:10:09 am »
It's literally an on/off setting, and a kernel module
Not so simple. You need to enable limiters at least and use it in pf rule. So it's a lot of GUI and code change if we going to make it on the traffic shaper side. If we going to make it on the limiters side, then yes it's much more simpler, we need scheduler type selection and bandwidth OR delay limiting. Since I use delay limiting for pipe, it's not enough to use only bandwidth limit. 
BTW delay limiting with 0ms gives me the best result with bufferbloat test, since enabled, I have tested it multiple times per day and it's always A/A+ regarding to ISP mainstream router load.
The best thing that comes with delay setting is that you don't limit your traffic when it's really don't need to be limited. For example my real bandwidth varies from 250 to 300Mbit and sometimes to make it work without bufferbloat I need to limit bandwidth down to 100. I am not sure why delay limiting helps in this case but it really works at least with my ISP and I have no bandwidth limit on my side.

Thanks for trying to explain it. When it comes to traffic-shaping, even from a user perspective (disregarding the developer implementation), rarely is anything as simple as "It's literally an on/off setting, and a kernel module".

I've been guilty of back-seat driving myself... and I'm totally, fully, absolutely awesome.  ::)
Please correct any obvious misinformation in my posts.
-Not a professional; an arrogant ignoramous.

Offline moscato359

  • Jr. Member
  • **
  • Posts: 91
  • Karma: +10/-6
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #19 on: April 14, 2017, 11:12:45 pm »
Why wouldn't it be a check box next to where we already have codel, random, random in and out, and explicit congestion notification

All of those things are already implemented.

It's just a different control algorithm tied in at the same place

Offline Nullity

  • Hero Member
  • *****
  • Posts: 973
  • Karma: +96/-9
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #20 on: April 15, 2017, 02:14:57 am »
Why wouldn't it be a check box next to where we already have codel, random, random in and out, and explicit congestion notification

All of those things are already implemented.

It's just a different control algorithm tied in at the same place

One big reason is because the area you're referring to is in the queues (ALTQ) section while fq_codel was implemented in limiters (dummynet) section.

Why don't we "just" send humans to Mars? We already have robots there.

Like I said, back-seat driving is easy.
Please correct any obvious misinformation in my posts.
-Not a professional; an arrogant ignoramous.

Offline moscato359

  • Jr. Member
  • **
  • Posts: 91
  • Karma: +10/-6
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #21 on: April 15, 2017, 11:03:17 am »
Why wouldn't it be a check box next to where we already have codel, random, random in and out, and explicit congestion notification

All of those things are already implemented.

It's just a different control algorithm tied in at the same place

One big reason is because the area you're referring to is in the queues (ALTQ) section while fq_codel was implemented in limiters (dummynet) section.

Why don't we "just" send humans to Mars? We already have robots there.

Like I said, back-seat driving is easy.

Why is it under limiter, when the rest of them are under altq?

Offline Harvy66

  • Hero Member
  • *****
  • Posts: 2195
  • Karma: +202/-12
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #22 on: April 15, 2017, 04:06:46 pm »
ALTQ and Limiters are two different systems. My understanding is ALTQ is PF traffic shaping and Limiters are IPFW traffic shaping. Two competing firewall systems that FreeBSD has.

Offline Nullity

  • Hero Member
  • *****
  • Posts: 973
  • Karma: +96/-9
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #23 on: April 15, 2017, 10:53:44 pm »
Why wouldn't it be a check box next to where we already have codel, random, random in and out, and explicit congestion notification

All of those things are already implemented.

It's just a different control algorithm tied in at the same place

One big reason is because the area you're referring to is in the queues (ALTQ) section while fq_codel was implemented in limiters (dummynet) section.

Why don't we "just" send humans to Mars? We already have robots there.

Like I said, back-seat driving is easy.

Why is it under limiter, when the rest of them are under altq?

I'm a bit unclear about what you're asking but if you are asking why fq_codel was implemented in dummynet rather than ALTQ you'd need to ask the devs: http://caia.swin.edu.au/freebsd/aqm/

I'd like to know as well. Maybe they think ipfw/dummynet is more future-proof than ALTQ? I dunno...
Please correct any obvious misinformation in my posts.
-Not a professional; an arrogant ignoramous.

Offline nallar

  • Newbie
  • *
  • Posts: 2
  • Karma: +0/-0
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #24 on: April 18, 2017, 09:08:02 am »
By default, fq_codel uses ECN.

This often doesn't work properly for upload so you may need to try without it. For my config this meant using:

ipfw sched 1 config pipe 1 type fq_codel ecn && ipfw sched 2 config pipe 2 type fq_codel noecn

Swap ecn/noecn as needed depending on the order you created the limiters in.

Offline moscato359

  • Jr. Member
  • **
  • Posts: 91
  • Karma: +10/-6
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #25 on: April 21, 2017, 08:31:02 am »
Interestingly, on Linux, fq_codel is in mainstream kernel, and enabled by default now.no settings required.

Offline w0w

  • Sr. Member
  • ****
  • Posts: 522
  • Karma: +29/-6
  • kernel panic attack
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #26 on: April 21, 2017, 01:22:50 pm »
By default, fq_codel uses ECN.

This often doesn't work properly for upload so you may need to try without it. For my config this meant using:

ipfw sched 1 config pipe 1 type fq_codel ecn && ipfw sched 2 config pipe 2 type fq_codel noecn

Swap ecn/noecn as needed depending on the order you created the limiters in.

I know what are you talking about.
https://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel/
But FQ_CODEL revision was updated several times since this article was published and no official remarks about ECN and recommended settings in docs.
I have read a lot and played a bit with ECN option, but in my case it have no effect directly. If anybody suggest some simple way to test ECN I will be much thankful.

Offline Nullity

  • Hero Member
  • *****
  • Posts: 973
  • Karma: +96/-9
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #27 on: April 21, 2017, 02:15:47 pm »
By default, fq_codel uses ECN.

This often doesn't work properly for upload so you may need to try without it. For my config this meant using:

ipfw sched 1 config pipe 1 type fq_codel ecn && ipfw sched 2 config pipe 2 type fq_codel noecn

Swap ecn/noecn as needed depending on the order you created the limiters in.

I know what are you talking about.
https://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel/
But FQ_CODEL revision was updated several times since this article was published and no official remarks about ECN and recommended settings in docs.
I have read a lot and played a bit with ECN option, but in my case it have no effect directly. If anybody suggest some simple way to test ECN I will be much thankful.

You can use tcpdump to see whether ECN has been negotiated/used, then run downloads & uploads with ECN disabled/enabled to see if there's any difference in speeds and/or latencies.

For me, it improved download (or was it upload? or both?) speeds by a few percent but over a few days of using ECN (Linux client /proc/sys/net/ipv4/tcp_ecn = 1) had a couple of sites completely fail to work so I set tcp_ecn back to it's default (2).


Whether your pfSense router supports ECN is a separate condition from your client supporting it, so make sure to configure it appropriately on both.

I only played with ECN very quickly so take my input with a grain of salt... ;)
Please correct any obvious misinformation in my posts.
-Not a professional; an arrogant ignoramous.

Offline w0w

  • Sr. Member
  • ****
  • Posts: 522
  • Karma: +29/-6
  • kernel panic attack
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #28 on: April 22, 2017, 08:28:30 am »
...
For me, it improved download (or was it upload? or both?) speeds by a few percent but over a few days of using ECN (Linux client /proc/sys/net/ipv4/tcp_ecn = 1) had a couple of sites completely fail to work so I set tcp_ecn back to it's default (2).


Whether your pfSense router supports ECN is a separate condition from your client supporting it, so make sure to configure it appropriately on both.

I only played with ECN very quickly so take my input with a grain of salt... ;)
Do you remember URLs of sites failed to work with ECN?
I've seen some reports like "Measuring the State of ECN Readiness in Servers, Clients" and others too, all of them stated that there is some % of servers that have wrongly configured ECN and this is the real problem, even if percentage of those servers lowered over years, but the real quantity raised up, so the simplest way is to test ECN enabled FQ_CODEL against some of those " ECN-failed" sites.

Offline HeatmiserNYC

  • Jr. Member
  • **
  • Posts: 26
  • Karma: +0/-0
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #29 on: April 22, 2017, 03:15:26 pm »
Setting my bandwidth to 95% of my always results in about 20mb off of my total bandwidth in tests. It seems that to use this you have to take a bandwidth hit....