[Click] Problems with RatedUnqueue

[Eddie Kohler]

Øivind,

Ah, I had not realized you were trying to use such low rates.  For very low 
rates like this RatedUnqueue is not currently a good choice of element.  The 
RatedUnqueue will, as you observe, spin endlessly while waiting to emit a 
packet.  Burster is a much better choice for very low rates.  While we might 
fix this problem eventually, we won't soon.  People interested in fixing it 
should look at elements like LinkUnqueue that use combinations of Timers and 
Tasks.

Eddie


Øivind Kure wrote:
> Eddie,
> I only did a brief test this afternoon. I have not had time to copy the original test scenario. However, with the setup shaping just the broadcast packet coming over the interface I got the same results once I set the shaper to the extreme range of 1 pck per sec. The machine became CPU bound. Increasing the shaping rate removed the problem again.
> 
> Regards
> Øivind
> 
> -----Original Message-----
> From: Eddie Kohler [mailto:kohler at cs.ucla.edu] 
> Sent: 23. februar 2009 08:33
> To: Øivind Kure
> Cc: click at pdos.csail.mit.edu; Bart Braem
> Subject: Re: [Click] Problems with RatedUnqueue
> 
> Øivind,
> 
> Did you ever try the newer Git sources to verify whether this problem still 
> occurs there?
> 
> Eddie
> 
> 
> Øivind Kure wrote:
>> Hi,
>> I run click in userspace (on a Suse 10.0 machine), essentially as a link emulator.
>> The essence of the configuration is Fromdevice ->Queue -> shaper -> Todevice.
>> In addition I use  a standard setup with Classifier, IPClassifier, CheckIPHeader, ArpResponder and ArpQuerier, so the configuration acts as a forwarding element.
>>
>> For the shaper element I started out with RatedUnqueue . 
>> The configuration is used in a controlled environment where the load is  1,5 Mbit/sec MPEG2 video or roughly 150 packets a second.  The configuration works with no problem. However, when I reduce the rate of the shaper element (f. ex 30) , the configuration become CPU bound. Packets are dropped from the video, but the queuing element before the shaper reports 0 drops. The cpu load reported by top increases to 0% idle and almost 100% to click. The machine remains cpu bound until the rate in the shaper element is increased to 250, well above the offered load.
>> This problem has been observed for click 1.5 and click 1.6.  I have also observed similar problems on other linux versions.
>>
>> If I replace the shaper element with Burster ( which is timer based) , the problem disappears. When the rate in the shaper element  is reduced, the queue starts dropping packets, as is shoul. The cpu load remains almost constant and low.
>>
>> It might be designed feature I have missed, a bug, or I might have misunderstood something basic. Any explanation to the observed behaviour will be appreciated. 
>> Regards
>> Øivind Kure
>>
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click