* Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx> [040518 10:32]: > 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? Actually, we charge most clients the same, but we would like to restrict the bandwidth hogs somewhat, and in a throttling situation, be able to give some priority to clients who "behave". Do you mean that we should NOT be using the tc to count traffic? What instead? We are using a Python script that reads values using tc -s -d class show <device> Is there a better way? > 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. 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. > 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. We don't want to just drop all P2P packets, so I guess we will have to throttle it, since our P2P users will suck up all the upload that is available, 24 hours a day if allowed. 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). 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. If this is not accurate, I hope someone will correct me. > 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. What we would prefer is for the P2P user to complain because he/she is not downloading very fast, and then we can explain it is because they leave P2P running ... that may lead to some social engineering. 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. Thanks for your comments. -- Jan Wilson, SysAdmin _/*]; jan@xxxxxxxxxxx Corozal Junior College | |:' corozal.com corozal.bz Corozal Town, Belize | /' chetumal.com & linux.bz Reg. Linux user #151611 |_/ Network, PHP, Perl, HTML _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
