[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