Very Computer

> I am using traffic control with a 2.6.26 kernel. During my testing, I
> am intentionally sending in more best effort traffic than my hardware
> can handle and I am seeing that the traffic control is dropping it, as
> it should.  Occasionally, I see a dip in the traffic in the queues I
> have defined for higher priority traffic.  This traffic is running
> below the minimum rate.  When this happens, I see the following qdisc
> statistics (sampling every 3 seconds):

> qdisc htb 9997: root r2q 10 default 9999 direct_packets_stat 0

> > I am using traffic control with a 2.6.26 kernel. During my testing, I
> > am intentionally sending in more best effort traffic than my hardware
> > can handle and I am seeing that the traffic control is dropping it, as
> > it should. ?Occasionally, I see a dip in the traffic in the queues I
> > have defined for higher priority traffic. ?This traffic is running
> > below the minimum rate. ?When this happens, I see the following qdisc
> > statistics (sampling every 3 seconds):

> > qdisc htb 9997: root r2q 10 default 9999 direct_packets_stat 0

> Not sure what the problem is (if it is a problem).

> Remember when you set a default with htb that (unless you filter to
> elsewhere) arp will also go to that class, which if low prio may cause
> you problems.

> > > I am using traffic control with a 2.6.26 kernel. During my testing, I
> > > am intentionally sending in more best effort traffic than my hardware
> > > can handle and I am seeing that the traffic control is dropping it, as
> > > it should. ?Occasionally, I see a dip in the traffic in the queues I
> > > have defined for higher priority traffic. ?This traffic is running
> > > below the minimum rate. ?When this happens, I see the following qdisc
> > > statistics (sampling every 3 seconds):

> > > qdisc htb 9997: root r2q 10 default 9999 direct_packets_stat 0

> > Not sure what the problem is (if it is a problem).

> > Remember when you set a default with htb that (unless you filter to
> > elsewhere) arp will also go to that class, which if low prio may cause
> > you problems.

> The problem is, for example, that a non-default htb queue with a rate
> defined as 100000bits/sec which is getting 90000bits/sec of data only
> lets about 20000bits/sec through while this behavior is seen. ?Could
> arp have this effect?

> > > > I am using traffic control with a 2.6.26 kernel. During my testing, I
> > > > am intentionally sending in more best effort traffic than my hardware
> > > > can handle and I am seeing that the traffic control is dropping it, as
> > > > it should. ?Occasionally, I see a dip in the traffic in the queues I
> > > > have defined for higher priority traffic. ?This traffic is running
> > > > below the minimum rate. ?When this happens, I see the following qdisc
> > > > statistics (sampling every 3 seconds):

> > > > qdisc htb 9997: root r2q 10 default 9999 direct_packets_stat 0

> > > Not sure what the problem is (if it is a problem).

> > > Remember when you set a default with htb that (unless you filter to
> > > elsewhere) arp will also go to that class, which if low prio may cause
> > > you problems.

> > The problem is, for example, that a non-default htb queue with a rate
> > defined as 100000bits/sec which is getting 90000bits/sec of data only
> > lets about 20000bits/sec through while this behavior is seen. ?Could
> > arp have this effect?

> I ran the test again. ?Actually the traffic from the non-default
> queues goes to 0 at the same time that the backlog number goes down
> and the number of packets dropped stays constant.

> Looking at the statistics for the classes, I can see that all of the
> queues, including the default queue, stop sending data during this
> period.  The data I am seeing from the default traffic was from data
> previously buffered up in our system.

> > Looking at the statistics for the classes, I can see that all of the
> > queues, including the default queue, stop sending data during this
> > period. ?The data I am seeing from the default traffic was from data
> > previously buffered up in our system.

> I would test without using a default class. Just make a catch all tc
> filter with a prio/pref higher than any others (1 is first for filters
> not 0) to direct ip traffic to 9999.

>>> Looking at the statistics for the classes, I can see that all of the
>>> queues, including the default queue, stop sending data during this
>>> period.  The data I am seeing from the default traffic was from data
>>> previously buffered up in our system.

>> I would test without using a default class. Just make a catch all tc
>> filter with a prio/pref higher than any others (1 is first for filters
>> not 0) to direct ip traffic to 9999.

> I just tried that and the higher priority classes end up losing
> packets.

> >>> Looking at the statistics for the classes, I can see that all of the
> >>> queues, including the default queue, stop sending data during this
> >>> period. ?The data I am seeing from the default traffic was from data
> >>> previously buffered up in our system.

> >> I would test without using a default class. Just make a catch all tc
> >> filter with a prio/pref higher than any others (1 is first for filters
> >> not 0) to direct ip traffic to 9999.

> > I just tried that and the higher priority classes end up losing
> > packets.

> But does it fix the everything stops problem?

> Maybe there is some other issue with the setup/tests that are causing this.

> Posting more details of the hardware, tests, results and the most
> simplified/stripped down htb setup that shows the problem would help.