* Ed Wildgoose <lists@xxxxxxxxxxxxxx> [040518 14:20]: > Jan Wilson wrote: > >Well, as I see it (which could easily be wrong), the problem is with > >setting up over 200 buckets, even though only 60 to 90, maybe, are > >active at any one time. With the limited bandwidth we have available > >(it is very expensive here), it makes rather tiny buckets. > > Yeah, but the buckets have a guaranteed bandwidth, and also get to share > the remaining bandwidth between them. So if you have 600 buckets, and > only two are active, then those two buckets should get half the > bandwidth each (if you set it up that way). Perhaps that's really > obvious, but just wanted to be sure I never mind anyone stating the "obvious" ... one person's obvious is another's "eureka" ;-) But I find it awkward, for our purposes, the way rate and ceil seem to work. If we theoretically have 200 clients, and all 200 are on, then we can set rate for 1/200 of the total ... in our case only about 10 kilobits per user. They CAN borrow up to ceil, yes. But since we are REALLY busy, we can't really do much to give one client more than another. However, if we KNOW only 50 are on right now, then we can give each of those a rate of 1/50, guaranteed. We can set ceil a little differently. And if we have bandwidth hogs, we can adjust things so it is fairer for all. Suppose we have invited 200 guests for dessert. So we make 200 tarts to be sure everyone gets one. But only 50 guests show up. So they eat their own tart, and then fight over the other 150 tarts. What if you could look at the total number of guests before they enter the dining room, make a quick assessment, and put two or three tarts on each plate instead of one. They still might squabble a bit over the remaining tarts, but not as much of a free-for-all as before. That is what I was thinking to do with my Perl script. > Also, I think you can do your accounting with firewall rules as well as > tc rules. It may be more flexible to seperate accounting from > throttling - perhaps it will give you more options to set this up. This is a really interesting idea ... if we can keep our accounting separate then it WOULD open up more possibilities. Maybe someone can point me in the direction of IP traffic accounting that we could use separate from the tc. > For example, you could setup the rules with the class of traffic at the > top and the users underneath, eg top level is "P2P", "bulk", > "interactive", and under each is a user class (or SFQ, etc). Now you > could limit the P2P to be only 1/3 of total bandwidth, which is then > fought over by the users (each will get a fraction depending on how many > others are using it, not how many classes you have). Perhaps for the > other classes even SFQ will be enough? I think I can see that ... if we don't have to put each customer into one (or two or three) different buckets. If we could even put groups of customers into buckets together, that might be good. But again, it seems like it would be handy to be able to dynamically change bucket sizes and whose packets go through them. > The howto mentions some examples of using hashing which may allow you a > concise way to setup these rules by IP for example (even though you > won't be accounting that way). I looked at that again, and I do see that it might be useful, especially if we can handle our bandwidth accounting separately. If anyone has a working example I could look at, I might actually have a chance of understanding it ;-) I have no trouble with the hex math, being an old assembly language programmer, but it isn't quite sinking in. > You then need to look to iptables to see if you can do some standard > rules to account for your traffic. Perhaps someone here could suggest a > neat way? That would be REALLY helpful. > Good luck. Would be interested to hear your final solution I promise there will be a link to a well-documented Perl script when I get something working. :-) Even if it is a static arrangement, I want to set it up with a script that can be adjusted easily when we have new customers, MAC address changes, additional ADSL modems, etc. Thanks lots for your suggestions. -- 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/
