Got fq_codel yet?

dtaht · Wed Sep 17, 2014 9:45 am

I am curious if fq_codel is available in these latest beta releases?

nkourtzis · Wed Sep 17, 2014 9:05 pm

I would't think so. Support for it before Linux 3.5 is nonexistent and even after 3.5 it is still very sparse. It seems that 3.12 is the lowest sensible requirement. Can we expect it to land in v7? Normis?

Zorro · Fri Sep 19, 2014 5:30 pm

oh yeah. fixing bloatbuffering and recent kernels used in RouterOS, thus - would be LOT of help.
but seems they presently focused on polishing Tilera code bit more than moving upstream.
which is sane.

Azendale · Tue Sep 23, 2014 2:27 am

I too would be quite interested in this.

Zorro · Tue Sep 23, 2014 4:38 am

I too would be quite interested in this.

i think its matter of time.
cuz newer kernels bring LOT of different improvements(aside Co_Del and other measures against blotbuffer, incrimental nearly in ANY next/new release), quite benefiticary for any kind of devices.

semenko · Wed Sep 24, 2014 7:40 am

fq_codel support would be amazing and could really improve our experience.

(Unfortunately, this seems almost entirely based on the kernel version.)

dtaht · Fri Sep 26, 2014 4:13 am

To clear up some stuff - fq_codel became stable in linux 3.6, and was backported by qualcomm-atheros folk as far back as linux 2.6.32 as part of the compat-wireless patchset. If you are using that patchset on an older kernel, you already have fq_codel.

Most of the core de-bufferbloating work entered the kernel before linux 3.10, and linux 3.10.12 and later (there were some bugs in htb backported from 3.11) have everything that is "core" to a router's needs for vastly better queue management. Now that 3.10 is stable (and the list of products using fq_codel other than mikrotik is getting rather long), some new work is starting up in the 3.18 series that will be interesting.

Useful stuff to have in general are bql support on the ethernet and dsl device drivers, also. That is generally a tiny amount of work per bql-enabled device driver for a large latency improvement at low speeds, and a noticible one at all line rate speeds.

A frustrating aspect of most of the new router designs is that much offloads are buried in the network hardware to make it "go fast", but they are difficult to turn off when it is needed to slow down enough to manage a slow uplink (eg, ISP gateway) more intelligently. The cavium used in the edgerouter is a classic example of this problem. Using software rate limiting to manage an ISP link peaks out at about 60Mbit. I'd hope that the tilera stuff in particular, would have either enough oomph to do software rate limiting better, or be able to embed algos such as htb + fq_codel in their offload engines in general.

An example of the benefit of fq_codel (and the above problem) is here:

http://burntchrome.blogspot.com/2014/08 ... t-sqm.html

At lower speeds the bufferbloat problem is much worse, and most hardware can handle these compensating mechanisms without raising a sweat, if it has the core stuff available.

I am (personally) in search of a routing product that can handle up to 300mbit software rate limiting + fq_codel...

semenko · Mon Sep 29, 2014 10:37 pm

Looks like there was a discussion this summer about CoDel here: http://forum.mikrotik.com/viewtopic.php?f=2&t=63594

We've been testing this on some saturated servers and other *nix routers with great results. Hoping to see it in v7.

PtDragon · Fri Jan 16, 2015 12:42 am

fq_codel is really good thing for router or heavily loaded server.
Please add support of it into RouterOS.
It works well with HTB tree (as good as RED or SFQ).
It was ported to lot of kernels so it can be in RouterOS too.
Hope it can be done easily enough and you will add it soon ^_^

Fri Jan 16, 2015 9:42 am

thanks for the suggestion, we are looking into it for v7. currently you can use SFQ, which is also very good

ghandalf · Sat Aug 01, 2015 8:07 pm

Hi,

I know, this is an old thread, but I have a question to the last thread posted by normis.

@normis,

you said, instead of using fq_codel, you can use SFQ and this also works quite well.

I was looking for some HowTo this, but unfortunately, I did not find anything about SFQ and reducing bufferbloat.

Can you give me some advices or maybe a short HowTo?

My bandwidth is 30/6 Down/Up Mbit.

