On Fri, Jul 30, 2010 at 9:24 AM, Darryl Miles <darryl-mailingli...@netbauds.net> wrote:
> I don't understand the relevance of your citation as an argument against > anything I've said. What is your understanding of the mechanism I described > and what is your understanding of section (9.2.2) in relation to that ? After reading the wiki page and re-reading section 9.2.2 I don't see anything to suggest that the tbf is intentionally delaying packets. In fact, my understanding (and experience) is that by using it to shorten your egress queue you will actually see reduced latency and improved interactivity on a congested interface. While tbf is constantly filling a bucket of tokens, the tokens themselves are not packets. A packet leaving the interface in question is matched to a token, if available, then queued for transmission. At this point the packet is out of the control of tbf. Although you can create a long (and therefore laggy) queue through tbf, any latency introduced as a result is not the express purpose of the qdisc. At least that's my undertanding. I used tbf as my WAN parent qdisc for some time with great satisfaction, until an apparent incompatibility arose between it and libtorrent, whereby torrents would slow to a crawl when tbf was active. > Maybe the wiki page http://en.wikipedia.org/wiki/Token_bucket would be more > useful at explaining the general concept in the context of using it to "rate > limit" throughput so that the router device is never stressed. Which is the > topic of this thread. Thanks for the link. I'm not trying to discount the hypothesis that tbf may be part of the problem in question, only the stated mechanism of action. Sorry to be off topic, but I didn't want anybody to go away with the wrong idea about tbf, even if that person was me. db _______________________________________________ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
