[LARTC] HTB classes: is it true that the rate of a parent MUST be exactly equal to the sum of rates

[LARTC] HTB classes: is it true that the rate of a parent MUST be exactly equal to the sum of rates

[Miernik]

When configuring HTB classes, is it true that the rate of a parent 
MUST be exactly equal to the sum of rates of it's children?

For example let's say I have a 160Kbit link, and two clients. I want 
each of them to have equal transfer rate, and ceil each of them to 
70Kbit. I leave 5% of the link idle as suggested on 
http://www.docum.org/stef.coene/qos/faq/cache/9.html

Lets compare two possible setups:

In setup A I assume that the rate of a parent class DOES NOT have to be 
equal to the sum of the rates of its child classes.

In setup B I assume that the rate of a parent class MUST be equal to 
the rates of its child classes.


Setup A:

tc qdisc add dev eth0 root handle 1: htb
tc class add dev eth0 parent 1:   classid 1:1  htb rate 150Kbit  ceil 150Kbit
tc class add dev eth0 parent 1:1  classid 1:2  htb rate  70Kbit  ceil  70Kbit
tc class add dev eth0 parent 1:1  classid 1:3  htb rate  70Kbit  ceil  70Kbit


Setup B:

tc qdisc add dev eth0 root handle 1: htb
tc class add dev eth0 parent 1:   classid 1:1  htb rate  80Kbit  ceil 150Kbit
tc class add dev eth0 parent 1:1  classid 1:2  htb rate  40Kbit  ceil  70Kbit
tc class add dev eth0 parent 1:1  classid 1:3  htb rate  40Kbit  ceil  70Kbit


Of course the correspnding filters to these, but I ommit them here, 
because it's not needed to show what I mean.

There are no other classeson eth0, and the filters are setupthis way 
that traffic can go either to class 1:2 or class 1:3 and nowhere else. 
There is no unclassified traffic.

In this situation: Are both setups valid? If yes are they equivalent? 
If not, then how the traffic will differ?

Does the rate of a parent class MUST be greater or equal than the sum 
of the rates of it children? 
Or does it have to be exactly equal? 
What happens if it is smaller? 
What happens if it is larger?

The reason I ask, is that I want to know, is it possible to add a 
third client to this setup, without changing the 1:1 class. Or do I 
have to recalculate and change the parent class, each time I change 
the rate of any of it's children?

If I add a third class, the setups will look like this:

Setup A:

tc qdisc add dev eth0 root handle 1: htb
tc class add dev eth0 parent 1:   classid 1:1  htb rate 150Kbit  ceil 150Kbit
tc class add dev eth0 parent 1:1  classid 1:2  htb rate  70Kbit  ceil  70Kbit
tc class add dev eth0 parent 1:1  classid 1:3  htb rate  70Kbit  ceil  70Kbit
tc class add dev eth0 parent 1:1  classid 1:4  htb rate  70Kbit  ceil  70Kbit


Setup B:

tc qdisc add dev eth0 root handle 1: htb
tc class add dev eth0 parent 1:   classid 1:1  htb rate 120Kbit  ceil 150Kbit
tc class add dev eth0 parent 1:1  classid 1:2  htb rate  40Kbit  ceil  70Kbit
tc class add dev eth0 parent 1:1  classid 1:3  htb rate  40Kbit  ceil  70Kbit
tc class add dev eth0 parent 1:1  classid 1:4  htb rate  40Kbit  ceil  70Kbit

Are both setups equivalent now?
Are they both valid?
If they are equivalent, then is one of them somehow better?
If they are not, then why?

If setup B is the only validsetup, then what if I want to add 50 
clients to this link, and also give each one a ceil of 70Kbit.
Each of them will use the link rarely, so statistically there will be 
no more then two clients on this link at the same time.
Should I then setup for each of the clinents   rate 3Kbit ceil 70Kbit :

