One other thing I noticed in all this, was that the overlimit count appears way, way off. I ran a test today, with the traffic generator creating a stream at 1mbit, and sent 187119 frames (64byte frames). It received 112208 frames at the other end. I was policing the stream to an effective 600kbit (3 MPLS paths each limited to 200kbit) rate. SNMP monitoring confirms that the rate is indeed approximately 600kbit (give or take a few bits for framing, etc). When I stopped the TG and looked at the stats as follows:
root@onc12:~> tc -s class show dev eth4 | grep -A 2 "1:00"
class cbq 1:100 parent 1:10 leaf 8007: rate 200Kbit (bounded) prio 1
Sent 2401024 bytes 37516 pkts (dropped 18633, overlimits 238775)
rate 10013bps 156pps
class cbq 1:200 parent 1:20 leaf 8008: rate 200Kbit (bounded) prio 1
Sent 2400960 bytes 37515 pkts (dropped 37325, overlimits 239212)
rate 9986bps 156pps
class cbq 1:300 parent 1:30 leaf 8009: rate 200Kbit (bounded) prio 1
Sent 2399872 bytes 37498 pkts (dropped 18632, overlimits 245800)
rate 9999bps 156pps
The total of the Sent and Dropped counts is 187119, as it should be. The problem is with the overlimit packets - each of the counts it itself way over the total # of packets sent.
The classes are cbq classes, and are using the default egress qdisc (a fifo if I'm not mistaken?) I've tried the same with a SFQ qdisc and the same thing happens.
> -----Original Message-----
> From: jamal [mailto:firstname.lastname@example.org]
> On Thu, 31 Aug 2000, Jonathan Earle wrote:
> > Unless I'm completely confused, and off-track, the
> > way I see the flow is something like:
> > - Packet enters box.
> > - Filter sees packet, sends it to the proper class.
> > - Class looks at the room (its rate specification) and says
> "Packet, you
> > cannot fit into this room, go away". The packet is dropped
> on the floor,
> > kicked and beaten to death by angry Narns, and counted as overlimit.
> No refer to above comments. This is what FIFO would do.
Do the qdiscs then handle the flow out of a class as well as determining the fate of packets already within a class?
> > - Class sends packets which are in the room (within the
> rate) to the SFQ,
> > which just dumbly sends them on their way, like an mall
> escalator would to
> > riders.
> If the class has a stashed TBF or CBQ it can do rate control
> othewise it
What do you mean by "stashed TBF or CBQ"?