[Click] Scheduler does not take packets

Eddie Kohler kohler at cs.ucla.edu
Tue Jul 27 09:32:30 EDT 2004


Hi Davy,

You need to explain this a bit better I think, and use counters on the outputs 
of OwnElement to verify that your element is behaving as expected.

I tried to model your configuration with the following test config:

sched1, sched2 :: PrioSched;

q1,q2,q3,q4,q5,q6 :: Queue;

i::Idle -> q1 -> [0]sched1;
RatedSource(RATE 200) -> sw::Switch -> q2 -> [1]sched1;
i[1] -> q3 -> [2]sched1;

i[2] -> q4 -> [0]sched2;
i[3] -> q5 -> [1]sched2;
sw[1] -> q6 -> [2]sched2;

sched1 -> Shaper(150) -> ca::Counter -> Discard;
sched2 -> Shaper(500) -> cb::Counter -> Discard;

DriverManager(wait 1s, print ca.count, print cb.count,
    write sw.switch 1, wait 3s, print ca.count, print cb.count, print q2.length,
    write sw.switch 0, wait 5s, print ca.count, print cb.count, stop)


Note the use of DriverManager to switch packets from [1]sched1 to [2]sched2. 
The result is exactly what I would expect: the first printouts print "150, 0"; 
the second printouts print "200 [the remaining 200 packets from the first second 
are emitted], 600, 0 [nothing in q2]"; the third print "1050, 600".

Eddie



Davy De Winter wrote:
> Hi all,
> 
> I still have another click-problem which I don't get: 
> I have the following configuration loaded (only the elements that could be of 
> intrest are shown): 
> All the elements (eth1hpq, ... , eth2oq, ending on q thus) are NotifierQueues 
> with a size of 25 packets. 
> The elements schedeth1 en schedeth2 are PrioSched-elements. 
> The ee_x elements are just EtherEncap elements.
> 
> OwnElement[0] -> ee_1 -> eth1hpq -> [0]schedeth1; 
> OwnElement[1] -> ee_2 -> eth1lpq -> [1]schedeth1; 
> OwnElement[2] -> ee_3 -> eth1oq -> [2]schedeth1; 
> 
> OwnElement[3] -> ee_4 -> eth2hpq -> [0]schedeth2;
> OwnElement[4] -> ee_5 -> eth2lpq -> [1]schedeth2;
> OwnElement[5] -> ee_6 -> eth2oq -> [2]schedeth2; 
> 
> schedeth1 -> Shaper(150) -> ToDevice(eth1); 
> schedeth2 -> Shaper(500) -> ToDevice(eth2); 
> 
> Now my problem: I send a flow with a FastUDPSource from another node to this 
> node. This flow sends 200 packets / s to my OwnElement[1]-port. Because the 
> shaper only lets 150 packets/s pass, normally packets would be dropped from 
> the eth1lpq, but my OwnElement remaps the flow for a certain amount of time 
> (e.g. 8 seconds) on an alternative, in this case eth2oq (corresponds to 
> OwnElement[5]). 
> But when the time expires (after the 8 seconds) it tries to remap the flow on 
> the original path, and thus eth1lpq (which corresponds to OwnElement[1]). 
> The first thing I expect is that the eth1lpq should be empty (during the 8 
> seconds, no other traffic arrived on eth1hpq, eth1lpq, eth1oq, so the 
> schedeth1 actually has no other job to do then empty eth1lpq, and wait). 
> But this isn't the case, the queue never has a size smaller then 24 packets 
> when I watch the length each second. Only a packet or 3 can pass on each 
> remap and then the flow is send back again to OwnElement[5]. 
> Can someone tell me in what direction I should look, because the schedeth1 
> doesn't schedule packets during that 8 seconds, only schedeth2 does. The 
> consequence is that my testresults do not correspond to my expectations. 
> 
> Thanks a lot!
> Best regards,
> Davy De Winter. 
> 
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click



More information about the click mailing list