[Click] empty queue

Mon Aug 23 11:45:06 EDT 2010

Hi Harald,
                   Ratedsource seems to work better for me thanks! There is still something that confuses me though. I watch the length of the queue through myElement and when it is non-empty it is always of length 1, even though the rate at wich i enqueue packets is much larger than the rate at which i dequeue them. I suppose that this has something to do with the fact that "When used as a push
element, RatedSource will send a maximum of one packet per scheduling" as mentioned in the description of the element. Anyway, what i want to secure, is to be sure that the RATE parameter of the RatedSource is the real rate (or close to the real rate) of the generated packets. Do you know if this is possible with RatedSource?
Also, the actual rate that i want packets to be generated with is much less than 100 packs/sec finally.

I remind you that my configuration is like this:
RatedSource -> Queue -> MyElement -> Discard

                                                                                         Thanks for the help,
                                                                                                    Panos

--- Στις Δευτ., 23/08/10, ο/η Harald Schiöberg <harald at net.t-labs.tu-berlin.de> έγραψε:

Από: Harald Schiöberg <harald at net.t-labs.tu-berlin.de>
Θέμα: Re: [Click] empty queue
Προς: "Panos Μatzakos" <magic_pan86 at yahoo.gr>
Κοιν.: "Cliff Frey" <cliff at meraki.com>, click at pdos.csail.mit.edu
Ημερομηνία: Δευτέρα, 23 Αύγουστος 2010, 12:18

Hi Panons, 

You may want to give RatedSource a try. It consumes more CPU on low
rates, but is able to achieve higher rates than TimedSource, 100 pkt/s
should be doable...
(It's using Tasks instead of Timers, see the discussion here: 
http://www.read.cs.ucla.edu/click/doxygen/classTimer.html 
) 

    Harald