tc qdisc add dev eth0 root handle 1: htb
tc class add dev eth0 parent 1:   classid 1:1  htb rate 150Kbit  ceil 150Kbit
tc class add dev eth0 parent 1:1  classid 1:2  htb rate   3Kbit  ceil  70Kbit
tc class add dev eth0 parent 1:1  classid 1:3  htb rate   3Kbit  ceil  70Kbit
tc class add dev eth0 parent 1:1  classid 1:4  htb rate   3Kbit  ceil  70Kbit
... and so on?

I've read http://www.docum.org and http://www.lartc.org/howto/ but I 
didn't find a strict anwser to this question.

-- 
    Miernik         ________________________ jabber:miernik@jabber.gda.pl
__ ICQ: 4004001 ___/__ tel: +48608233394 __/      mailto:miernik@ctnet.pl
Latest news about infringing people's freedom cases: 
http://www.stallman.org/

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HTB classes: is it true that the rate of a parent MUST be exactly equal to the sum of ra

[Stef Coene]

On Sunday 18 May 2003 12:39, Miernik wrote:
> When configuring HTB classes, is it true that the rate of a parent
> MUST be exactly equal to the sum of rates of it's children?
No.

> For example let's say I have a 160Kbit link, and two clients. I want
> each of them to have equal transfer rate, and ceil each of them to
> 70Kbit. I leave 5% of the link idle as suggested on
> http://www.docum.org/stef.coene/qos/faq/cache/9.html
You misunderstood the faq page.  If you have a 160kbit link, you have to make 
sure that you never send more data then lets say 150kbit.  So the maximum 
ceil of the classes is 150kbit.  This is to prevent that you send more data 
then your modem can handle.  

> Lets compare two possible setups:
>
> In setup A I assume that the rate of a parent class DOES NOT have to be
> equal to the sum of the rates of its child classes.
>
> In setup B I assume that the rate of a parent class MUST be equal to
> the rates of its child classes.
>
>
> Setup A:
>
> tc qdisc add dev eth0 root handle 1: htb
> tc class add dev eth0 parent 1:   classid 1:1  htb rate 150Kbit  ceil
> 150Kbit tc class add dev eth0 parent 1:1  classid 1:2  htb rate  70Kbit 
> ceil  70Kbit tc class add dev eth0 parent 1:1  classid 1:3  htb rate 
> 70Kbit  ceil  70Kbit
>
>
> Setup B:
>
> tc qdisc add dev eth0 root handle 1: htb
> tc class add dev eth0 parent 1:   classid 1:1  htb rate  80Kbit  ceil
> 150Kbit tc class add dev eth0 parent 1:1  classid 1:2  htb rate  40Kbit 
> ceil  70Kbit tc class add dev eth0 parent 1:1  classid 1:3  htb rate 
> 40Kbit  ceil  70Kbit
>
>
> Of course the correspnding filters to these, but I ommit them here,
> because it's not needed to show what I mean.
>
> There are no other classeson eth0, and the filters are setupthis way
> that traffic can go either to class 1:2 or class 1:3 and nowhere else.
> There is no unclassified traffic.
>
> In this situation: Are both setups valid? If yes are they equivalent?
> If not, then how the traffic will differ?
>
> Does the rate of a parent class MUST be greater or equal than the sum
> of the rates of it children?
No.

> Or does it have to be exactly equal?
No.

> What happens if it is smaller?
Nothing.

> What happens if it is larger?
Nothing.

> The reason I ask, is that I want to know, is it possible to add a
> third client to this setup, without changing the 1:1 class. Or do I
> have to recalculate and change the parent class, each time I change
> the rate of any of it's children?
No.

