On Fri, Dec 07, 2001 at 08:15:34AM -0800, Don Cohen wrote: > [from new doc] > Besides being classful, CBQ is also a shaper and it is in that aspect > that it really doesn't work very well. It should work like this. > I've not noticed that it doesn't work well. Perhaps cause I'm > accidentally using the right parameters? Perhaps because you happen to use it in the circumstances it works well for. As Devik said, he knows many cases in which CBQ missed the mark - he can always explain them, and often suggest fixes, but it is not a 'surefire' algorithm. > If you try to shape a 10mbit/s connection to 1mbit/s, the link should > be idle 90% of the time. If it isn't, we need to throttle so that it > IS idle 90% of the time. > Which is the way it does work, as far as I can tell. Yes, this is how it should work. Now imagine a busy ethernet segment with a lot of colisions. CBQ is configured with 'bandwidth 100mbit/s'. Because the ethernet is busy, the network card has a hard time getting 5mbit/s out of the door. We are trying to shape traffic to 2Mbit/s, so the link should be idle 98% of the time if we are sending at the configured rate. Now, because the effective bandwidth has decreased to 5Mbit/s, at 2Mbit/s, the link appears *far* too busy - it is idle only 60% over time! In fact, in this situation, CBQ will shape our traffic to 100kbit/s, which isn't even *close* to the configured 2mbit/s. Now, I admit that not many segments will be as busy as this. But do you see my point? The effectively available bandwidth determines how we shape. In many cases, you don't notice this. If you are talking to a switch, for example, your ethernet will be pretty empty except for you. You *will* get dequeued at a rate of 100mbit/s - *if* your network adaptor is up to it. If your computer is busy with other things, or has a crappy bus or network adaptor, CBQ may not be dequeued at 100mbit/s either, in which case too it will do crazy things. > I can't believe this dependence on packet size since I've always had > good results using the same default packet size even though different > tests use very different packet sizes. Ok. Let's see what the kernel does with avpkt. It doesn't do anything with it. This is truly marvelous :-) It takes great care to copy avpkt to the kernel. As far as I can tell, avpkt is only used to calculate maxidle. So I retract the packet size dependency statement. It was wrong. > (* 1042 8 40 .1)=33.3kpbs, again pretty close (tests) > Finally, data size 1 gives me 981 replies over 10 seconds (this time I > have to increase the rate in order to saturate the limit) > (* 43 8 981 .1)=33.7kbps > > It's clearly not counting every packet as the same size!! Thanks for testing this! > bandwidth > The physical bandwidth of your device, also needed for idle time > calculations. > > Notice above I supplied bandwidth 30kbit which is far from the actual > physical bandwidth (100Mbit). Maybe this is why I get good results. > Maybe this is what you're SUPPOSED to do! Not that I'm aware of. > Recall in the experiment I reported to lartc 10/10 the correct > bandwidth ended up giving me about twice the rate. I don't see from > above explanation why that should be, but again it suggests that this > parameter really ought to be set to the desired rate. I've succeded into bullying some of the kernel people (Hi Jamal :-)) into reading over the HOWTO and manpages - we will soon know. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services Trilab The Technology People Netherlabs BV / Rent-a-Nerd.nl - Nerd Available - 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