On Sun, 2010-08-22 at 18:19 +0000, Panos Μatzakos wrote:
> Hello Cliff, i need to process about 100 packets/sec. What i want to do is to send every packet to the PHY layer from my element through a socket, wait until i get an ACK for about 10ms and then discard the packet (through Discard element) and go to dequeue the next one. 
> Is there any restriction of how frequently timedsource can generate a packet (i mean how small the INTERVAL parameter of timedsource can be)? Once again thank you very much for your help!
> 
> --- Στι Παρ., 20/08/10, ο/η Cliff Frey <cliff at meraki.com> γραψε:
> 
> Απ: Cliff Frey <cliff at meraki.com>
> Θμα: Re: [Click] empty queue
> Προ: "Panos Μatzakos" <magic_pan86 at yahoo.gr>
> Κοιν.: "Click mailman" <click at pdos.csail.mit.edu>
> Ημερομηνα: Παρασκευ, 20 Αγουστο 2010, 21:16
> 
> TimedSource can be very active, but it will be limited in how fast it can generate packets if you are CPU limited.  You could change it to use a TokenBucket for how much it needs to send, and have it send up to BURST packets per timer run, which would make it slightly more tolerant of CPU overload.
> 
> Also, maybe your element is being too aggressive (like processing many packets at once, or always being scheduled, when timers are only run every N runs of your task).  Is it really a problem that the queue becomes empty?  Isn't it just because your other element is so fast?  How many packets/sec do you actually need to process and how far from that goal are you?
> 
> Also, please always CC the mailing list.
> Cliff
> 
> 2010/8/20 Panos Μatzakos <magic_pan86 at yahoo.gr>
> 
> Hi Cliff and thank you very much for your answer! As you said, with InfiniteSource the Queue is non-empty the whole time. But that does not serve all of my needs unfortunately, because it can only cover the case of a saturated source. What i need is to check the throughput of my network for various offered loads(meaning various rates of filling the queue and cases in which the Queue needs to get empty) and not just for saturated conditions. This is why i needed the TimedSource element. But from what you answered me i think that i cannot be sure  that the offered load wich is supposed to be generated from timedsource is the actual offered load, due to scheduling. Have i got something wrong? If not is there a way to bypass this difficulty?
> 
> 
> --- Στι Πμ., 19/08/10, ο/η Cliff Frey
>  <cliff at meraki.com> γραψε:
> 
> Απ: Cliff Frey <cliff at meraki.com>
> 
> Θμα: Re: [Click] empty queue
> Προ: "Harald Schioeberg" <harald at net.t-labs.tu-berlin.de>
> Κοιν.: "Panos Μatzakos" <magic_pan86 at yahoo.gr>, click at pdos.csail.mit.edu
> 
> Ημερομηνα: Πμπτη, 19 Αγουστο 2010, 18:36
> 
> I agree with Harald,
> TimedSource might not be able to fill up a Queue as fast as you think in CPU bound cases.  Specifically if you look at timedsource.cc, you can see that it pushes at most one packet per timer-execution, and then schedules another timer for the future (even if TimedSource is behind schedule, for instance).  If you used InfiniteSource instead of TimedSource, it would have a greater chance of keeping the queue
>  full.
> 
> If you really think that the Queue is full, then add a configuration argument to your element of the Queue element itself... so you'd have something like
> upstream_q :: Queue
> 
> -> mysocket :: MyMainElement(DEBUG_QUEUE_ELT upstream_q)
> Then, in MyMainElement::configure, add a
> "DEBUG_QUEUE_ELT", cpkM, cpElementCast, "Queue", &_debug_queue,
> 
> (you'll need to include click/elements/standard/fullnotequeue.hh, and define an element instance variable of FullNoteQueue *_debug_queue)
> Then in your debugging printout of NULL! you can add _debug_queue->size(); to the printout (to verify that the queue is empty).
> 
> 
> In any case, just wanted to show you a possible way to debug this if everything else isn't working.
> Cliff
> 2010/8/19 Harald Schioeberg <harald at net.t-labs.tu-berlin.de>
> 
> 
> Hi Panos,
> 
> 
> 
> do you run in CPU-bounded conditions? If click is CPU bound, it will
> 
> give strong precedence to egress, meaning that ingress may not see all
> 
> the packets that you expect.
> 
> 
> 
> Harald
> 
> 
> 
> On Wed, 2010-08-18 at 17:52 +0000, Panos Μatzakos wrote:
> 
> > Hello, as i had mentioned in a previous mail i try to implement a mac
> 
> >  protocol (802.11 csma/ca) for my thesis and i am using the following
> 
> >  flowgraph:
> 
> >
> 
> > Timedsource -> Queue -> mysocket -> Discard
> 
> >
> 
> > where mysocket is the main element of my router which implements the
> 
> >  algorithm of the protocol and sends packets to PHY through sockets.
> 
> >  Then, i needed a way to know from "mysocket" when the queue becomes
> 
> >  empty because it is of great importance for my protocol. The simplest
> 
> >  way that was suggested to me was this:
> 
> >
> 
> > mysocket::pull() {
> 
> >   Packet * p = input(0).pull();
> 
> >   if(p == NULL){
> 
> >       return 0;}
> 
> >
> 
> > } p is NULL exactly if Queue is empty.  Everything seemed to work nice
> 
> >  but when i tried to test my protocol in saturation conditions (in
> 
> >  which case the queue is always non empty) by securing that the
> 
> >  incoming rate of the queue is much higher than the outcoming rate i
> 
> >  noticed that the queue got empty sometimes. Specifically i wrote the
> 
> >  following code:
> 
> >
> 
> > Packet * p = input(0).pull();
> 
> >     if(p == NULL){
> 
> >         cout<<"NULL!!"<<endl;
> 
> >         return 0;
> 
> >     }
> 
> >
> 
> > and noticed that the "NULL!!" message was printed although it
> 
> >  shouldn't. One thing that i am not sure about is what happens exactly
> 
> >  when the queue holds capacity, which is a case that obviously
> 
> >  interests me because as i said my incoming rate is greater than the
> 
> >  outcoming rate. In the description of the queue element it says "Drops
> 
> >  incoming packets if the queue already holds CAPACITY packets". What i
> 
> >  understand from this is that the packets which are dropped are the new
> 
> >  ones which are generated from timedsource and not the ones which are
> 
> >  already in the queue, so the queue should still remain non empty. So
> 
> >  do you have any idea about what happens and my queue still gets empty
> 
> >  under these conditions?
> 
> >
> 
> > One last thing i need to ask as i want to be sure if i have understood
> 
> >  everything right is the following. In my flowgraph the element which
> 
> >  initiates the packet flow after the queue element is the Discard
> 
> >  element by a pull connection from its input. Is that right?
> 
> >
> 
> >
> 
> > _______________________________________________
> 
> > 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
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click