With a full upload (about 5,8Mbit), my ping times rise from normal 6ms to my ISP nameserver to 250-900ms.

Regards,
Florian

PtDragon · Wed Aug 05, 2015 3:49 am

Hi,

I know, this is an old thread, but I have a question to the last thread posted by normis.

@normis,

you said, instead of using fq_codel, you can use SFQ and this also works quite well.

I was looking for some HowTo this, but unfortunately, I did not find anything about SFQ and reducing bufferbloat.

Can you give me some advices or maybe a short HowTo?

My bandwidth is 30/6 Down/Up Mbit.

With a full upload (about 5,8Mbit), my ping times rise from normal 6ms to my ISP nameserver to 250-900ms.

Regards,
Florian

I use queue trees for this(without SFQ as it slows down things for me).
I got 3-8ms jump at full download or upload (which is more than 500mbit).
If you wish i can post my queue rules.

ghandalf · Sun Aug 09, 2015 11:27 pm

Hi PtDragon,

would be great, when you can post your rules!

Hopefully, I can rewrite these rules to use them in my config, but I will do my best!

THX,
Florian

PtDragon · Fri Aug 14, 2015 3:05 pm

I attached full export of /ip/firewall/mangle and /queue
I can clean up that mess a bit if you need just for one interface.

ghandalf · Mon Aug 17, 2015 8:53 pm

I attached full export of /ip/firewall/mangle and /queue
I can clean up that mess a bit if you need just for one interface.

Hi,

thank you very much! I looked into your config and I have to say, that you have a lot of WAN interfaces!

I tried to separate one interface from both config files, but mangle config is quite hard to understand with so many interfaces and rules.

The next thing, I don't understand is that you have in queue config, different parent interface for ethX-IN and ethx-OUT.
Another thing is also not completly clear to me, which rules from mange config, I really need for the queue part.

It would be great, if you can shrink down your config to only one WAN interface.

Do you have 100Mbit Up/Downlink? If yes, why do you use only 95Mbit for rate limit?

Regards
Florian

PtDragon · Mon Aug 17, 2015 9:07 pm

I looked into your config and I have to say, that you have a lot of WAN interfaces!

Yeah, that's true. I have 6 links from 3 ISPs right now.

The next thing, I don't understand is that you have in queue config, different parent interface for ethX-IN and ethx-OUT.

It's because I limit both incoming and outgoing traffic for each external interface.
I need to limit it to avoid big delays on ISP network.

Do you have 100Mbit Up/Downlink? If yes, why do you use only 95Mbit for rate limit?

I have 100Mbit on both interfaces but limit to 95 to avoid delays inside ISP limiting queues(which varies from 20 to 300ms).
Not reaching limit = no additional delay from limiting by ISP.

It would be great, if you can shrink down your config to only one WAN interface.

Sure, I will do it today or tonight.

PtDragon · Tue Sep 29, 2015 4:08 pm

Sorry guys, was a bit busy(when working on several jobs at same time it happens

)
queue:

