[Click] click 1.8.0 Unqueue2 -> 100% CPU usage

[Lars Bro]

Hello, Raja

I think, this is because of the way Click timers work. A Click timer
is *very* precise, and this is achieved by so to say "spinning on
gettimeofday()" For example, if You want to sleep 753.332 milisecond,
it wil sleep normally for the first 750 miliseconds, and then
busy-wait on the timer for the last three miliseconds. I dont know the
threshold, but you are requesting something to take place every
1000/75 = 13 miliseconds, which may mean that the process is
busy-waiting all the time, using all of the CPU. You can try changing
the 75 to below 50, I guess the limit is 20 msec.

You must remember that all other timers in Click are still just as
precise, so the only effect is that the Click process uses CPU. Click
itself does fine. You must also remember that the time-sharing
scheduler on your system will soon find out that the Click process can
easily be scheduled out in favor of other user processes.

You can try to do the same when a heavy compilation is also running on
that processor, and then watch the accuracy of the Click process. You
should come to the result that even when compiling, the Click process
is very accurate.

yours,
Lars Bro


On Thu, Jun 23, 2011 at 2:41 AM, R H <rajamhayek at yahoo.com> wrote:
> Hi,
>
> Using the following sample configuration, I get 100% CPU usage even after the InfiniteSource finishes sending the 100 packets; but if I replace Unqueue2 with Unqueue everything works well.  Looked at the documentation and they both default to pulling 1 packet when scheduled until there is nothing to pull.  What am I missing?
>
> s :: InfiniteSource(\<0800>, RATE 75, LIMIT 100, STOP false); //random numbers as long as it does not stop!
>
> q :: NotifierQueue(200);
> uq :: Unqueue2();
> p :: Print();
>
> d :: Discard;
>
> s->q->uq->p->d;
>
> Thanks,
> Raja
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>