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<koh...@cs.ucla.edu> > To: R H<rajamha...@yahoo.com> > Cc: "cl...@pdos.csail.mit.edu"<click@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<lars...@gmail.com> >> To: R H<rajamha...@yahoo.com> >> Cc: cl...@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<rajamha...@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@amsterdam.lcs.mit.edu >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>> >> _______________________________________________ >> click mailing list >> click@amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click > _______________________________________________ > click mailing list > click@amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click _______________________________________________ click mailing list click@amsterdam.lcs.mit.edu https://amsterdam.lcs.mit.edu/mailman/listinfo/click
