[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ATM performance vs. IP QoS
First of all, I worked around the problem by enforcing an artificial limit on
the queue size for CBR VCs. Maybe it would be nice to have some means of
configuring this limit at runtime, preferably on a per-vc basis. Any
> If the packets queued in the ATM driver are still accounted for by the
> ATM stack, you can limit the queue for that PVC with sndbuf <size>
> when creating the PVC.
What do you mean by "still accounted for by the ATM stack"?
The driver doesn't copy TX buffers, so SKBs are not freed by the driver until
they're effectively transmitted.
> In principle, you should generate data just at the rate set on the NIC, and
> use the buffers only to absorb jitter. (The rather generous buffers are
> there mainly for UBR.) So using TBF would actually be the right thing.
> But then, it's of course so much more convenient to use the ATM hardware
> for all the rate control ... ;-)
I was thinking of a temporary workaround for my QoS tests (now I've modified
the driver I don't need it anymore), so I was thinking of using a TBF as
outer qdisc. Of course I hadn't thought straight: as TBF is classless there's
no way to make it work as outer qdisc...