[Click] How works Polling?? more details...

[Giorgio Calarco]

hi,

i try to clarify what Alessandro has written, since to whole
problem is just a bit more complicated...

We are making some measurements about the (click) packets' latency
(the configuration installs an RFC1812 router - the output fifo is 200
elements long). We are varying the packets size and rate to try to have a
more
general idea about performance and bottlenecks. The packet flow is
unidirectional, thus we can talk about an "input nic" and an "output nic"
in the following...

Thus, briefly (not so much...):

- using short 64 byte packets and increasing the rate, we have "missed
frames" in the input nic. We suppose this is related to a memory performance
bottleneck (the input nic cannot transfer anymore packets to memory ->
it has no more DMA descriptors -> the DMA ring buffer is a memory
contained structure -> that's why we suppose the limiting factor is memory).

- now, the "problem": using long frames (1518 byte), we don't have any
missed frame in the
input nic, but... an enourmously varying latency. The growing part of the
delay
is due to the output queue (from 2us to 2 ms). So, the only reasonable idea
we have is the
the "pull process" has some problems... but why ?
Considering we have a 32bit/33MHz PCI bus (thus 1024 Mbit/s as a
throughput),
we can suppose to need about 12us to move the packet from the input nic
to memory. Then, we take about 1.2us to "route" it and put it in the output
queue. Then, other 12 us to move it to the output nic. At all, 25us.
The top rate when can reach (with reasonable queue delay values - about 2.6
us)
is 37000 pps, when we increase it just a bit (38-40000 pps) the queue delay
grows up to 200-2000 usec !
At 37000 pps, the inter-arrival packet interval is 27 us. Thus, injecting
1518 byte packets at 37000 pps, we are making the PCI bus very
busy... just 2 us of margin... what could happen if an other periferal takes
the bus with a so limited margin?

First idea : the pull phase is delayed due to "external bus activities"...
If delayed too much, can also be its scheduling time cancelled ?
I mean, if the pull process (for transferring the packet from the queue to
the output nic) is delayed too much, can the control return to the push
phase ?
This would make packets accumulate in the output queue, since i get them in
and never have time to send them out from the router... it this possible ?
(I don't know how the stride scheduler works


Second idea: if the pull phase cannot be cancelled and is strictly
sequential to the
push phase, the only idea can be that the "external bus activities" delay
the push-pull
phases a bit for each incoming packet. After some time, the packet routing
activity
"slides" in comparison with the packet arrivals, which continues to be
sinchronous.
Under these conditions can the output queue fill more & more? If so, making
it empty again
should take a lot of time ( mmm, 200 * 12 usec = 2.4 ms ...).


Did I say lots of silly things ?
Any idea or suggestion ? Anyone has noticed this effects before ?


thx

giorgio



Ing. Giorgio Calarco
DEIS - Università di Bologna
Viale Risorgimento, 2 40136 Bologna - Italy
Tel: 051 2093776 Fax: 051 2093053
E-mail: gcalarco at deis.unibo.it
PGP: http://www.deis.unibo.it/GCalarco/Giorgio_Calarco.asc