Queues show NaN values, why?
-
Same here. Noticed this on a fresh install of 2.4.3. I was using PRIQ is 2.4.2 without these issues. I could see the borrows and suspends column not be related to PRIQ specifically. But I can't figure out why one of my queues (which is identical to all the other non-default queues other than priority number) is saying NaN for drops.
![PRIQ - NaN pfSEnse 2.4.3.png](/public/imported_attachments/1/PRIQ - NaN pfSEnse 2.4.3.png)
![PRIQ - NaN pfSEnse 2.4.3.png_thumb](/public/imported_attachments/1/PRIQ - NaN pfSEnse 2.4.3.png_thumb) -
I see NaN on all queue types eventually.
-
Ah finally other people noticed.
I knew it was a bug, but wanted others to chime first…
From my own testing, this happens is you change the Queue Limit from the default (either null or 500) to a bigger number (1000, 2000).
If you don't do that, the queues would show the numbers (who knows if they are correct), but not NAN, until a day or so later, where some will show NaN.
I'm guessing some wrong math or counters, but a bug in this release, none the less.
I'm using traffic shaping.
I have used a few different types, PRIQ works well for voip, but i'm looking to understand and use HFSC more.
In both of these queue schedulers, I see NaN (not a number) in the queue status.
Any idea why? See screen captures enclosed.
-
I just retested with all default queue length settings and I get NaN right away for borrows and suspends using PRIQ.
-
These NaN don't indicate that the shaping has any operational errors do they?
I see them on all interfaces, on all pri types.
-
I didn't see them at all on PRIQ in 2.4.2.
-
Bug filed: https://redmine.pfsense.org/issues/8468
-
No Activity on this in a Year. :(
Fresh install this weekend on 2.4.4-RELEASE-p3 (amd64) built on Wed May 15 18:53:44 EDT 2019
and seeing the NaN using HFSC in Borrows and suspends
Any support needed from a non-programmer in troubleshooting?
-
I just started using Traffic shaping and noticed the same thing. The reason it was happening for me is that I was using Suricata with Inline mode. There is apparently an issue with netmap.
If you're using Suricata with inline mode, try to disable it and see if it helps. If it does help, switch to Legacy mode instead.
-
Just to clarify, I actually don't know if Inline mode of Suricata breaks the traffic shaping, it may or it may just be a reporting issue. Because it also breaks the outbound bandwidth graph, but you still have outbound traffic.
-
Looks like internally the server runs
pfctl -s queue -v
which doesn't print borrows by default. Neither doespftop -v queue
, which was mentioned in the bug.
The code to pass along the values is there, so this is just visual.
If you want a quick patch, edit/usr/local/www/status_queues.php
and append|| 0
to the following lines:- borrows = parseFloat(queue['borrows']); - suspends = parseFloat(queue['suspends']); + borrows = parseFloat(queue['borrows'] || 0); + suspends = parseFloat(queue['suspends'] || 0);