/queue tree
add limit-at=1 max-limit=95M name=ETH1-IN parent=bonding1 queue=RED16
add limit-at=1 max-limit=95M name=ETH1-OUT parent=ether1 queue=RED16
add name=ETH1-IN-1 parent=ETH1-IN priority=1 queue=PFIFO_8
add name=ETH1-IN-4 parent=ETH1-IN priority=4 queue=PFIFO_8
add name=ETH1-IN-8 parent=ETH1-IN queue=PFIFO_8
add name=ETH1-IN_BT packet-mark=wan0_bt_in parent=ETH1-IN-8 queue=RED16
add name=ETH1-OUT-1 parent=ETH1-OUT priority=1 queue=PFIFO_8
add name=ETH1-OUT-4 parent=ETH1-OUT priority=4 queue=PFIFO_8
add name=ETH1-OUT-8 parent=ETH1-OUT queue=PFIFO_8
add name=ETH1-OUT_DNS packet-mark=wan0_dns parent=ETH1-OUT-1 queue=PFIFO_32
add name=ETH1-OUT_ICMP packet-mark=wan0_icmp parent=ETH1-OUT-1 priority=4 queue=PFIFO_8
add name=ETH1-OUT_HTTP packet-mark=wan0_http parent=ETH1-OUT-4 priority=4 queue=PFIFO_32
add name=ETH1-OUT_SSH packet-mark=wan0_ssh parent=ETH1-OUT-4 priority=1 queue=PFIFO_8
add name=ETH1-OUT_SSL packet-mark=wan0_ssl parent=ETH1-OUT-4 priority=3 queue=PFIFO_32
add name=ETH1-OUT_BT packet-mark=wan0_bt parent=ETH1-OUT-8 queue=RED16
add name=ETH1-OUT_SSL_B packet-mark=wan0_ssl_b parent=ETH1-OUT-4 priority=6 queue=RED16
add name=ETH1-IN-4-1 parent=ETH1-IN-4 priority=1 queue=PFIFO_8
add name=ETH1-IN-4-8 parent=ETH1-IN-4 queue=PFIFO_8
add name=ETH1-IN-2 parent=ETH1-IN priority=2 queue=PFIFO_8
add name=ETH1-OUT_OTHER packet-mark=wan0p_out parent=ETH1-OUT-8 queue=RED16
add name=ETH1-OUT_ACK packet-mark=ack_wan0 parent=ETH1-OUT-1 priority=1 queue=RED16
add name=ETH1-IN_OTHER packet-mark=wan0p_in parent=ETH1-IN-8 priority=4 queue=RED16
add name=ETH1-IN_ACK packet-mark=wan0_ack_in parent=ETH1-IN-1 priority=1 queue=RED16
add name=ETH1-IN_ICMP packet-mark=wan0_icmp_in parent=ETH1-IN-2 priority=4 queue=PFIFO_8
add name=ETH1-IN_DNS packet-mark=wan0_dns_in parent=ETH1-IN-2 queue=PFIFO_32
add name=ETH1-IN_HTTP packet-mark=wan0_http_in parent=ETH1-IN-4-1 priority=4 queue=PFIFO_32
add name=ETH1-IN_SSH packet-mark=wan0_ssh_in parent=ETH1-IN-4-1 priority=1 queue=PFIFO_8
add name=ETH1-IN_SSL packet-mark=wan0_ssl_in parent=ETH1-IN-4-1 priority=3 queue=RED16
add name=ETH1-IN_SSL_B packet-mark=wan0_ssl_in_b parent=ETH1-IN-4-8 priority= 3 queue=RED16

95Mbit is 95% of bandwidth limit on interface(100Mbit).
Queue types:
PFIFO_numpackets=simple pfifo queue, number is number of packets
REDnumpackets=red queue, number is number of packets.
Avg packet size=1000.
Min threshold=25%of size.
Max threshold=75% of size.
Burst=50%of size.

PtDragon · Tue Sep 29, 2015 4:28 pm

Firewall part:

