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

[Eddie Kohler]

Thanks!  I've deprecated Unqueue2; it will be removed in a later version.

E


On 6/23/11 7:51 PM, R H wrote:
> Either way works for me.
>
> Thanks,
> Raja
>
>
> ________________________________
> From: Eddie Kohler<kohler at cs.ucla.edu>
> To: R H<rajamhayek at yahoo.com>
> Cc: "click at pdos.csail.mit.edu"<click at amsterdam.lcs.mit.edu>
> Sent: Thursday, June 23, 2011 7:15 PM
> Subject: Re: [Click] click 1.8.0 Unqueue2 ->  100% CPU usage
>
> BTW, I checked in a change that should make Unqueue2 listen to notifiers --
> but I still think it might be better to just remove Unqueue2 altogether.
>
> Eddie
>
>
> On 06/23/2011 07:11 PM, R H wrote:
>> Hi Lars,
>>
>> The same script works fine when replacing Unqueue2 with Unqueue without changing the InfiniteSource configurations.  So I don't think it is a timer issue.  As Beyers pointed out and looking at the source code, Unqueue2 does not listen to queue empty signals sent from the NotifierQueue and keeps checking for packets.
>>
>> Regards,
>> Raja
>>
>>
>> ________________________________
>> From: Lars Bro<larsbro at gmail.com>
>> To: R H<rajamhayek at yahoo.com>
>> Cc: click at pdos.csail.mit.edu
>> Sent: Thursday, June 23, 2011 1:51 AM
>> Subject: Re: [Click] click 1.8.0 Unqueue2 ->   100% CPU usage
>>
>> 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
>>>
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click