[Click] LinkUnqueue multiple flows shaping issues
milos rovcanin
ro1208984 at gmail.com
Mon Jun 27 03:37:27 EDT 2011
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>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>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> 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>> wrote:
>>>>
>>>>
>>>>
>>>> On Thu, Jun 23, 2011 at 8:02 PM, Eddie Kohler <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>>
>>>> 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
>>
>>
>
>
> --
> 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
>
>
--
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