/ip firewall mangle
add action=set-priority chain=prerouting new-priority=from-dscp
add action=set-priority chain=prerouting new-priority=from-ingress
add action=mark-connection chain=prerouting connection-state=new dst-address-list=LAN new-connection-mark=LOCAL src-address-list=LAN
add action=fasttrack-connection chain=prerouting connection-mark=LOCAL
add action=jump chain=input connection-state=new in-interface=!bonding1 jump-target=mark_in_only
add action=mark-connection chain=mark_in_only in-interface=ether1 new-connection-mark=wan0
add action=return chain=mark_in_only
add action=jump chain=prerouting connection-mark=no-mark connection-state=new in-interface=!bonding1 jump-target=mark_conn_input
add action=mark-connection chain=mark_conn_input connection-mark=no-mark in-interface=ether1 new-connection-mark=wan0
add action=return chain=mark_conn_input
add action=jump chain=prerouting comment="Jump to prerouting connection marks (PCC)" connection-mark=no-mark connection-state=new dst-address-list=!LAN in-interface=bonding1 jump-target=mark_prerouting_internal
add action=mark-connection chain=mark_prerouting_internal comment=wan0 new-connection-mark=wan0 nth=6,1
add action=return chain=mark_prerouting_internal
add action=jump chain=prerouting comment="Jump to prerouting connection marks (PCC)" connection-mark=no-mark connection-state=new in-interface=bonding1 jump-target=mark_prerouting_internal
add action=jump chain=prerouting comment="Jump to prerouting connection marks (PCC)" connection-mark=no-mark connection-state=new in-interface=bonding1 jump-target=mark_prerouting_internal
add action=jump chain=prerouting comment="Jump to force_marks" connection-mark=no-mark connection-state=new dst-address-list=!LAN in-interface=bonding1 jump-target=mark_prerouting_internal_f
add action=jump chain=output connection-state=new jump-target=mark_out out-interface=!bonding1
add action=mark-connection chain=mark_out new-connection-mark=wan0 out-interface=ether1
add action=return chain=mark_out
add action=jump chain=prerouting comment="Jump to mark routing prerouting" connection-mark=!no-mark in-interface=bonding1 jump-target=mark_routing_prerouting
add action=mark-routing chain=mark_routing_prerouting connection-mark=wan0 new-routing-mark=wan0
add action=return chain=mark_routing_prerouting
add action=jump chain=prerouting comment="Marking incomming packets" jump-target=mark_prerouting
add action=mark-packet chain=mark_prerouting in-interface=ether1 new-packet-mark=wan0p_in
add action=mark-packet chain=mark_prerouting in-interface=bonding1 new-packet-mark=bonding_in
add action=return chain=mark_prerouting
add action=jump chain=forward comment="Marking WAN output packets" jump-target=mark_wan out-interface=!bonding1
add action=mark-packet chain=mark_wan new-packet-mark=wan0p_out out-interface=ether1
add action=return chain=mark_wan
add action=jump chain=forward in-interface=ether1 jump-target=wan0_proto_in out-interface=!ether1
add action=jump chain=forward in-interface=!ether1 jump-target=wan0_proto out-interface=ether1
add action=mark-packet chain=wan0_proto dst-limit=400,100,addresses-and-dst-port/10ms layer7-protocol=http new-packet-mark=wan0_http
add action=mark-packet chain=wan0_proto dst-limit=800,200,addresses-and-dst-port/10ms layer7-protocol=http new-packet-mark=wan0_http_b packet-mark=wan0p_out
add action=mark-packet chain=wan0_proto new-packet-mark=wan0_icmp protocol=icmp
add action=mark-packet chain=wan0_proto layer7-protocol=bittorrent new-packet-mark=wan0_bt
add action=mark-packet chain=wan0_proto layer7-protocol="5TP" new-packet-mark=wan0_bt
add action=mark-packet chain=wan0_proto new-packet-mark=wan0_bt p2p=bit-torrent
add action=mark-packet chain=wan0_proto new-packet-mark=wan0_bt protocol=tcp src-address=192.168.4.64 src-port=16508
add action=mark-packet chain=wan0_proto new-packet-mark=wan0_bt protocol=udp src-address=192.168.4.64 src-port=16508
add action=mark-packet chain=wan0_proto dst-limit=800,200,addresses-and-dst-port/10ms layer7-protocol=ssl new-packet-mark=wan0_ssl packet-mark=wan0p_out
add action=mark-packet chain=wan0_proto layer7-protocol=ssl new-packet-mark=wan0_ssl_b packet-mark=wan0p_out
add action=mark-packet chain=wan0_proto layer7-protocol=ssh new-packet-mark=wan0_ssh packet-mark=wan0p_out
add action=mark-packet chain=wan0_proto dst-limit=800,200,addresses-and-dst-port/10ms layer7-protocol=ssh new-packet-mark=wan0_ssh_b packet-mark=wan0p_out
add action=mark-packet chain=wan0_proto layer7-protocol=dns new-packet-mark=wan0_dns
add action=return chain=wan0_proto
add action=mark-packet chain=wan0_proto_in dst-limit=400,100,addresses-and-dst-port/10ms layer7-protocol=http new-packet-mark=wan0_http_in packet-mark=wan0p_in
add action=mark-packet chain=wan0_proto_in layer7-protocol=http new-packet-mark=wan0_http_in_b packet-mark=wan0p_in
add action=mark-packet chain=wan0_proto_in new-packet-mark=wan0_icmp_in protocol=icmp
add action=mark-packet chain=wan0_proto_in layer7-protocol=bittorrent new-packet-mark=wan0_bt_in
add action=mark-packet chain=wan0_proto_in layer7-protocol="5TP" new-packet-mark=wan0_bt_in
add action=mark-packet chain=wan0_proto_in new-packet-mark=wan0_bt_in p2p=bit-torrent
add action=mark-packet chain=wan0_proto_in dst-address=192.168.4.64 dst-port=16508 new-packet-mark=wan0_bt_in protocol=tcp
add action=mark-packet chain=wan0_proto_in dst-address=192.168.4.64 dst-address-list=local_ips dst-port=16508 new-packet-mark=wan0_bt_in protocol=udp
add action=mark-packet chain=wan0_proto_in dst-limit=200,100,addresses-and-dst-port/100ms layer7-protocol=ssl new-packet-mark=wan0_ssl_in packet-mark=wan0p_in
add action=mark-packet chain=wan0_proto_in layer7-protocol=ssl new-packet-mark=wan0_ssl_in_b packet-mark=wan0p_in
add action=mark-packet chain=wan0_proto_in layer7-protocol=ssh new-packet-mark=wan0_ssh_in
add action=mark-packet chain=wan0_proto_in layer7-protocol=dns new-packet-mark=wan0_dns_in
add action=return chain=wan0_proto_in
add action=jump chain=forward jump-target=mark_ack_wan out-interface=!bonding1 packet-size=0-128 protocol=tcp tcp-flags=ack
add action=jump chain=forward jump-target=mark_ack_wan out-interface=!bonding1 packet-size=0-128 protocol=tcp tcp-flags=fin,rst,ack
add action=jump chain=forward jump-target=mark_ack_wan out-interface=!bonding1 packet-size=0-128 protocol=tcp tcp-flags=fin,syn,ack
add action=jump chain=forward jump-target=mark_ack_wan out-interface=!bonding1 packet-size=0-128 protocol=tcp tcp-flags=syn
add action=jump chain=forward jump-target=mark_ack_wan out-interface=!bonding1 packet-size=0-128 protocol=tcp tcp-flags=rst
add action=jump chain=forward jump-target=mark_ack_wan out-interface=!bonding1 packet-size=0-128 protocol=tcp tcp-flags=rst,ack
add action=jump chain=forward jump-target=mark_ack_wan out-interface=!bonding1 packet-size=0-128 protocol=tcp tcp-flags=fin,ack
add action=jump chain=forward jump-target=mark_ack_wan out-interface=!bonding1 packet-size=0-128 protocol=tcp tcp-flags=syn,ack
add action=jump chain=forward jump-target=mark_ack_wan out-interface=!bonding1 packet-size=0-128 protocol=tcp tcp-flags=fin,ack
add action=jump chain=forward jump-target=mark_ack_wan out-interface=!bonding1 packet-size=129-809 protocol=tcp tcp-flags=ack
add action=mark-packet chain=mark_ack_wan connection-mark=wan0 new-packet-mark=ack_wan0 out-interface=ether1
add action=return chain=mark_ack_wan
add action=jump chain=prerouting in-interface=!bonding1 jump-target=mark_ack_in_wan packet-size=0-128 protocol=tcp tcp-flags=ack
add action=mark-packet chain=mark_ack_in_wan connection-mark=wan0 in-interface=ether1 new-packet-mark=wan0_ack_in
add action=return chain=mark_ack_in_wan
add action=change-dscp chain=postrouting comment="Setting DSCP for the switch" new-dscp=38 out-interface=bonding1
add action=change-dscp chain=postrouting new-dscp=46 out-interface=bonding1 packet-size=0-128 protocol=tcp tcp-flags=ack
add action=change-dscp chain=forward comment="Setting DSCP for the ISP" new-dscp=38 out-interface=!bonding1
add action=change-dscp chain=forward new-dscp=46 packet-mark=ack_wan0

