Re: ATM performance vs. IP QoS

[Rui Prior <rprior@inescporto.pt>]

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 
suggestion?


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

Rui Prior