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 <[email protected]> > 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 > > [email protected] > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > > _______________________________________________ > click mailing list > [email protected] > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
