[Click] High CPU usage with BandwidthShaper Element

[Cliff Frey]

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 <adel.aziz at epfl.ch> 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
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>