[Click] LinkUnqueue multiple flows shaping issues

milos rovcanin ro1208984 at gmail.com
Fri Jun 24 04:04:36 EDT 2011


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


More information about the click mailing list