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 <[email protected]> γραψε:
>
> Απ: Cliff Frey <[email protected]>
> Θμα: Re: [Click] empty queue
> Προ: "Panos Μatzakos" <[email protected]>
> Κοιν.: "Click mailman" <[email protected]>
> Ημερομηνα: Παρασκευ, 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 <[email protected]>
>
> 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
> <[email protected]> γραψε:
>
> Απ: Cliff Frey <[email protected]>
>
> Θμα: Re: [Click] empty queue
> Προ: "Harald Schioeberg" <[email protected]>
> Κοιν.: "Panos Μatzakos" <[email protected]>, [email protected]
>
> Ημερομηνα: Πμπτη, 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 <[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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
