[Click] LinkUnqueue multiple flows shaping issues
Eddie Kohler
kohler at cs.ucla.edu
Thu Jun 30 09:56:32 EDT 2011
Hi Milos,
Sorry, but debugging an old problem in a prior version is not exciting for
anyone. :) You have a lot of tools that could help you look for the problem,
including git log.
Eddie
On 6/27/11 8:42 AM, milos rovcanin wrote:
> We have been able to fix our code. It can compile now.
> Nevertheless, I would be more than thankful if you could give me your opinion
> on our problem with LinkUnqueue element inside version 1.8.0. Since there is
> no such a problem, someone has to know where the bug was?
>
> Anyone?
>
> Thanks!
>
> On Mon, Jun 27, 2011 at 1:29 PM, Eddie Kohler <kohler at cs.ucla.edu
> <mailto:kohler at cs.ucla.edu>> wrote:
>
> Milos,
>
> Please be specific about what compilation problems you are seeing and we
> will fix them. It is almost always better to use newer code.
>
> Eddie
>
>
>
> On 06/27/2011 12:37 AM, milos rovcanin wrote:
>
> Hello,
>
> The latest GIT version of Click works fine and the problem we had
> seems to be
> solved, but there are some other elements that won't compile under the
> it. It
> turns out that the latest GIT provides more problems than solutions. Could
> anyone , please, take a look at the simple configuration that I sent in my
> last mail? I have explained the behavior of it as well.
>
> Thank you in advance!!!
>
> On Fri, Jun 24, 2011 at 10:08 AM, milos rovcanin <ro1208984 at gmail.com
> <mailto:ro1208984 at gmail.com>
> <mailto:ro1208984 at gmail.com <mailto:ro1208984 at gmail.com>>> wrote:
>
> Before we downloaded GIT version:
>
> After doing some more tests, I found out that when no drops occur
> (eg 500
> bytes packets,shaping on 10Mbps, and UDP load of 20Mbps), there
> are only
> 10Mbps packets that enter Click (took a dump just after the
> FromDevice)??!!!
>
> When drops do occur (e.g. 1000bytes packet, shaping on 10Mbps
> and UDP
> load of 20Mbps), 20Mbps packets enter Click, are sent to the queue
> and off
> course are dropped there because the LinkUnqueue pulls at the shaping
> rate. This is behaviour that we expect.
>
> Now when I use 500 bytes packets but shape it on 5Mbps and UDP load of
> 20Mbps, packets are dropped! So, I then get expected behaviour: 20mbps
> packets enter click, sent to the queue and pulled at 5mbps by the
> linkunqueue shaper. So there is some correlation between packet
> size and
> shaping rate.
>
> When it goes wrong, it seems like the Linkunqueue element pulls
> all the
> way to the FromDevice, even when there is a queue element in
> between, and
> FromDevice is actually a push element..
>
> On Fri, Jun 24, 2011 at 10:04 AM, milos rovcanin
> <ro1208984 at gmail.com <mailto:ro1208984 at gmail.com>
> <mailto:ro1208984 at gmail.com <mailto:ro1208984 at gmail.com>>> wrote:
>
> My colleagues and I have just finished testing our
> configuration with
> the latest GIT version and it works fine!!!
>
>
>
> On Fri, Jun 24, 2011 at 4:18 AM, Eddie Kohler
> <kohler at cs.ucla.edu <mailto:kohler at cs.ucla.edu>
> <mailto:kohler at cs.ucla.edu <mailto:kohler at cs.ucla.edu>>> wrote:
>
> Please cc: your replies to the list.
>
>
> On 06/23/2011 04:22 PM, milos rovcanin wrote:
>
> Hello,
> I am not sure that you have understood me right: I am
> using
> Jperf 2.0 to
> generate UDP/TCP traffic and I am trying to send TWO
> flows at
> the same time,
> from host1 and host2 towards host 3, through a router
> that
> runs my script. I
> need to have 2 LinqUnqueue elements, for host1 and host2 ,
> respectively.
> Therefore, to test a configuration with only one
> LinkUnqueue
> element won't
> help me in any way.
>
>
> I have understood you.
>
> If you expect anyone to help you solve your problem, you
> need to
> help narrow down the problem to a minimal bug report.
>
> If you are sure that the problem DOES NOT occur with one
> LinkUnqueue, but DOES occur with two, that would be
> helpful. You
> could report the experiments that brought you to this
> conclusion.
>
> If you are not sure, then you have not created a minimal bug
> report yet. I sent a script that you change to create a
> smaller
> test case.
>
> With your own code, you can test by, for example, only
> sending one
> of the two flows at a time, or whatever else.
>
>
> Could you, at least, explain to me what "scheduled"
> handler
> (or is it a flag
> of some kind) mean? You can see it when you run Clicky and
> check your
> LinkUnqueue element?
>
>
> "scheduled" is true if the element is rescheduling itself using
> Tasks, and false if it is rescheduling itself using
> Timers. It is
> not very meaningful in this scenario.
>
> Eddie
>
>
>
>
> Thank you very much for your time!
> On Fri, Jun 24, 2011 at 1:09 AM, milos rovcanin
> <ro1208984 at gmail.com <mailto:ro1208984 at gmail.com>
> <mailto:ro1208984 at gmail.com <mailto:ro1208984 at gmail.com>>
> <mailto:ro1208984 at gmail.com <mailto:ro1208984 at gmail.com>
> <mailto:ro1208984 at gmail.com <mailto:ro1208984 at gmail.com>>>> wrote:
>
>
>
> On Thu, Jun 23, 2011 at 8:02 PM, Eddie Kohler
> <kohler at cs.ucla.edu <mailto:kohler at cs.ucla.edu>
> <mailto:kohler at cs.ucla.edu <mailto:kohler at cs.ucla.edu>>
> <mailto:kohler at cs.ucla.edu <mailto:kohler at cs.ucla.edu>
> <mailto:kohler at cs.ucla.edu <mailto:kohler at cs.ucla.edu>>>> wrote:
>
> Milos,
>
> Are you sure this is a bug?
>
> Remember that LinkUnqueue enforces a BANDWIDTH
> limit.
> That means that
> you SHOULD see more smaller packets per second
> than
> larger ones.
>
> I wrote the following Click script to test the
> enforced bandwidth of
> LinkUnqueue at three packet sizes, first 64, then
> 1000, then 32. The
> observed bandwidths for these three packet
> sizes is:
>
> 10039296
> 10000000
> 10000080
>
> all of which are pretty close to 10000000 bps!!
>
> If you really think this is a bug please
> provide the
> simplest test
> case possible -- preferably involving only one
> LinkUnqueue.
>
> Eddie
>
>
> s :: InfiniteSource(LENGTH 64)
> -> q :: Queue
> -> l :: LinkUnqueue(LATENCY 0, BANDWIDTH
> 10000000 bps)
> -> c :: Counter
> -> Discard;
>
> DriverManager(
> wait 5s,
> write s.active false,
> print $(mul $(c.count) $(s.length)
> 1.6), //
> 1.6 == 8 bits / 5 sec
>
> write c.reset,
> write q.reset,
> write l.reset,
> write s.length 1000,
> write s.active true,
> wait 5s,
> write s.active false,
> print $(mul $(c.count) $(s.length) 1.6),
>
> write c.reset,
> write q.reset,
> write l.reset,
> write s.length 30,
> write s.active true,
> wait 5s,
> write s.active false,
> print $(mul $(c.count) $(s.length) 1.6),
> );
>
>
>
> On 06/23/2011 07:00 AM, milos rovcanin wrote:
>
> Greetings to all,
>
> I have noticed an awkward behaviour of the
> LinkUnqueue() element
> when trying
> to send two flows at the same time (UDP/UDP,
> TCP/TCP, UDP/UDP).
> This is,
> pretty much, what my configuration looks like:
>
> ...
> ->Qtag0::Queue(20)
> -> LinkUnqueue(LATENCY 0,BANDWIDTH
> 13000000 bps)
> -> Queue()
> -> [0]output;
>
> ...
> -> Qtag1::Queue(20)
> -> LinkUnqueue(LATENCY 0,BANDWIDTH
> 9000000 bps)
> -> Queue()
> -> [1]output;
>
> and while I am sending at rates lower than the
> ones defined in the
> LinkUnqueue() element, everything seems to be
> working fine.
> Problems start
> to occur when one or both of the flows
> exceed the
> threshold. In
> other words,
> when LinkUnque() starts to shape. Both
> flow rates drop
> significantly, but
> only if the packet size is over 850 bytes! For
> example, if I use
> MSS of 1000
> bytes, everything work fine even with
> higher rates.
>
> I used Clicky to check the status of the
> LinkUnqueue() element and
> I noticed
> this:
> - Qtag0/Qtag1 lenghts are 1 all the time and
> LinkEnqueue's handler
> "scheduled" is true - when I send smaller packets (the ones
> that cause
> problems)
> - Qtag0/Qtag1 gets immediately full all
> the time
> and LinkEnqueue's
> handler
> "scheduled" is false - when I send larger packets (~850B and
> larger)
>
> Does anyone have any idea what could be the
> problem and how to
> solve it?
>
> Thank you in advance!
>
>
>
>
> --
> Milos Rovcanin
> Department of Information Technology
> Internet Based Communication Networks and Services
> research group (IBCN)
> Ghent University - IBBT
> Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
> T: +32 9 33 14946 ; T Secr: +32 9 33 14900
> E: Milos.Rovcanin at intec.UGent.be
> <mailto:Milos.Rovcanin at intec.UGent.be>
> <mailto:Milos.Rovcanin at intec.__UGent.be
> <mailto:Milos.Rovcanin at intec.UGent.be>>
> <mailto:Milos.Rovcanin at intec. <mailto:Milos.Rovcanin at intec.>____UGent.be
> <mailto:Milos.Rovcanin at intec.__UGent.be
> <mailto:Milos.Rovcanin at intec.UGent.be>>>
> W: www.ibcn.intec.UGent.be
> <http://www.ibcn.intec.UGent.be>
> <http://www.ibcn.intec.UGent.__be <http://www.ibcn.intec.UGent.be>>
> <http://www.ibcn.intec.UGent.____be
> <http://www.ibcn.intec.UGent.__be <http://www.ibcn.intec.UGent.be>>>
>
>
>
>
>
> --
> Milos Rovcanin
> Department of Information Technology
> Internet Based Communication Networks and Services
> research
> group (IBCN)
> Ghent University - IBBT
> Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
> T: +32 9 33 14946 ; T Secr: +32 9 33 14900
> E: Milos.Rovcanin at intec.UGent.be
> <mailto:Milos.Rovcanin at intec.UGent.be>
> <mailto:Milos.Rovcanin at intec.__UGent.be
> <mailto:Milos.Rovcanin at intec.UGent.be>>
> <mailto:Milos.Rovcanin at intec. <mailto:Milos.Rovcanin at intec.>____UGent.be
> <mailto:Milos.Rovcanin at intec.__UGent.be
> <mailto:Milos.Rovcanin at intec.UGent.be>>>
> W: www.ibcn.intec.UGent.be
> <http://www.ibcn.intec.UGent.be> <http://www.ibcn.intec.UGent.__be
> <http://www.ibcn.intec.UGent.be>>
> <http://www.ibcn.intec.UGent.____be
> <http://www.ibcn.intec.UGent.__be <http://www.ibcn.intec.UGent.be>>>
>
>
>
>
> --
> Milos Rovcanin
> Department of Information Technology
> Internet Based Communication Networks and Services research
> group (IBCN)
> Ghent University - IBBT
> Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
> T: +32 9 33 14946 ; T Secr: +32 9 33 14900
> E: Milos.Rovcanin at intec.UGent.be
> <mailto:Milos.Rovcanin at intec.UGent.be>
> <mailto:Milos.Rovcanin at intec.__UGent.be
> <mailto:Milos.Rovcanin at intec.UGent.be>>
> W: www.ibcn.intec.UGent.be <http://www.ibcn.intec.UGent.be>
> <http://www.ibcn.intec.UGent.__be <http://www.ibcn.intec.UGent.be>>
>
>
>
>
> --
> Milos Rovcanin
> Department of Information Technology
> Internet Based Communication Networks and Services research group
> (IBCN)
> Ghent University - IBBT
> Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
> T: +32 9 33 14946 ; T Secr: +32 9 33 14900
> E: Milos.Rovcanin at intec.UGent.be
> <mailto:Milos.Rovcanin at intec.UGent.be>
> <mailto:Milos.Rovcanin at intec.__UGent.be
> <mailto:Milos.Rovcanin at intec.UGent.be>>
> W: www.ibcn.intec.UGent.be <http://www.ibcn.intec.UGent.be>
> <http://www.ibcn.intec.UGent.__be <http://www.ibcn.intec.UGent.be>>
>
>
>
>
> --
> Milos Rovcanin
> Department of Information Technology
> Internet Based Communication Networks and Services research group (IBCN)
> Ghent University - IBBT
> Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
> T: +32 9 33 14946 ; T Secr: +32 9 33 14900
> E: Milos.Rovcanin at intec.UGent.be
> <mailto:Milos.Rovcanin at intec.UGent.be>
> <mailto:Milos.Rovcanin at intec.__UGent.be
> <mailto:Milos.Rovcanin at intec.UGent.be>>
> W: www.ibcn.intec.UGent.be <http://www.ibcn.intec.UGent.be>
> <http://www.ibcn.intec.UGent.__be <http://www.ibcn.intec.UGent.be>>
>
>
>
>
> --
> Milos Rovcanin
> Department of Information Technology
> Internet Based Communication Networks and Services research group (IBCN)
> Ghent University - IBBT
> Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
> T: +32 9 33 14946 ; T Secr: +32 9 33 14900
> E: Milos.Rovcanin at intec.UGent.be <mailto:Milos.Rovcanin at intec.UGent.be>
> W: www.ibcn.intec.UGent.be <http://www.ibcn.intec.UGent.be>
>
More information about the click
mailing list