Hi grubs, thanks for trying it out
I guess I should post some more info on what each of the fields represent for those that are not familiar with bandwidth shaping
ClearOS uses virtual intermediate queing devices to apply traffic shaping rules too. All incoming (or 'download') traffic from the WAN is passed through IMQ1, all outgoing (or 'upload') traffic from the WAN is passed through IMQ0. These rules are created in the mangle table of iptables.
On each of these 'virtual devices' bandwith rules are applied to prioritise or shape traffic as it passes through. It is important that your upload or download speeds defined in the webconfig are kept *below* your actual throughput to ensure that queues of traffic do not get stuck in your modem and are controlled by the queuing devices. (approx 90% of your actual bandwdith works well for me and I have relatively stable up/down speeds). I should emphasise here that bandwidth management is not about getting faster uploads out of your connection, it's about ensuring that traffic is shared among all services so that none can use it at the expense of the others, with a preference to some of those services.
So on each IMQ device, there are several classes of 'qdiscs' which are used to lump traffic into based on your webconfig rules. The clearos bandwdith rules create filters - one for each class so that traffic is matched and placed into one of these classes. These are arranged in a tree like heirachy, so you can have more than one 'tier' of bandwidth classes - however ClearOS uses one.
Class 1:1 is the root or parent class, i.e. the top of the tree - and has your ceiling limits applied to it. Class 1:2 is a special class for all other traffic that doesn't match your other rules. User defined bandwdith rules start at 1:10, 1:11, 1:12 etc. All of these classes are children of the parent 1:1 class.
This heirachical behaviour is important as when a class needs more traffic than it's specified rate, it will ask the parent to borrow more. The parent class will then lend some traffic from the other classes which are not in use. A class can borrow more traffic up to it's specified limit - which is the ceiling rate. The ceiling rate maybe the same as the parent or at some lower value if you have chosen to cap this class to a slower value. When several classes need to borrow more traffic - the parent class will apportion it between them based on their priorities as set in the webconfig. higher priorities getting traffic before other classes.
So a class which consistently borrows more packets (as shown in the list) is consistently requiring more traffic than it's specified rate.
A class which is consistently lending packets is not using as much as it's specified rate.
Overlimits, shows how many times a class was asked to send a packet but he can't due to rate/ceil constraints (currently counted for leaves only).
Rate, tells you actual (10 sec averaged) rate going through the class.
Lended, is # of packets donated by this class (from its rate) and Borrowed are packets borrowed from parent class.
Backlog of packets can occur when your connection is saturated by other classes or your upload (actual) speed has lowered below your ceiling rate. Backlogs of packets are not good and should be investigated
There are several other parts to it which are hard coded into the webconfig - such as burst levels. These control how much data a class can temporarily send quickly or in a 'burst' over and above the rate or it's ceiling rate. HTTP is an example of very bursty type of traffic
Some practical guidlines on creating rules then:-
Define bandwidth rules for all traffic that you consider to be essential to your server. For example on my cable line with a limited upload I have DNS, SSH, SMTP, Web uploads, FTP and my PS3 all set to high priority with a small rate so that they can always pass traffic and more importantly keep the latency down. I then have torrents set to a lower ceiling value (i.e. rate capped) and use transmission which only uses one port for it's transfers. All remaining traffic is then left in class 1:2 and dealt with on a round robin scnario based on it's QOS fields.
So on a well configured connection - when your upload is 'maxed out' you should still be able to run all these services, and still be able to browse the web, use SSH connections, have quick and responsive DNS and host other bulk transfer traffic. The same principles apply to VOIP which also requires low latency conenctions.
Hope that helps
For more details see many of the guides on the web....