[LARTC] sfq, queue len and dropped packets

[LARTC] sfq, queue len and dropped packets

[Mihai RUSU]

Hi

If I use sfq qdisc on a CBQ class I get a lot of dropped packets and the
backlog itr almost always to its full value: 128. From the HOWTO I
understand that the queue is at 128 packets, and SFQ shows 128/1024 flows
, but how can I increase that value ? I have tried ip link set txqueuelen
but this only increases the tx queue on the interface.

qdisc sfq d468: quantum 1514b limit 128p flows 128/1024 perturb 10sec
 Sent 373321530 bytes 477032 pkts (dropped 120119, overlimits 0)
 backlog 120p

How can I increase that 128p limit ?

Thanks

----------------------------
Mihai RUSU

Disclaimer: Any views or opinions presented within this e-mail are solely
those of the author and do not necessarily represent those of any company,
unless otherwise specifically stated.

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

Re: [LARTC] sfq, queue len and dropped packets

[Stef Coene]

On Wednesday 10 April 2002 17:26, Mihai RUSU wrote:
> Hi
>
> If I use sfq qdisc on a CBQ class I get a lot of dropped packets and the
> backlog itr almost always to its full value: 128. From the HOWTO I
> understand that the queue is at 128 packets, and SFQ shows 128/1024 flows
> , but how can I increase that value ? I have tried ip link set txqueuelen
> but this only increases the tx queue on the interface.
>
> qdisc sfq d468: quantum 1514b limit 128p flows 128/1024 perturb 10sec
>  Sent 373321530 bytes 477032 pkts (dropped 120119, overlimits 0)
>  backlog 120p
>
> How can I increase that 128p limit ?
You can find it on www.docum.org under FAQ.
You need to change the kernel source to do so.

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.openprojects.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] sfq, queue len and dropped packets

[Don Cohen]

  On Wednesday 10 April 2002 17:26, Mihai RUSU wrote:
  > If I use sfq qdisc on a CBQ class I get a lot of dropped packets and the
  > backlog itr almost always to its full value: 128. From the HOWTO I
  > understand that the queue is at 128 packets, and SFQ shows 128/1024 flows
  > , but how can I increase that value ? I have tried ip link set txqueuelen
  > but this only increases the tx queue on the interface.
First, are you sure you're not under attack?
If you are running a small network this seems implausible.
Also, the constant high backlog probably indicates that you're
just getting input faster than you can forward it.  In that case
increasing the queue length won't result in many fewer drops.
It will just increase average delay.

  > qdisc sfq d468: quantum 1514b limit 128p flows 128/1024 perturb 10sec
  >  Sent 373321530 bytes 477032 pkts (dropped 120119, overlimits 0)
  >  backlog 120p
  >
  > How can I increase that 128p limit ?
  You can find it on www.docum.org under FAQ.
  You need to change the kernel source to do so.
This tells how to decrease, not increase the limit (and the
explanation of why you'd want to makes no sense to me).
In order to increase the limit you have to not only increase
the queue "depth", but also change a type declaration, something
like sfq_index - from char to int.  There's a comment about that
in the code.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] sfq, queue len and dropped packets

[Mihai RUSU]

On Wed, 10 Apr 2002, Don Cohen wrote:

> First, are you sure you're not under attack?

Well, there many computers behind that class and we get a lot of flood
attacks each day, so there is no way to tell for sure if in that moment
there is an attack or not.

> If you are running a small network this seems implausible.

Its not small at all, several hundred of computers.

> Also, the constant high backlog probably indicates that you're
> just getting input faster than you can forward it.  In that case
> increasing the queue length won't result in many fewer drops.
> It will just increase average delay.
>

I see. What exactly do you mean with getting input faster than output? I
mean the SFQ class is on a CBQ which limits them already, do you mean that
even so the kernel tries to enqueue() more packets than the system (SFQ)
can deal with?

In that case I would have to see a high load on that computer but the load
its lower than 0.5 usually.

> This tells how to decrease, not increase the limit (and the
> explanation of why you'd want to makes no sense to me).
> In order to increase the limit you have to not only increase
> the queue "depth", but also change a type declaration, something
> like sfq_index - from char to int.  There's a comment about that
> in the code.

I usually dont have problems hacking into C programms but I dont get it
what does that comment means, with the 4k page limit. I mean I need a
formula to calculate to see if I would get over that 4k limit.

Thanks for the answer

----------------------------
Mihai RUSU

Disclaimer: Any views or opinions presented within this e-mail are solely
those of the author and do not necessarily represent those of any company,
unless otherwise specifically stated.

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

Re: [LARTC] sfq, queue len and dropped packets

[Don Cohen]

Mihai RUSU writes:
 > > Also, the constant high backlog probably indicates that you're
 > > just getting input faster than you can forward it.  In that case
 > > increasing the queue length won't result in many fewer drops.
 > > It will just increase average delay.
 > 
 > I see. What exactly do you mean with getting input faster than output? I
One example is that you have two interfaces, one is limited (either by
hardware or software) to 10Mbps and the other to 1Mbps.  Then if
traffic arrives on the faster one at, say, 2Mbps, you clearly won't be
able to forward it all out the slower one.  In that case you'd end up
with lots of dropped packets and long queues.

 > mean the SFQ class is on a CBQ which limits them already, do you mean that
 > even so the kernel tries to enqueue() more packets than the system (SFQ)
 > can deal with?
 > In that case I would have to see a high load on that computer but the load
 > its lower than 0.5 usually.
Unless you have either an unusually fast network or an unusually slow
computer, the bottleneck is more likely in the network than the cpu.

 > I usually dont have problems hacking into C programms but I dont get it
 > what does that comment means, with the 4k page limit. I mean I need a
 > formula to calculate to see if I would get over that 4k limit.
I think that increasing the 128 will require you to change the type
from char to int.  One of those arrays has 2 * sfq_depth elements.
The code could be fixed to not require changing the type until you
go over sfq_depth 256, but I think it'll be easier for you to just
change the type and not worry about it.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] sfq, queue len and dropped packets

[Mihai RUSU]

On Thu, 11 Apr 2002, Don Cohen wrote:

> One example is that you have two interfaces, one is limited (either by
> hardware or software) to 10Mbps and the other to 1Mbps.  Then if
> traffic arrives on the faster one at, say, 2Mbps, you clearly won't be
> able to forward it all out the slower one.  In that case you'd end up
> with lots of dropped packets and long queues.
>

Hmm, my setup has one fast eth incoming interface (no outgoing at all on
that interface) and one outgoing fast eth interface (there is no incoming
traffic on this one). They use the same driver and are very good hardware
(eepro100).

> Unless you have either an unusually fast network or an unusually slow
> computer, the bottleneck is more likely in the network than the cpu.
>

Oh, so 100Mbit its no problem for a 2xP3 1GHz ? :)

>  > I usually dont have problems hacking into C programms but I dont get it
>  > what does that comment means, with the 4k page limit. I mean I need a
>  > formula to calculate to see if I would get over that 4k limit.
> I think that increasing the 128 will require you to change the type
> from char to int.  One of those arrays has 2 * sfq_depth elements.
> The code could be fixed to not require changing the type until you
> go over sfq_depth 256, but I think it'll be easier for you to just
> change the type and not worry about it.
>

Ok, I'll look into it, thanks.

----------------------------
Mihai RUSU

Disclaimer: Any views or opinions presented within this e-mail are solely
those of the author and do not necessarily represent those of any company,
unless otherwise specifically stated.

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