| |||||||||||||
The CHOKe packet schedulerThe CHOKe packet schedulerPosted Feb 28, 2011 3:24 UTC (Mon) by dlang (✭ supporter ✭, #313)In reply to: The CHOKe packet scheduler by gmaxwell Parent article: The CHOKe packet scheduler
if you are pumping data out a 10Gb pipe, you are unlikely to need this sort of thing. this is needed when the link you are sending out of is the bottleneck of the communications path.
allow this to be configured on a per-interface basis and you can disable it on your links where the hardware can barely keep up, but still have it in place where you are going to be buffering the data that you send.
(Log in to post comments)
The CHOKe packet scheduler Posted Feb 28, 2011 3:41 UTC (Mon) by gmaxwell (subscriber, #30048) [Link]
I wonder what bit of misinformation makes people think that simply because a link is fast that it won't be congested. This isn't the caseĀ and fast links tend to be major traffic aggregation points where fairness is a bigger issue, and where insufficient buffering can result in very costly under-utilization.
As I mentioned, in the sort of place where you're using a purely software forwarding path and where the design of CHOKe wouldn't be a performance impediment you could also do per-flow queuing which would be considerably more fair than CHOKe (and potentially much better for loss sensitive flows), perhaps falling back to CHOKe/SFB if the flow lookups become too expensive.
AFAIK, Linux doesn't even have a true per-flow qdisc though there have been patches and SFQ approximates it with acceptable performance. Can you suggest a case where CHOKe would be needed but the SFQ qdisc in Linux would be inappropriate?
|
|||||||||||||