> If I add a third class, the setups will look like this:
>
> Setup A:
>
> tc qdisc add dev eth0 root handle 1: htb
> tc class add dev eth0 parent 1:   classid 1:1  htb rate 150Kbit  ceil
> 150Kbit tc class add dev eth0 parent 1:1  classid 1:2  htb rate  70Kbit 
> ceil  70Kbit tc class add dev eth0 parent 1:1  classid 1:3  htb rate 
> 70Kbit  ceil  70Kbit tc class add dev eth0 parent 1:1  classid 1:4  htb
> rate  70Kbit  ceil  70Kbit
>
>
> Setup B:
>
> tc qdisc add dev eth0 root handle 1: htb
> tc class add dev eth0 parent 1:   classid 1:1  htb rate 120Kbit  ceil
> 150Kbit tc class add dev eth0 parent 1:1  classid 1:2  htb rate  40Kbit 
> ceil  70Kbit tc class add dev eth0 parent 1:1  classid 1:3  htb rate 
> 40Kbit  ceil  70Kbit tc class add dev eth0 parent 1:1  classid 1:4  htb
> rate  40Kbit  ceil  70Kbit
>
> Are both setups equivalent now?
Yes.

> Are they both valid?
Yes.

> If they are equivalent, then is one of them somehow better?
Setup B

> If they are not, then why?
>
> If setup B is the only validsetup, then what if I want to add 50
> clients to this link, and also give each one a ceil of 70Kbit.
> Each of them will use the link rarely, so statistically there will be
> no more then two clients on this link at the same time.
> Should I then setup for each of the clinents   rate 3Kbit ceil 70Kbit :
>
> tc qdisc add dev eth0 root handle 1: htb
> tc class add dev eth0 parent 1:   classid 1:1  htb rate 150Kbit  ceil
> 150Kbit tc class add dev eth0 parent 1:1  classid 1:2  htb rate   3Kbit 
> ceil  70Kbit tc class add dev eth0 parent 1:1  classid 1:3  htb rate  
> 3Kbit  ceil  70Kbit tc class add dev eth0 parent 1:1  classid 1:4  htb rate
>   3Kbit  ceil  70Kbit ... and so on?
No.
As long as you are sure that you never send more data then your modem can 
handle.  So if you have only 2 active classes, you can take a bigger rate.

> I've read http://www.docum.org and http://www.lartc.org/howto/ but I
> didn't find a strict anwser to this question.
The reason why you have to take parent rate = sum of child rate is to just 
make it easier to find out what will happen.  The parent rate and ceil is 
never respected, so it doesn't matter what you take for parent rate and/or 
ceil.  But following the rules like suggested on my faq page, just makes it 
easier to found out how the bandwidth is divided.

You don't have to follow any of the rules I suggested.  It will work.  But 
finding out what will happen will be less obvious.

Stef


-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HTB classes: is it true that the rate of a parent MUST

[Martin A. Brown]

Miernik,

I'll add a bit to Stef's answer.

 : When configuring HTB classes, is it true that the rate of a parent
 : MUST be exactly equal to the sum of rates of it's children?

No.  This is not true.  This is merely a recommendation for how to use
HTB.  When the parent class ceil matches the total of all of the ceil
parameters of the children classes, there is no way for bandwidth usage to
exceed the parent ceil.

 : For example let's say I have a 160Kbit link, and two clients. I want
 : each of them to have equal transfer rate, and ceil each of them to
 : 70Kbit. I leave 5% of the link idle as suggested on
 : http://www.docum.org/stef.coene/qos/faq/cache/9.html

I have a clarification to make, which may help you understand all of the
answers to your questions:

   With HTB, shaping is only performed by the leaf class.  Why
   bother setting rate and ceil in parent classes?  The ceil is
   used by the parent class to lend bandwidth to the child
   classes [1].  In short, all non-leaf classes use ceil to cap how
   much bandwidth to lend to a child class.

[ example set one snipped:

  A: total child rate bandwidth does not exceed parent ceil bandwidth
     children are configured not to borrow
  B: total child rate bandwidth does not exceed parent ceil bandwidth
     children are configured to borrow

  ]

 : Does the rate of a parent class MUST be greater or equal than the sum
 : of the rates of it children?

No. (Note, that I assume you mean "Does the ceil of a parent..." because
the parent rate is not considered at all.)

 : Or does it have to be exactly equal?
 : What happens if it is smaller?

If the parent class ceil is smaller than the sum of the children ceil,
then the children can consume more bandwidth than the parent class appears
to allow.  This occurs because the parent class is never checked!  The
parent class is only checked if the child has exceeded rate and wishes to
borrow from the parent.

 : What happens if it is larger?

