[Click] empty queue
Harald Schioeberg
harald at net.t-labs.tu-berlin.de
Mon Aug 23 19:13:43 EDT 2010
Hi Panos,
here are a few more thoughts, perhaps some of them are helpful:
For debugging a configuration like your
RatedSource -> Queue -> MyElement -> Discard
I typically use something like:
RatedSource -> SetTimestamp
-> t1::Tee
-> q1::Queue
-> SetTimestamp
-> t2::Tee
-> MyElement
-> Discard
t1
-> ToIPSummaryDump(filename1,CONTENTS timestamp ip_id)
t2
-> ToIPSummaryDump(filename2,CONTENTS timestamp ip_id)
This needs ./configure --enable-analysis (...) to run, or you use ToDump
and parse the output files with tcpdump.
ip_id should be substituted with some field(s) that allow you to
identify your packets.
If you run in Kernel, have a look at the StoreTimestamp Element...
If you really have no packets leaving click as in your
RatedSource->Discard example,
you can furthermore run userlevel click with the --simtime option, this
will cause click to run as fast as the cpu permits in non real-time, and
may help you find out which effects stem from lack of CPU time...
Something like this may help you check whether you really read the right
length with MyElement:
t2 -> Script(TYPE PACKET,
label start,
read q1.length,
goto start )
On Mon, 2010-08-23 at 15:45 +0000, Panos Μatzakos wrote:
> 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
>
>
More information about the click
mailing list