Rui Prior wrote:
> This quickly made me conclude that it was the queuing on the device driver:
> in fact, for CBR flows the nicstar driver uses queues with 64 entries, and
> uses 2 entries per AAL5-PDU sent => queue size = 32 packets.
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.
> My question is: is there a better option? Should the ATM driver avoid queuing?
> I know I can trade off a bit of bandwidth for much lower delays by using a
> TBF with a rate just below that of the link as the outer qdisc, but I feel
> this is not the Right Thing...
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 ... ;-)
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH Werner.Almesberger@... /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
|