In the case that the parent class ceil is larger than the sum of the
children ceil, there is available bandwidth in the parent class.  That is,
a new child class could probably borrow bandwidth from the parent.

[ example set two snipped

  A: total child rate bandwidth exceeds parent ceil bandwidth
     children are configured not to borrow
  B: total child rate bandwidth does not exceed parent ceil bandwidth
     total child ceil bandwidth exceeds parent ceil bandwidth
     children are configured to borrow

  ]

 : Are both setups equivalent now?

I would disagree with Stef (note, Stef *does* have more experience with
HTB, so let's see what he says).  These setups are not equivalent.

 : Are they both valid?

Valid?  Yes.  Advisable?  No.

 : If they are equivalent, then is one of them somehow better?
 : If they are not, then why?

I'd agree with Stef...setup B is probably better.

 : If setup B is the only valid setup, then what if I want to add 50
 : clients to this link, and also give each one a ceil of 70Kbit. Each of
 : them will use the link rarely, so statistically there will be no more
 : then two clients on this link at the same time.

This seems to me the most natural use and leveraging of HTB.  It seems
like you are adding 1 class per client.  If this is so, the borrowing
rules of HTB will ensure that each class has fair access to the bandwidth
between sum ( rate of children ) and parent ceil.

 : Should I then setup for each of the clients rate 3Kbit ceil 70Kbit :
 :
 : tc qdisc add dev eth0 root handle 1: htb
 : tc class add dev eth0 parent 1:   classid 1:1  htb rate 150Kbit  ceil 150Kbit
 : tc class add dev eth0 parent 1:1  classid 1:2  htb rate   3Kbit  ceil  70Kbit
 : tc class add dev eth0 parent 1:1  classid 1:3  htb rate   3Kbit  ceil  70Kbit
 : tc class add dev eth0 parent 1:1  classid 1:4  htb rate   3Kbit  ceil  70Kbit
 : ... and so on?

Miernik--I would recommend this type of approach.  In your example,
though, you are using a rate which is below Devik's recommend minimum rate
for reliable operation of HTB [2].  Perhaps you could create 25 classes,
and put two IPs in each class.  That gives you a 6kbit rate for each child
class.

children classes  parent class
 #  rate  ceil    rate   ceil      notes
--  ----  ----    ----   ----     ----------------------------------
 2    70    70     150    150     *1 no B, p->L never exceeded
 2    40    70     150    150     *2 B, p->L never exceeded
 3    70    70     150    150     *3 no B, p->L might be exceeded
 3    40    70     150    150     *4 B, p->L never exceeded
50     3    70     150    150     *5 B, c->R probably too low
25     6    70     150    150     *6 B, maybe good model?

    c=child/children class(es)
    p=parent class
    B=borrowing
    R=rate (in kbit)
    LÎil (in kbit)

  *1: Because the rate of each child class is equal to the ceiling,
      no child class will try to borrow.  The sum of the child class
      rates, sum( c->R ), does not exceed the parent ceiling, p->L.
      The total transmitted traffic should be below p->L.
  *2: Each child will begin to borrow from the parent when it has more
      than 40kbit to send.  Note, also, that the sum of the child class
      ceil, sum ( c->L ), is still below the parent ceiling, p->L.  This
      means that the parent class will always have more bandwidth to offer
      than the children will request.  This means your clients would never
      use more than 140kbit total, leaving 10kbit of your (already
      conservatively estimated) 150kbit link.
  *3: This is a setup almost exactly like the setup in *1, but you now
      have three children, each of which will consume up to 70kbit
      (c->R = c->L).  This means that if all three children are sending
      traffic at their configured rate, the parent ceiling will be
      exceeded.  If you are using traffic control to prevent congestion on
      your uplink, this defeats your purpose.  *4 is a better solution
      if you want to use three classes.
  *4: This is similar to the setup in *2.  The sum of the rates of the
      children classes, sum( c->R ), is less than the parent's ceiling,
      p->L.  The children will always ask to borrow from the parent when
      they have more than 40kbit to send.  The parent class will divide
      bandwidth among each of the child classes as they request bandwidth.
      This model, where sum( c->R ) < p->L, provides the most natural
      use of borrowing with HTB.
  *5: This is almost the same model as *4.  The c->R, however is very low,
      perhaps lower than HTB can reliably handle.  Try *6.
  *6: A suggested alternative to *5, based on the same rules as *4.


Note, also, that I have some doubt [3] about the suggestion that
sum( c->R ) < p->R, because I didn't think that p->R was ever consulted
for borrowing purposes.  I hope the thread following my posting answers
this question, and sheds some more light on the use of HTB.

-Martin

 [1]  http://www.docum.org/stef.coene/qos/faq/cache/12.html
 [2]  http://luxik.cdi.cz/~devik/qos/htb/htbfaq.htm
 [3]  http://mailman.ds9a.nl/pipermail/lartc/2003q2/008592.html

-- 
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HTB classes: is it true that the rate of a parent MUST be exactly equal to the sum of ra

[Stef Coene]

On Sunday 18 May 2003 19:27, Martin A. Brown wrote:
> Miernik,
>
> I'll add a bit to Stef's answer.
:)

