[Click] DelayUnqueue 100% cpu

[Eddie Kohler]

Fixed, thanks for the report.

Eddie


Robert Ross wrote:
> Looks like something is missing from the latest CVS.  routerthread will 
> not compile due to missing inline reference:
> 
>   CXX [M] routerthread.o
> /usr/local/src/click/linuxmodule/../include/click/master.hh: In member 
> function ‘void RouterThread::driver()’:
> /usr/local/src/click/linuxmodule/../include/click/master.hh:117: sorry, 
> unimplemented: inlining failed in call to ‘Timestamp 
> Master::next_timer_expiry_adjusted() const’: function body not available
> /usr/local/src/click/linuxmodule/../lib/routerthread.cc:416: sorry, 
> unimplemented: called from here
> make[3]: *** [/usr/local/src/click/linuxmodule/routerthread.o] Error 1
> make[2]: *** [_module_/usr/local/src/click/linuxmodule] Error 2
> make[2]: Leaving directory `/usr/src/kernels/linux-2.6.19.7'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/usr/local/src/click/linuxmodule'
> make: *** [linuxmodule] Error 2
> 
> Can someone post the source fix to the mailing list and/or commit fixes 
> to GIT/CVS?
> 
> Robert A. Ross
> DSCI Inc.
> 609-509-5139
> 
> 
> 
> -----Original Message-----
> From: click-bounces at pdos.csail.mit.edu on behalf of Eddie Kohler
> Sent: Tue 2/5/2008 5:40 PM
> To: Mike Scheutzow
> Cc: Click Mail List
> Subject: Re: [Click] DelayUnqueue 100% cpu
> 
> Hi Mike,
> 
> Thanks for this bug report.  I agree that 100 milliseconds is way too high.
> 
> I've checked in a change that not only reduces this sleeping threshold, but
> also hopefully improves Click's timer precision overall.  The change adjusts
> Timer check frequencies based on observed lag (how slow the machine is).
> 
> Let me know if it works for you.
> Eddie
> 
> 
> Mike Scheutzow wrote:
>  > Problem
>  >
>  > If I use either the DelayUnqueue or DelayShaper elements with Click
>  > userlevel, my cpu usage always pegs at 100%.
>  >
>  > This problem is present in both 1.6.0 and in the cvs repository
>  > (checkout on Jan 31, 2008).
>  >
>  > Solution
>  >
>  > The bug is in the code which decides whether the thread should sleep or
>  > not. A threshold of 100 milliseconds is way too high.
>  >
>  > In elements/standard/delayunqueue.cc and
>  > elements/standard/delayshaper.cc, I changed:
>  >
>  >       usec_to_subsec(100000)
>  > to:
>  >       usec_to_subsec(100)
>  >
>  > and everything works much better. Our kernel uses a 1 millisecond tick.
>  >
>  >
>  > Mike Scheutzow
>  > scheutzow at alcatel-lucent.com
>  >
>  > _______________________________________________
>  > 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
>