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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
