[LARTC] more on cbq parameters

[don-lartc@isis.cs3-inc.com (Don Cohen)]

While I'm thinking about that review of howto changes, here are a few
other responses about things I don't believe.  I'll be interested in
more info if anyone has any.

==
[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?
  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.

  This is pretty hard to measure, so CBQ also needs to know how big an
  average packet is going to be, and instead derives the idle
  time from the number of microseconds that elapse between requests from
  the hardware layer for more data. Combined, this can
  be used to approximate how full or empty the link is. 

 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.  

     tc class add dev eth1 parent 10:100 classid 10:2 cbq \
     bandwidth 30Kbit rate 30Kbit allot 1514 weight 30Kbit prio 5 \
     maxburst 10 avpkt 1000 bounded
 I send ping packets with default data size (56 bytes) 
 which is 98 bytes per packet inc. mac, ip, icmp headers.  
[[new data to avoid problems with that in original reply]]
 In 10 seconds I get 413 replies,
 which I assume means 413 got sent (I enqueued 1000)
 That's (* 413 98 8 .1)2.3kbps, pretty close.
 Now I try 1000 bytes of data and get 40 replies over 10 seconds 
 (again enqueuing 1000 packets)
 (* 1042 8 40 .1)3.3kpbs, again pretty close
 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)3.7kbps 

 It's clearly not counting every packet as the same size!!

==
   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!

 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.

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/