[Click] empty queue

Sun Aug 22 14:19:29 EDT 2010

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