Am Tuesday 18 May 2004 19:43 schrieb Jan Wilson: > Maybe a compromise ... I could have the script set up x number of > buckets and add/delete up to or down to a certain number of classes, > then flush all and recalculate and redistribute the bandwidth only > after the number of classes has exceeded or fallen below a certain > number. Well - HTB will work too even if the children rates added together don't equal the parent rate (Wondershaper is living proof ;-P), so probably recreating all classes is not necessary. It's more important that there are as few classes as possible (no class for inactive user). So you could try just adding a class when a user gets active and removing a class when a user gets inactive. I think there was someone on this list who had a script that worked like that with ~1000 users in total. People notice in my LAN (which has only 5 users) when I re-run my fairnat script (the machine it runs on is quite old, so it takes several second until everything is re-created, and interactive connections tend to get sloppy for a while after that), so I think it would be really bad if you did the same every 2 or somewhat minutes with so many users. > We would like to place the heavy uploaders into a tighter upload bucket, > without regard to whether the upload is P2P or something else (don't know > what). Sure, that sounds like a good idea. However, what exactly do you intend to do to 'tighten' things? > What I've seen on this list is that if we have to double or triple our > HTB buckets in order to use ipp2p, it might not be worth it for a > large network with limited bandwidth. Shaping on a user basis will only affect the P2P users. If you make an IPP2P class as child of the user class with low priority, the effect will be that the P2P user can still use interactive connections (because his own P2P traffic has lower priority). But for other users it won't matter, they don't know wether the traffic caused by users is P2P or something else. The only thing you could do on a user basis would be setting a hard ceil for P2P. That way, P2P traffic of a user could never cause the user class to borrow. But I don't recommend this setup - prioritizing interactive over P2P traffic is something the user should do at home. > Our bandwidth is SO expensive, we want to avoid adding additional > bandwidth as long as possible. It is also why we are using ADSL > rather than T1 or something. Adding bandwidth wouldn't change much anyway, as long as P2P and similar takes all the bandwidth there is. So this way or another you need a good solution to clean this traffic mess up. HTH Andreas _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
