On Tue, 2006-20-06 at 17:09 +0200, Patrick McHardy wrote: > jamal wrote:
> "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. > Ok, this makes things a little trickier though, no? > The thing I'm not sure about is whether this wouldn't be handled better > by userspace, If you do it in user space you will need a daemon of some form; this is my preference but it seems a lot of people hate daemons - the standard claim is it is counter-usability. Such people are forgiving if you built the daemon into the kernel as a thread. Perhaps the netcarrier that Stefan Rompf has added could be extended to handle this) Note, if you wanna do it right as well you will factor in other things like some wireless technologies which changes their throughput capability over a period of time ( A lot of these guys try to have their own hardware level schedulers to compensate for this). > 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? Not there at the moment - but we do emit event for other link layer stuff like carrier on/off - so adding this should be trivial and a reasonable thing to have; with a caveat: it will be link-layer specific; so whoever ends up adding will have to be careful to make sure it is not hard-coded to be specific to ethernet-like netdevices. It could probably be reported together with link state as a TLV like ETHER_SPEED_CHANGED which carries probably old speed and new speed and maybe even reason why it changed. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
