Traffic Shaper - Queue Length and Dropped Packets
-
So it sounds like the queue statistics may not be reporting drops correctly when using codel?
That it what I was thinking as well.
I wonder if it should register. The queue never overflows, technically, right?
I have this issue as well. Codel drops never register.
Is it an issue? From a queue perspective, the queue is never overflowed (technically?) when codel is implemented.
More to the point, is this discrepancy causing any problems?
-
If you're trying to diagnose why a packet came in the WAN but not out the LAN, it would be nice to know your dropped packet count went up by one instead of it just disappearing with no indication anywhere as to why.
-
If you're trying to diagnose why a packet came in the WAN but not out the LAN, it would be nice to know your dropped packet count went up by one instead of it just disappearing with no indication anywhere as to why.
Like I mentioned earlier in the thread, I think queue drops are only logged as such if the queue is the reason for the drop.
Other drops are not, but should they be? I dunno. I would prefer that all the rrdtool graphs in pfSense were more reliable, but since I do not use those graphs for anything important, I kinda don't care…
I would probably use tcpdump to solve the situation you describe, because I am unclear of the semantics involved in the interface/queue stats.