Hi, I just realized that buffer is converted to time by tc before it's send to HTB. In the old version of HTB it's the limit of how much data measured in time can be sent at once(in 1 time unit). Basicly buffer value is used as fine control of the speed limiting, which define the peak rate measured in a smaller unit of time.
So It's still possible just change the kernel code to choose a fine control time unit and then multiply to calculate the amount of data or let user pass this value to the kernel (via tc, however). But then the workaround of "+ mtu" will be a new problem. 2012/6/20 YANG Zhe <yangzhe1...@gmail.com>: > 2012/6/20 Stephen Hemminger <shemmin...@vyatta.com>: >> On Wed, 20 Jun 2012 10:27:37 +0800 >> YANG Zhe <yangzhe1...@gmail.com> wrote: >> >>> Hi Thomas, >>> >>> I read the htb code before so I'll show the problem here. >>> >>> When tc comes to calculate buffer & cbuffer, it set lookup get_hz() >>> and set buffer = rate / get_hz() + mtu. >>> >>> But nowadays, packet scheduling (sched) in kernel employ hrtimer so >>> that the old limit of activity only HZ (100) times per second is >>> removed. Also get_hz() returns 10^9 so that tc pretend that sched >>> start 10^9 times per second. So buffer would be set to no more than >>> mtu. >>> >>> But hrtimer doesn't work by this way. So every time htb starts, it can >>> only send about 2 packet and because of sched won't start too >>> frequently, the desired rate can't be reached. >>> >>> I would suggest that buffer should be manually set by user, and >>> converted to 10ms amount of data by default in future version of tc. >>> >> >> What about backward compatibility with older kernels. Maybe the >> kernel should just be fixed instead. > > Good point. tc communicate to htb by the netlink socket. > buffer/cbuffer value is set by tc because (old and present version of) > htb require it. So that for backward compatibility tc should just add > a few checks for example if get_hz() may return 10^9 or 10^6, fallback > to 100, which in another word means 10ms. > > -- > Sincerely, > Yang Zhe -- Sincerely, Yang Zhe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