>  : When configuring HTB classes, is it true that the rate of a parent
>  : MUST be exactly equal to the sum of rates of it's children?
>
> No.  This is not true.  This is merely a recommendation for how to use
> HTB.  When the parent class ceil matches the total of all of the ceil
> parameters of the children classes, there is no way for bandwidth usage to
> exceed the parent ceil.
It's not the "total of all of the ceil", it's the maximum of all the ceil 
parameters of the children classes.
And you can exceed the parent ceil.  See me other post on this subject.  It 
can because the rate of a class is the minimum the class always gets.  Even 
if it exceeds the parent ceil.

>  : For example let's say I have a 160Kbit link, and two clients. I want
>  : each of them to have equal transfer rate, and ceil each of them to
>  : 70Kbit. I leave 5% of the link idle as suggested on
>  : http://www.docum.org/stef.coene/qos/faq/cache/9.html
>
> I have a clarification to make, which may help you understand all of the
> answers to your questions:
>
>    With HTB, shaping is only performed by the leaf class.  Why
>    bother setting rate and ceil in parent classes?  The ceil is
>    used by the parent class to lend bandwidth to the child
>    classes [1].  In short, all non-leaf classes use ceil to cap how
>    much bandwidth to lend to a child class.
This is true for the ceil.  But not for the rate.  The rate of the parent 
class is used to split the traffic.  See other post on the same subject for 
an example.  And I just realized that I stated before that the parent rate is 
never respected.  That's not true.  It is.  But I don't know how exactly.

> I would disagree with Stef (note, Stef *does* have more experience with
> HTB, so let's see what he says).  These setups are not equivalent.
Thx ;)

> Miernik--I would recommend this type of approach.  In your example,
> though, you are using a rate which is below Devik's recommend minimum rate
> for reliable operation of HTB [2].  Perhaps you could create 25 classes,
> and put two IPs in each class.  That gives you a 6kbit rate for each child
> class.
I think Devik means that this is a minimu rate for active classes.  And he 
states that there are only some of the classes active.  So the real rate will 
always > 6kbit.  As long as quantum is big enough, I don't think there will 
be a problem.

I deleted some parts of Martins answer.  My conclustion : I need to do some 
more tests to find out how the parent settings influence the children.

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HTB classes: is it true that the rate of a parent MUST

[Martin A. Brown]

 : >  : When configuring HTB classes, is it true that the rate of a parent
 : >  : MUST be exactly equal to the sum of rates of it's children?
 : >
 : > No.  This is not true.  This is merely a recommendation for how to use
 : > HTB.  When the parent class ceil matches the total of all of the ceil
 : > parameters of the children classes, there is no way for bandwidth usage to
 : > exceed the parent ceil.
 : It's not the "total of all of the ceil", it's the maximum of all the ceil
 : parameters of the children classes.