You should use your marks instead of NTH or PCC for your config!
Internal interface is bonding1
External interface is ether1
LAN address list is for internal LAN routing on bonding1(which can't be balanced to external interfaces so marked before everything else).
Config isn't perfect and is designed for fast routers such as CCR1036 and may slow things down on routers with not enough CPU power(I didn't test on other routers).

Zorro · Thu Oct 01, 2015 10:06 pm

things like RRED https://en.wikipedia.org/wiki/Robust_ra ... _detection
ECB support and DCTCP support would help a lot potentially along with native MPTCP(multi-path TCP) support(already released 0.90 version which is cool)

ab0tj · Thu Feb 11, 2016 6:47 pm

Just putting my vote in for this. CoDel would be a very welcome addition to the QoS options in RouterOS.

Zorro · Fri Feb 19, 2016 1:28 pm

Just putting my vote in for this. CoDel would be a very welcome addition to the QoS options in RouterOS.

which imply - Newer Linux kernel to Properly support it with real benefits(few/incomplete "back-porting" attempts - bring only fractions of benefits from), which imply it can be only in Router OS 7.x versions, since MT developers state that such major updates to tool-chain and ROS itself - mean major version change.
my point is: not like its happen Soon. generally "major" ROS versions had huge distance in time. betwee say 5.0 and 6.0 passed a LOT of time for example :=)

