On Thu, Jul 7, 2011 at 4:29 PM, Michael C. Robinson < [email protected]> wrote:
> Yes, fairness is hard to define. > > To keep fairness simple, no priority queueing where paying more means > more bandwidth. > > I was thinking I need the queue target to decide in real time whether > or not to favor host b over host a for example. My thought is the > following, keep track on an hourly basis who has used the most > bandwidth and if there is a decision between letting that host > through verses another host, the other host goes. Of course this has > to extend for multiple hosts, so the packet counts have to be compared > to choose who should get through right now. Another idea is to reduce > packet speed for people doing large downloads so that there is some > bandwidth left for the other hosts. > One has to remember that bandwidth control is not about bandwidth as each packet at a time will consume the full bandwidth of the pipe at the point in time that it is being sent or received. You have to think about it more like a train on a track or a single lane one-way highway. How often do you need to interrupt the frieght train or tractor-trailer convoy to insert something else. If those big/long connections are not there then nothing should or needs to be slowed down. iptable rules with tc queuing rate controls will be your friend (or fiend if you can't understand it) here. > I'm trying to divvy up two broadband connections between up to 4+ hosts > at a time. > If you are just wanting to gauge the usage by host in snapshot monitor mode then iftop with a filter or two should get you there. > > Another thought to control the impact of a mail flood is to set a > maximum saturation level. If you know how many packets you can handle > instantaneously, it should be possible to signal a slowdown when a limit > is reached. Whether the slowdown needs to happen at the packet layer or > Postfix should be sending an I'm not ready message is not clear to me. > > I'm interested in the QUEUE target because spamcannibal uses it and > getting spamcannibal working is on my todo list. > > I originally wanted to do the simplest thing I could think of which was > a strange idea because there are easier ways to do it than queueing > packets to user space. > > So the critical goal is to get spamcannibal to learn which means that it > needs to catch email packets as they come in. Having a better handle on > bandwidth usage and/or more than that, that is something that seems > related to getting spamcannibal working. The point of spamcannibal is > to slowdown email trouble makers. Is there a way to log whether or not > packets are coming to user space and track down whether or not they are > being picked up properly? > > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug > _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
