[Click] empty queue

[Cliff Frey]

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
>