personally - i would care MUCH more about anti-bloatbuffering control methods introduced in newer kernel and netfilter with fine-grained control and serious/precise tweaking and enforcement, than coDel as one of Many things, that rely on with consumers benefits in many aspects.
generally moving "upstream" not only bring important improvements such as those, but improve security A LOT, boost hardware compatibility(even across "legacy" embedded things/devices)and even improve performance(cuz sometimes updates mean cleaner, simpler, re-worked, fixed code and/or enteriely replaced things or deprecated broken ones)
RouterOS-wize i can underline among them those things as:
nftables
https://en.wikipedia.org/wiki/Nftables
opendpi/ndpi thing(very light-weght, low-overhead DPI implementation, suitable even for low-power routers)
http://www.ntop.org/products/deep-packe ... tion/ndpi/
and number of others that take hours to only enumerate/list them(rather than discuss/explain).

R1CH · Mon Jul 18, 2016 5:59 pm

I've been reading up on AQM and managing buffer sizes and was a bit disappointed to only see RED available on my MT devices. Would love to see fq_codel / RRED available in future ROS versions as buffer bloat is a huge problem among residential users.

Zorro · Wed Jul 20, 2016 8:20 am

I've been reading up on AQM and managing buffer sizes and was a bit disappointed to only see RED available on my MT devices. Would love to see fq_codel / RRED available in future ROS versions as buffer bloat is a huge problem among residential users.

