[Click] LinkUnqueue multiple flows shaping issues
milos rovcanin
ro1208984 at gmail.com
Mon Jun 27 11:42:45 EDT 2011
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> 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>> 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>> 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>> 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>>>
>> 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>>>
>> 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<Milos.Rovcanin at intec.UGent.be>
>> >
>> <mailto:Milos.Rovcanin at intec._**_UGent.be
>> <mailto:Milos.Rovcanin at intec.**UGent.be<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>
>> >>
>>
>>
>>
>>
>>
>> --
>> 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<Milos.Rovcanin at intec.UGent.be>
>> >
>> <mailto:Milos.Rovcanin at intec._**_UGent.be
>> <mailto:Milos.Rovcanin at intec.**UGent.be<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>
>> >>
>>
>>
>>
>>
>> --
>> 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 <Milos.Rovcanin at intec.UGent.be>>
>> W: 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 <Milos.Rovcanin at intec.UGent.be>>
>> W: 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<Milos.Rovcanin at intec.UGent.be>
>> >
>> W: 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
W: www.ibcn.intec.UGent.be
More information about the click
mailing list