pfSense Gold Subscription

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

0 Members and 1 Guest are viewing this topic.

Offline Harvy66

  • Hero Member
  • *****
  • Posts: 2217
  • Karma: +204/-12
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #195 on: December 01, 2017, 10:35:20 am »
Your target should also be at least 1.5x how long it takes to send an MTU amount of data at your bandwidth. Cake does this automatically as they found general limit works well.

The reason for this is you don't want a single MTU sized packet to trip the drop logic.

Offline Cardnyl

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #196 on: December 03, 2017, 02:45:50 pm »
Your target should also be at least 1.5x how long it takes to send an MTU amount of data at your bandwidth. Cake does this automatically as they found general limit works well.

The reason for this is you don't want a single MTU sized packet to trip the drop logic.

What is the correct way to set these targets?

Offline Harvy66

  • Hero Member
  • *****
  • Posts: 2217
  • Karma: +204/-12
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #197 on: December 04, 2017, 11:29:40 am »
I assume the "net.inet.ip.dummynet.fqcodel" settings you mentioned in your just prior post.

Offline tman222

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +6/-0
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #198 on: December 04, 2017, 07:46:23 pm »
Your target should also be at least 1.5x how long it takes to send an MTU amount of data at your bandwidth. Cake does this automatically as they found general limit works well.

The reason for this is you don't want a single MTU sized packet to trip the drop logic.

What is the correct way to set these targets?

So I experimented with this a little bit, and changing the values below either in the System Tunables section or by editing loader.conf.local didn't seem to work because these fq_codel defaults don't appear to show up until fq_codel is actually loaded.  So if you are loading fq_codel using shellcmd this won't really work.

Code: [Select]
net.inet.ip.dummynet.fqcodel.limit: 10240
net.inet.ip.dummynet.fqcodel.flows: 1024
net.inet.ip.dummynet.fqcodel.quantum: 1514
net.inet.ip.dummynet.fqcodel.interval: 100000
net.inet.ip.dummynet.fqcodel.target: 5000

You can make it work, but you would have to load fq_codel using ipfw so the defaults show up, change the default values to what you want them to be using sysctl and then load fq_codel again with the new values.

However, I think there is an easier way as you can change these values just by editing the ipfw command that loads fq_codel.

From a link posted earlier in this thread:

http://caia.swin.edu.au/freebsd/aqm/patches/README-0.2.1.txt

From section 3, the syntax for loading fq_codel via ipfw is:

Code: [Select]
ipfw sched x config [...] type fq_codel [target t] [interval t] [ecn | noecn]
        [quantum n] [limit n] [flows n]
 
 where
    t is time in seconds (s), milliseconds (ms) or microseconds (us). The
        default interpretation is milliseconds.
    n is an integer number

The command to load fq_codel with the defaults (from earlier in the thread):

Code: [Select]
ipfw sched 1 config pipe 1 type fq_codel && ipfw sched 2 config pipe 2 type fq_codel


Using similar syntax as above, in your case all you would have to change is:

Code: [Select]
ipfw sched 1 config pipe 1 type fq_codel target 15 noecn quantum 300 limit 600 && ipfw sched 2 config pipe 2 type fq_codel target 15 noecn quantum 300 limit 600