well newer kernels had serious benefits even w/o fq_codel in terms of countering/perventing bloatbuffering.
and both not really work "from box" and need few adjustments, but fq_codel coniderably more fool-proof and ready to go, and RRED generally not need adjustments in most cases(same about improved SFQ works, which isn't my favorite topic, but remain future-proof thing too)

pabl0 · Sat Feb 04, 2017 10:50 am

Any news on codel? Everybody else has it, only we are stuck in the past

lmns · Wed Feb 08, 2017 1:20 pm

It's definitely unfortunate that ROS v7 takes so long. The newer kernel would make fq_codel support pretty much a guaranteed feature without any effort on MikroTik's side. SFQ works OK, but fq_codel is so much better most of the time it's not even funny.

PtDragon · Wed Feb 08, 2017 3:14 pm

Any news on codel? Everybody else has it, only we are stuck in the past

Maybe another year or two(or more, who knows?) and we will get it.
It is surely under development but not at high priority(5 had just 26 builds and 6 has already 39(and will grow counter bigger, i feel that)).

SystemErrorMessage · Sat Feb 11, 2017 1:38 pm

i too would like to see this but mainly because i havent figured out how to use RED or SFQ.

Mikrotik is starting to lag behind in software now as other manufacturers in the same field have implement newer and more modern features like DNScrypt and are seriously far behind in the managed switch as they lack the most basic features to make them reliable and useful in a complex network.

Even the ability to use domains in the configuration rather than ip address or resolving the domain and using the IP as not everyone uses a static IP. I cant make a p2p VPN network using mikrotik with home connections as i can get no ip domains and update them from mikrotik using script and https but i cant put domains in the rules to make them connect/reconnect with each other by having them resolve the domain each time. Other routers, even consumer routers that are linux based allow you to use domains and will resolve the domain at the time when the config is used rather than resolving and storing the IP instead. This is just an example of a basic feature that even mikrotik is missing out on.

russman · Sat Sep 01, 2018 4:27 pm

thanks for the suggestion, we are looking into it for v7. currently you can use SFQ, whh is also very good

Come on man, throw us a bone. Ubiquiti has it in their firewalls, I'm trying hard to not use theirs but you're not making it easy. SFQ is better than some even older more abusive options but is still deprecated since FQCodel offers a fair superior experience. https://www.bufferbloat.net/projects/co ... s_Gallery/

mducharme · Sun Sep 02, 2018 3:27 am

Come on man, throw us a bone. Ubiquiti has it in their firewalls, I'm trying hard to not use theirs but you're not making it easy. SFQ is better than some even older more abusive options but is still deprecated since FQCodel offers a fair superior experience. https://www.bufferbloat.net/projects/co ... s_Gallery/

I don't think they can implement it until the new kernel version, which only arrives in v7. Harping at them to try to get it sooner will not help.

doush · Tue Sep 04, 2018 1:16 pm

Well after nearly 5 years of time, still no word from MT. At least an explanation would be nice.

frozutek · Fri Sep 07, 2018 10:37 am

Just signed up to the forums to say... I really want this feature too.

At this rate I'm going to have to buy an Ubiquiti EdgeRouter X to replace my hEX...

Steveocee · Tue Sep 11, 2018 9:12 am

Just signed up to the forums to say... I really want this feature too.

At this rate I'm going to have to buy an Ubiquiti EdgeRouter X to replace my hEX...

Not quite as good as codel but use an sfq until it gets implemented. Just make sure you set the limits a few kB below what your service can do to ensure the router controls the packet flow.

Janevski · Sat May 11, 2019 12:01 am

Is fq_codel implemented in MikroTik RouterOS?

r00t · Sat May 11, 2019 4:29 pm

Is fq_codel implemented in MikroTik RouterOS?

no, it's not

And answer to all problems and current issues is still exactly the same, like it was in the year 2015:

thanks for the suggestion, we are looking into it for v7. currently you can use SFQ, which is also very good

Four years later and we are still waiting for the magic unicorn v7...

ivantirado · Sun May 12, 2019 5:02 am

I haven't found a suitable solution in other products either. The Ubiquiti solutions don't have enough throughput and have other problems. I don't IF/WHEN Mikrotik will ever get around to this, been waiting for a long time.. so I decided to bypass Mikrotik on this topic and built a Linux VM, passed two NICs to it directly on ESXi, bridged them in the OS and implemented the newest Cake code into that kernel (Cake is a newer, better version of fq_codel) .. I then simply plugged in said VM between my CCR1016 and the LAN. It's a bump in the wire and its only function is to do queuing/shaping. Works perfect.

Steveocee · Mon May 13, 2019 11:29 am

I haven't found a suitable solution in other products either. The Ubiquiti solutions don't have enough throughput and have other problems. I don't IF/WHEN Mikrotik will ever get around to this, been waiting for a long time.. so I decided to bypass Mikrotik on this topic and built a Linux VM, passed two NICs to it directly on ESXi, bridged them in the OS and implemented the newest Cake code into that kernel (Cake is a newer, better version of fq_codel) .. I then simply plugged in said VM between my CCR1016 and the LAN. It's a bump in the wire and its only function is to do queuing/shaping. Works perfect.

Untangle is a very good option for a polished off the shelf.

ivantirado · Mon May 13, 2019 6:35 pm

Untangle is a pretty good firewall/UTM. It's lacking in the routing department, so I'd be running Untangle plus a router like the Mikrotik anyway. Another alternative for firewall/UTM might be Ipfire or even PFsense/OPNsense (I've used PFsense before). I chose to go with a bump-in-the-wire queuing machine because that's how the setup would end up if I chose to go with one of those.

Got fq_codel yet?

Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Re: Got fq_codel yet?

Who is online