jamal wrote: > On Tue, 2006-20-06 at 02:54 +0200, Patrick McHardy wrote: > >>jamal wrote: >> >>>- For further reflection: Have you considered the case where the rate >>>table has already been considered on some link speed in user space and >>>then somewhere post-config the physical link speed changes? This would >>>happen in the case where ethernet AN is involved and the partner makes >>>some changes (use ethtool). >>> > > [..] > >>I've thought about this a couple of times, scaling the virtual clock >>rate should be enough for "simple" qdiscs like TBF or HTB, which have >>a linear relation between time and bandwidth. I haven't really thought >>about the effects on HFSC yet, on a small scale the relation is >>non-linear. > > > Does HFSC not depend on bandwith? How is rate control achieved? "Depend on bandwidth" is not the right term. All of TBF, HTB and HFSC provide bandwidth per time, but with TBF and HTB the relation between the amount of bandwidth is linear to the amount of time, with HFSC it is only on a linear on larger scale since it uses service curves, which are represented as two linear pieces. So you have bandwidth b1 for time t1, bandwidth b2 after that until eternity. By scaling the clock rate you alter after how much time b2 kicks in, which affects the guaranteed delays. The end result should be that both bandwidth and delay scale up or down proportionally, but I'm not sure that this is what HFSC would do in all cases (on small scale). But it should be easy to answer with a bit more time for visualizing it. The thing I'm not sure about is whether this wouldn't be handled better by userspace, if the link layer speed changes you might not want proportional scaling but prefer to still give a fixed amount of that bandwidth to some class, for example VoIP traffic. Do we have netlink notifications for link speed changes? _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
