Messages

This issue was resolved and added as a 17.7 milestone. Does this mean it already implemented in the latest update?

Ah, thanks!! I see it now :)

Oh just to comment something on earlier posts.

That you don't have to hit the box codel or set a mask on fq_codel makes perfect sense.

- Cause codel can also be used as just a way how to let packets drop if a pipe gets saturated. Essentially just if the delay exceeds a certain amount of ms.
- FQ_codel is a way that it automatically makes queues out of flows. So a mask is not needed to generate queues.

Cake would even be super great to have when it's available. Then the automatic flow creation done in a much nicer way.

But first, it would be super nice to have this traffic shaper going :)

Some extra info.

I tried it on two setups that I have running. Both give only FIFO as a type. Now for testing I just have a VM with 17.1.8 on it. Super simple setup it just always shows FIFO. Like this for example:

Code Select Expand

Limiters:
10000:  40.000 Mbit/s    0 ms burst 0
q141072  50 sl. 0 flows (1 buckets) sched 75536 weight 0 lmax 0 pri 0 droptail
sched 75536 type FIFO flags 0x0 0 buckets 0 active

It's now a bit weird to know if it's really working or not, this guessing is really a bit...

But even if you set it up in the CLI with something like

Code Select Expand

IPFW pipe config sched QFQ it remains on FIFO if you do IPFW pipe show.

How did you manage to get the type on FQCODEL. Cause no matter what I try, my scheduler type stays on FIFO. But there seems difference in how it behaves...

Even if I add the pipe in the shell. No matter what you enter it always shows FiFo sadly...

Added the issue on Github.

Looks like now the slow response is only present in:

- dashboard > interfaces widget
- interfaces > overview
- interfaces > wireless > status (I don't have any wifi hardware or setup)

Tried the patch, seems to work better. But the interfaces > overview is still hanging here.

More than thanks for the great and quick response!

I'll try it tomorrow morning. Also should I still make issue of it at GitHub?

I'm searching a bit but didn't found it yet...

I setup'ed 150 vlans total of 152 interfaces. This causes the GUI interface to stop responding.

When I put off the interface listing on the dashboard I can at least login, but still everything is super slowly responding...

I know it is a bit rough to say, but PFsense had the same thing going until they fixed it somewhat half a year ago. I would massively prefer Opnsense over PFsense so would it be possible to fix this matter?

I would supply gladly more details and such.

Cheers,

Peter