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

[don-lartc@isis.cs3-inc.com (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/