[Click] ToDevice Cpu Load 99%

Eddie Kohler kohler at cs.ucla.edu
Fri Feb 9 02:16:24 EST 2007


Hi Nicola,

I actually think that the recent changes, especially including a change 
today that fixed some bugs with things like TimeSortedSched.  But maybe 
not.  I think we'd need a bit more information to debug the problem 
further, if current code doesn't fix it.

Eddie


Nicola Arnoldi wrote:
> May the problem I posted quite time ago be related to this notifier issue?
> 
> I use a scheduling, which is closely related to rrsched. Its notifiers 
> are the same of rrsched.
> 
> The scheme is as follows:
> 
> ...->class :: Classifier()
> class[0]->NotifierQueue(x)->[0]scheduler;
> class[1]->NotifierQueue(x)->[1]scheduler;
> class[2]->NotifierQueue(x)->[2]scheduler;
> class[3]->NotifierQueue(x)->[3]scheduler;
> 
> prio_sched :: PrioSched()
> scheduler->[1]prio_sched
> ....->[0]prio_sched
> 
> where x is the length of NotifierQueue.
> 
> I tried to load the Classifier with a very high bitrate UDP traffic 
> which is classified by the classifier and distributed to the four queues.
> This is in a 802.11g system, with raw throughput of 26Mbps.
> The scheduler is a weighted priority scheduler.
> I noticed that, with UDP traffic, and queues shorter than 1000 pkts, the 
> throughput is not distributed according to the weights.
> Notifierqueue has got a sleepiness mechanism which avoids pulling from 
> them when they hover around 1 or 2 pkts.
> 
> However the scheduler, which uses empty queues notifiers in order to 
> learn if a queue is empty or not, skips pulling for queues (especially 
> high prio ones) many times because of empty notifiers.
> This happens only when queues are shorter than 600-700 pkts. This 
> shouldn't be, as the packet rate injected into the queues is very high.
> 
> I also tried changing the sleepiness threshold, but it seems not 
> affecting the issue.
> I tried the configuration with short queues and RatedSource and 
> RatedUnqueue in order to test it offline. It worked!
> It seems that when applying it to a real scenario the whole thing 
> collapses...
> 
> This fact is critical, because I have to mantaing very long queues which 
> cause very high delays in my router!
> 
> 
> Help needed!
> 
> 
> 
> 
> Il giorno 26/gen/07, alle ore 22:04, Eddie Kohler ha scritto:
> 
>> Paolo,
>>
>> Do the recent notification fixes address this problem?
>>
>> Eddie
>>
>>
>> Paolo Mailing wrote:
>>> Hi to all,
>>> I've a problem with the element ToDevice in linuxmodule,
>>> in some complicated configuration the cpu load go fast to
>>> 99%. I've some Queue plugged in a PrioSched and then
>>> in another Priosched and then in ToDevice.
>>> I've tried some configuration but I didn't understand the
>>> problem.
>>> The configuration is like this :
>>>
>>> FromDevice(eth0) ->
>>> paintswitch :: PaintSwitch();
>>> out_scheduler :: SimplePrioSched();
>>> paintswitch[0] -> Queue -> [0] out_scheduler;
>>> paintswitch[1] -> Queue -> [1] out_scheduler;
>>> paintswitch[2] -> Queue -> [2] out_scheduler;
>>> paintswitch[3] -> Queue -> [3] out_scheduler;
>>> paintswitch[4] -> Queue -> [4] out_scheduler;
>>> paintswitch[5] -> Queue -> [5] out_scheduler;
>>> out_scheduler -> ToDevice(eth0);
>>>
>>> Thanks
>>> Paolo
>>> _______________________________________________
>>> 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


More information about the click mailing list