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

TC calling sequence timing

Hello all,
I would write about a bug or let's say a special behavior that exists in
the call sequence of the tbf qdisc and I imagine in general in the
kernel traffic control call sequence.
(Configuration: kernel 2.2.13, iproute 990630, ds 6, atm0.59)
I am working on a modified version of tbf and i have noticed the
following behavior:
If the incoming to the tbf shaper rate exceeds the tbf rate, more
packets come in from the ones tbf can transmit, the call of the enqueue
function triggers correctly the dequeue fuction, that is; dequeuing of
packets occurs at the time stamps that should. (lets say for a 1024
timer, packet size 800, tbf rate = 80kbps, incoming packet rate 160kpbs
we have a packet transition at a period of 10ms). (tg was used as a
traffic measurement & genetation tool)
If on the other hand, the rate doesn't exceed the tbf rate (lets say if
the source enters an off rate period, and there are still packets for
transmission at the qdisc's queue) dequeue its not called when it should
The exact behaviour that I have noticed in my    qdisc is that dequeue
is not called every EOI or successful packet transmition, but at a
probabilistic and greater time than the proper one, usual times are
around 150 ms). The really curious thing is that for the first packet
transmission, dequeue is called immediately after (at the same ms) and a
packet to be transmitted is scheduled at the proper time (10 ms after).
When this packet is finally succesfully dequeued 10ms after, dequeue is
not called immediately again by EOI, in order to program another timer
event but it is called after the random period of time I wrote about
Even if the outcoming traffic is not above the tbf rate, the traffic
produced is not as smooth as it could be, because if appears as maximum
rate bursts at random intervals with mean rate upper bound the tbf rate.

This misbehaviour may or may not be a bug but anyway I am (and I imagine
lot of other people that do linux programming, or use it as a qos
router) interested for an explanation or a tip.
Sorry to bother you, especially the kernel developers on the list, but I
would deeply appreciate any help or tip.
Thank you all in advance

Panagiotis G.Stathopoulos
National Technical University of Athens
Telecommunications Laboratory
E-mail: pstath@telecom.ntua.gr
Tel: +30 1 772 1479     Fax: +30 1 772 2534