Droped Packets and Suspends for no obvious reason
-
So I have been playing around with CBQ Traffic Shaping and either I am doing something wrong or something is not working correctly…
I have the following queues configured for the traffic shaper.
LAN - Enabled, Scheduler Type = CBQ, Bandwidth = empty, Queue Limit = empty, TBR Size = empty
TotalDownload - Priority = empty, Queue limit = empty, Scheduler options = none, Bandwidth = 50Mbit/s
dDefault - Priority = empty, Queue limit = empty, Scheduler options = default queue, Bandwidth = 100%
WAN- Enabled, Scheduler Type = CBQ, Bandwidth = empty, Queue Limit = empty, TBR Size = empty
TotalUpload- Priority = empty, Queue limit = empty, Scheduler options = none, Bandwidth = 10Mbit/s
uDefault- Priority = empty, Queue limit = empty, Scheduler options = default queue, Bandwidth = 100%
As you can see from above there is really not any traffic shaping occurring as the only queue that is in place is the default one so all traffic is being sent through this queue. As a side note I have allocated the maximum amount of bandwidth available from my ISP to the appropriate queue above.
My issue is that I would think that with the queues configured like this and given that the most bandwidth I have used at any one time today peaked at about 8Mbit/s well within my 50Mbit/s (down) and 10Mbit/s (up) provided by my ISP that I would not being seeing suspends/drops on the traffic shaper queue monitoring page. However right now (as I type this post) I have 253 suspends on the LAN interface and 444 suspends and 30 drops on the WAN interface.
Any ideas on why this is occurring? Do I not have something set correctly somewhere?
-
The default queue size of 50 could be causing issues. Try increasing your queues. I'd recommend using CoDel. I'm not actually sure if CoDel cares about the queue size setting.
-
So I had read in other posts that the queue size should be increased, however I have yet to really see a good explanation of what queue length is and what it should be set to, would you care to explain this in more detail so that I can better understand what is going on?
I have also seen the use Codel thrown around as well, but like the queue length there is not really a lot of explanation (at least that I can find) of what that does and what it means.
Any additional information you could provide would be highly appreciated!
Thank you!
-
The queue length is how many packets may be buffered at any given time for that queue. If a burst of packets come in faster than they can be processed, the queue fills up and drops the extras.
Simply described, CoDel uses a time based queuing instead of size based. It will buffer up to 5ms of packets, then start probabilisticly dropping packets at and increasing rate until it finally finds a packet that has not been queued for over 5ms. Instead of a hard stop, it slowly ramps up the pressure more and more until it finally gets things back to "normal".
This gives a few benefits. One of them is it doesn't cause global TCP synchronization because only some TCP flows get affected, and they get affected at different times relative to each other instead of all at the same time, causing them all to back-off and speed up at the same time. Another benefit is a single large flow can't get to monopolize the buffer, because a flow that fills the buffer first, typically backs off the least because fewer of its packets get dropped.
-
So would I increase queue length and enable CoDel or just do one or the other?
Is there a way of determining how large the queue length should be? Or do I just want to keep it as small as possible?
Thanks
-
I'm not sure if the queue length is honored by codel or not. Assuming memory is not an issue, I'd just set the queue to 5,000 and make sure codel is used. Depending on how codel is actually implemented in FreeBSD, this may or may not be optimal, but it's still better than the default.
-
Thanks for the info, I will have to try this out.