The easiest way I have gotten around this is to use LinkUnqueue instead (It is not exactly a drop-in replacement though, as it is pull-to-push). However it would also be possible to set up a timer in the BandwidthShaper element and put the task to sleep.
Cliff On Mon, Dec 14, 2009 at 9:39 AM, Aziz Adel <[email protected]> wrote: > Hello, > > I am a new user to Click and I noticed that the BandwidthShaper Element is > using all my CPU power (266 Mhz on Asus router) when I limit the rate below > the capacity of the wireless channel (i.e. the queue of the MAC layer is > most of the time empty). > I noticed that this problem, does not occur, when I set a higher rate that > is able to fill the MAC queue (which basically means that the > BandwidthShaper is not limiting anything). Thus, I am guessing that the > problem might come from the "pull" method (see below) that is always called > by the MAC layer and that heavily uses the CPU due to the Timestamp::now() > calls. > ------------------------ > Packet * > BandwidthShaper::pull(int) > { > Packet *p = 0; > if (_rate.need_update(Timestamp::now())) { > if ((p = input(0).pull())) > _rate.update_with(p->length()); > } > return p; > } > ------------------- > > I wanted to know if any other user also encountered this problem and how > did he solved it? > In a C code, my guess would have been to add and "else" part and put use > the "usleep()" function in order to limit too many pull calls by delaying > the answer, but this does not seem to compile as is and I did not find an > equivalent to "usleep()" that could be used with the Click code. > > If anyone has any hint for how to go over my problem, it would be really > nice :) > > Best, > > Adel > _______________________________________________ > click mailing list > [email protected] > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
