Traffic Shaper - Queue Length and Dropped Packets
-
OP: I just ran into a problem when I mixed a queue with TCP and non-TCP packets and used CoDel on the queue. Actually, no queue-drops registered, but CoDel was dropping ~30% of the ping packets being sent through. I now make sure to only use CoDel on queues exclusively filled with TCP only.
So you have a queue for both TCP and ICMP and say ICMP packet-loss but nothing registered with the queue? Are you sure the packets are being dropped by PFSense and not the connection to your ISP?
-
I would be very interested in bufferbloat-reduction reports using either the rrul test suite or the new dslreports tool regarding hfsc + fairqueue + codel, in particular.
http://www.internetsociety.org/blog/tech-matters/2015/04/measure-your-bufferbloat-new-browser-based-tool-dslreports
-
OP: I just ran into a problem when I mixed a queue with TCP and non-TCP packets and used CoDel on the queue. Actually, no queue-drops registered, but CoDel was dropping ~30% of the ping packets being sent through. I now make sure to only use CoDel on queues exclusively filled with TCP only.
So you have a queue for both TCP and ICMP and say ICMP packet-loss but nothing registered with the queue? Are you sure the packets are being dropped by PFSense and not the connection to your ISP?
With CoDel on a mixed protocol queue, during a saturated upload test, if my ping packets went through said queue they had CoDel-like latency (30-60ms) but had ~30% of the pings unreplied. No QueueDrops registered. Queue averaged about 3 packets.
If CoDel was disabled on the queue, ping latency was 600ms with 0% ping packet loss. Queue averaged about 30 packets.When I assigned pings to another queue, I had 0% packet loss and the same latency.
I did not run tcpdump to see where the packet was last seen.
-
So it sounds like the queue statistics may not be reporting drops correctly when using codel?
-
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 guess it could be possible that the way FreeBSD records dropped packets is if the queue responds with a "full" return code when attempting to enqueue from the wire to the queue. If that is the only way for it to track drops, when you'll never see drops that are internal to codel. That would also mean those times I did see drops, it was because the queue actually got full and not because of max latency in queue.
-
-
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.