[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TC calling sequence timing





On Tue, 4 Apr 2000, Panagiotis Stathopoulos wrote:

> Hi,
> Let me give you the script that generates this results, even if I believe this
> behaviour is not depended at
> the tbf parametrs but really at the scheduling and interupt mechanics of
> linux. I also must point out that this behaviour is not really a problem,
> because if other streams exist, as in a router, since packets from other
> streams enqueued will trigger the dequeue function of the device. But anyway
> is not the anticipated behaviour from what I have understand about kernel and
> tc so any conversation on it will clarify the kernel operation.
> 
> tc qdisc add dev $DEV handle 1:0 root tbf rate 80Kbps buffer 3Kb limit 40Kb
> DEV=atm0 or eth0 (it has been tested with both)

- You are right that arriving packets will clock out packets; with the
worst case being the HZ value; so you do have an upper bound time.

Several things you can do:
-Change the HZ value if you have >= Pentium pro. (careful: change from
100->1024)
-Select CPU as the clock source in pkt_sched.h

- Linux doesnt do the EOI functionality; but it should be easy to add;

Alexey, here's a thought, maybe a 2.5 thing:
- Make the TX completion schedule a tasklet;
*When the tasklet runs, it harvests things like tx/rx descriptors (i.e
move this out of the driver) as well as enforces a dequeue() for that
interface; 
Benefit is now the fast path is faster and the shaping is more accurate.

cheers,
jamal