This does the following:
Set target to 15ms (you'll need higher than default of 5ms given the low upload on your 15/1 connection)
Turn off ECN
Set fq_codel quantum to 300
Set queue size limit to 600 packets

(feel free to tweak these values as necessary)

Now of course, this all assumes that you have already created two limiters and queues underneath them.

You can issue the command above from the command line and make it persistent between reboots using shellcmd.

Hope this helps.

Offline tman222

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +6/-0
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #199 on: December 04, 2017, 08:36:47 pm »
I also have a question for everyone following this thread:

The command to enable fq_codel that has been shown in this thread to be:
Code: [Select]
ipfw sched 1 config pipe 1 type fq_codel && ipfw sched 2 config pipe 2 type fq_codel

However, looking at the examples in 3.3 here:
http://caia.swin.edu.au/freebsd/aqm/patches/README-0.2.1.txt

Doesn't the command have to be appended to include setting the the scheduler on the queue, i.e.:

Code: [Select]
ipfw sched 1 config pipe 1 type fq_codel && ipfw queue 1 config sched 1 && ipfw sched 2 config pipe 2 type fq_codel ipfw queue 2 config sched 2

The above assumes only two queues, one under each limiter.

Thanks in advance for the help.

Offline w0w

  • Sr. Member
  • ****
  • Posts: 538
  • Karma: +31/-6
  • kernel panic attack
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #200 on: December 04, 2017, 10:52:50 pm »
I also have a question for everyone following this thread:

The command to enable fq_codel that has been shown in this thread to be:
Code: [Select]
ipfw sched 1 config pipe 1 type fq_codel && ipfw sched 2 config pipe 2 type fq_codel

However, looking at the examples in 3.3 here:
http://caia.swin.edu.au/freebsd/aqm/patches/README-0.2.1.txt

Doesn't the command have to be appended to include setting the the scheduler on the queue, i.e.:

Code: [Select]
ipfw sched 1 config pipe 1 type fq_codel && ipfw queue 1 config sched 1 && ipfw sched 2 config pipe 2 type fq_codel ipfw queue 2 config sched 2

The above assumes only two queues, one under each limiter.

Thanks in advance for the help.

I have used second, official variant, but have also found that first variant also works just fine if you have already configured limiters via GUI.

Offline atrotter01

  • Newbie
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #201 on: December 05, 2017, 07:06:12 pm »
I am trying to set this up on an SG-3100 with an asymmetrical gigabit connection.  I setup two queues and am configuring them as follows:

Code: [Select]
ipfw pipe 1 config  bw 920Mb
ipfw sched 1 config pipe 1 type fq_codel
ipfw queue 1 config sched 1 mask dst-ip6 /128 dst-ip 0xffffffff

ipfw pipe 2 config  bw 40232Kb
ipfw sched 2 config pipe 2 type fq_codel
ipfw queue 2 config sched 2 mask src-ip6 /128 src-ip 0xffffffff

On the firewall side I am using a floating rule to apply the queues.  This all works, with the floating rule enabled I get A / A+ on the DSL Reports speed test, whereas without the rule I get a C at best for bufferbloat.  The issue I am having is with the rule enabled, I get at most ~650Mb/s bandwidth downstream, I have no problem hitting 940 with the rule disabled.  Am I running into a CPU limitation of the SG-3100? Is there anything I can try to tweak?

Offline Animosity022

  • Jr. Member
  • **
  • Posts: 53
  • Karma: +4/-0
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #202 on: December 06, 2017, 10:19:17 am »
I am trying to set this up on an SG-3100 with an asymmetrical gigabit connection.  I setup two queues and am configuring them as follows:

Code: [Select]
ipfw pipe 1 config  bw 920Mb
ipfw sched 1 config pipe 1 type fq_codel
ipfw queue 1 config sched 1 mask dst-ip6 /128 dst-ip 0xffffffff

ipfw pipe 2 config  bw 40232Kb
ipfw sched 2 config pipe 2 type fq_codel
ipfw queue 2 config sched 2 mask src-ip6 /128 src-ip 0xffffffff

I'd love to have someone else chime in, but the way I "think" the masks work is that you are sharing bandwidth between source and destinations based on the "mask src/mask dst" rules going on. So that causes some dynamic queues to be setup and it'll share out bandwidth amongst those queues so assuming you have some other traffic going on even if it's only a little, it will limit the bandwidth out.

Maybe try without having the src and dst masks setup and just leave those blank and see how your results look. Also, you can check the CPU % or something? i'm not familiar with that on that particular to device to tell you how, but that would validate if you are having a CPU bottleneck instead.

On the firewall side I am using a floating rule to apply the queues.  This all works, with the floating rule enabled I get A / A+ on the DSL Reports speed test, whereas without the rule I get a C at best for bufferbloat.  The issue I am having is with the rule enabled, I get at most ~650Mb/s bandwidth downstream, I have no problem hitting 940 with the rule disabled.  Am I running into a CPU limitation of the SG-3100? Is there anything I can try to tweak?

Offline atrotter01

  • Newbie
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #203 on: December 06, 2017, 03:57:12 pm »
I tried leaving the masks off and that didn't seem to make a difference.  Then I tried disconnecting everything from the firewall except the laptop that I am using to test with, so that I could ensure nothing else was on the network.  That didn't make a difference either.  When the limiters are not enabled I can run a sustained 60 second download test and hit gig speeds 95% of the time, other than occasional dips.  When I enable the limiters I can't get over the 650ish mark.

I can run top from an SSH session and it looks to be pegging one of the cores both with and without fq_codel so I can't really tell one way or the other there.

Offline johnpoz

  • Hero Member
  • *****
  • Posts: 14457
  • Karma: +1337/-200
  • Not a pfSense employee, they cannot fire me...
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #204 on: December 07, 2017, 04:17:10 am »
If you have symmetrical gig gig, why are you setting 40232Kb on pipe2

So 40mb?  Whats the amount of traffic for acks to hit 650 vs 940?  Have to do the math, etc.  But limiting your upload could have an effect on your max download.. Shoot 500mbps down would be like 8mbps or something up just in acks..

If your on gig/gig why would you want to limit your upload so much?

Not a qos guy, this was my real first test of any sort of qos in pfsense.. But I got asked to take a look, that is what jumps out at me to look odd..  In a few days when my 4860 is online I would be able to test your settings.  But not going to be ready until the weekend for sure..  But will be able try and duplicate the problem next week say.
 
- An intelligent man is sometimes forced to be drunk to spend time with his fools.
- Please don't PM me for personal help
- if you want to say thanks applaud or https://www.freebsdfoundation.org/donate/
1x SG-2440 2.3.4_p1 (work)
1x SG-4860 2.4.2-RELEASE-p1 (home)

Offline atrotter01

  • Newbie
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #205 on: December 07, 2017, 05:30:08 am »
John thanks, it's asymmetrical, not symmetrical.  :) The connection maxes out at about 940/42.

Offline Animosity022

  • Jr. Member
  • **
  • Posts: 53
  • Karma: +4/-0
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #206 on: December 07, 2017, 09:24:24 am »
What's the CPU as well? I couldn't drive shaping until I did some upgrades. I'm overpowered now with an:

   Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz (4 cores)

But I wanted to future proof a bit. I can drive gig both directions at the same time without breaking my CPU atm.

Offline atrotter01

  • Newbie
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #207 on: December 07, 2017, 05:45:38 pm »
It's a dual core ARM v7 Cortex-A9 @ 1.6 GHz with NEON SIMD and FPU. I think I am either hitting some odd issue with traffic shaping on ARM architecture or a CPU limitation.

Offline tman222

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +6/-0
    • View Profile
Re: playing with fq_codel in 2.4
« Reply #208 on: December 08, 2017, 04:53:57 pm »
It's a dual core ARM v7 Cortex-A9 @ 1.6 GHz with NEON SIMD and FPU. I think I am either hitting some odd issue with traffic shaping on ARM architecture or a CPU limitation.

1)  Do you run any type of IPS/IDS currently (e.g. Snort)?  If so, try disabling it temporarily to see if that helps.
2)  What's the output of "ipfw sched show"?  I think it would be good to doublecheck your fq_codel parameters.
3)  As alternative you can try ALTQ traffic shaping (instead of dummynet) to see if you experience similar limitations.  Instead of using limiters, try setting up the ALTQ FAIRQ scheduler and then enable Codel in the default queue.  You'll probably also need to increase the default queue size from 50 to something larger like 512 or 1024.  FAIRQ + Codel is not quite the same as fq_codel, but it it's similar (I have used both and the performance in my case was comparable).   If you try that, do you see a similar speed limitation that you currently see with dummynet/fq_codel?

Hope this helps.