Hmmmm.....I think I see my error.  But I think we have an challenge in
accurately describing it.  So, to be unbelievable verbose:

  If the parent class "ceil" parameter matches (or is greater than) the
  sum of the "ceil" parameter for all of the leaf children (terminal
  HTB children), then there is no way for this parent's "ceil" to be
  exceeded.

This definition is halfway between the "maximum of all the ceil
parameters of the children classes" and the "total of all of the ceil",
both of which are inaccurate in different ways.  Do you agree, Stef?

( Martin wonders if Stef enjoys splitting hairs. )

 : And you can exceed the parent ceil.  See me other post on this subject.  It
 : can because the rate of a class is the minimum the class always gets.  Even
 : if it exceeds the parent ceil.

Agreed.

 : > Miernik--I would recommend this type of approach.  In your example,
 : > though, you are using a rate which is below Devik's recommend minimum rate
 : > for reliable operation of HTB [2].  Perhaps you could create 25 classes,
 : > and put two IPs in each class.  That gives you a 6kbit rate for each child
 : > class.
 :
 : I think Devik means that this is a minimu rate for active classes.
 : And he states that there are only some of the classes active.  So the
 : real rate will always > 6kbit.  As long as quantum is big enough, I
 : don't think there will be a problem.

Ah-ha!  This makes sense.  Thanks for the clarification.

-Martin

-- 
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HTB classes: is it true that the rate of a parent MUST be exactly equal to the sum of ra

[Stef Coene]

On Wednesday 21 May 2003 04:53, Martin A. Brown wrote:
>  : >  : When configuring HTB classes, is it true that the rate of a parent
>  : >  : MUST be exactly equal to the sum of rates of it's children?
>  : >
>  : > No.  This is not true.  This is merely a recommendation for how to use
>  : > HTB.  When the parent class ceil matches the total of all of the ceil
>  : > parameters of the children classes, there is no way for bandwidth
>  : > usage to exceed the parent ceil.
>  :
>  : It's not the "total of all of the ceil", it's the maximum of all the
>  : ceil parameters of the children classes.
>
> Hmmmm.....I think I see my error.  But I think we have an challenge in
> accurately describing it.  So, to be unbelievable verbose:
>
>   If the parent class "ceil" parameter matches (or is greater than) the
>   sum of the "ceil" parameter for all of the leaf children (terminal
>   HTB children), then there is no way for this parent's "ceil" to be
>   exceeded.
>
> This definition is halfway between the "maximum of all the ceil
> parameters of the children classes" and the "total of all of the ceil",
> both of which are inaccurate in different ways.  Do you agree, Stef?
>
> ( Martin wonders if Stef enjoys splitting hairs. )
What about ...
"The ceil and the rate of a class are respected, but the rate for each class 
is always satisfied."
I'm doing some tests to prove this.  But I have some strange results.  I think 
it's a quantum problem.  The restult is an error of 5-10% if I create 2 
classes with the same rate and quantum.  If a class sends more data then its 
rate, you use quantum.  And that's not accurate.

>  : And you can exceed the parent ceil.  See me other post on this subject. 
>  : It can because the rate of a class is the minimum the class always gets.
>  :  Even if it exceeds the parent ceil.
>
> Agreed.
>
>  : > Miernik--I would recommend this type of approach.  In your example,
>  : > though, you are using a rate which is below Devik's recommend minimum
>  : > rate for reliable operation of HTB [2].  Perhaps you could create 25
>  : > classes, and put two IPs in each class.  That gives you a 6kbit rate
>  : > for each child class.
>  :
>  : I think Devik means that this is a minimu rate for active classes.
>  : And he states that there are only some of the classes active.  So the
>  : real rate will always > 6kbit.  As long as quantum is big enough, I
>  : don't think there will be a problem.
>
> Ah-ha!  This makes sense.  Thanks for the clarification.
But to prevent problems, he should add quantum 1500 if he creates the classes 
to prevent sharing problems (this is only needed if quantum < 1500 if you jtb 
calculates the quantum).

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/