Am Tuesday 18 May 2004 17:42 schrieb Jan Wilson: > Unfortunately, we HAVE to break this down by client, and be able to track > bandwidth by client. In fact, by client, rather than by machine If I get this right, you want to know how much traffic each client caused, because they have to pay for it. This should be done independent of your actual traffic shaping strategy. You shouldn't need tc to count traffic? > What I was really asking is whether redistributing the buckets every 2 > minutes is a problem. I know the SFQ perturbs every 5 or 10 seconds, > so 2 minutes seemed conservative, comparatively. You could add/remove classes on the fly as required. You probably should avoid removing all classes everytime a client becomes (in)active. But if you want to enhance quality and P2P traffic really is a problem, I don't see another way than to move this traffic away from the user classes. In my own script, I put P2P into user class, because it's intended for small home network. Imagine you have 5 users, even if 4 have P2P running to max the line out, the 5th user still gets 1/5th of bandwidth guaranteed, which is probably enough. With 80 user, he'd only get 1/80th, which probably isn't enough to do anything useful. Of course, it also depends on the total bandwidth of your line and your client's requirements. I've never worked with big networks, but I imagine that P2P traffic there is pretty much unwanted. So why do you want to allow P2P traffic eating 99% of your line? Sure, if you limit P2P to say 25% of your line, paying users may complain about bad P2P performance - but that's still better than all users complaining about bad overall performance in general. Andreas _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
