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.
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
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.
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.
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.
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.