[Click] click optimize efficiency
Yongheng Qi
jetever at gmail.com
Sat Nov 28 03:50:54 EST 2009
I tested the NotifierQueue, the instance is the same as before.
anyone have ideas? Thanks.
This is the top result:
Mem: 20540K used, 106700K free, 0K shrd, 0K buff, 6656K cached
CPU: 0% usr 27% sys 0% nice 0% idle 0% io 15% irq 56% softirq
Load average: 0.95 0.88 0.50
PID PPID USER STAT VSZ %MEM %CPU COMMAND
777 2 root RW 0 0% 99% [kclick]
807 691 root R 1960 2% 0% top
682 664 root S 1992 2% 0% /usr/sbin/dropbear -p 22
691 682 root S 1972 2% 0% -ash
2009/11/28 Yongheng Qi <jetever at gmail.com>
> Thanks very much, Roman.
>
> I will read the paper serious. and thanks your advise about notifier
> queues.
>
> now I only use the general Queue(). now it is the wee hours at my local
> time.
>
> I am at home. tomorrow I will go to my office. and If I get the new
> instance.
>
> I will mail to you.
>
> 2009/11/28 Roman Chertov <rchertov at cs.ucsb.edu>
>
> Yongheng Qi wrote:
>> > Thanks roman,I think my question is how to reduce the kclick cpu load,
>> > now when the thoughput get about 90Mbps kclick use 100% cpu. So I want
>> > to make kclick more quickly, and it will process more packets.
>>
>> I highly recommend that you read this
>> http://pdos.csail.mit.edu/papers/click:tocs00/paper.pdf It explains how
>> the elements interact with each other and how the packets are processed.
>> This should give you some insights as to how you can reduce the load
>> and speed up the processing by rearranging your click config.
>>
>> Also, search the mail archives about notifier queues. There was a
>> discussion a while ago on how to reduce the CPU load when the packet
>> load is not very high.
>>
>> Roman
>>
>> >
>> > How do you think?
>> >
>> > On 11/28/09, Roman Chertov <rchertov at cs.ucsb.edu> wrote:
>> >> Yongheng Qi wrote:
>> >>> By the way, when test the two routes use wireless, both them kclick
>> >>> thread use more then 95% CPU load.
>> >>>
>> >>> I check all queue I am used, nothing be droped.
>> >> This most likely means that you are dropping packets at the input
>> >> interfaces as they are not drained fast enough.
>> >>
>> >>> how to play with the BURST parameter?
>> >> http://read.cs.ucla.edu/click/elements/fromdevice
>> >>
>> >> BURST allows to specify how many packets to dequeue at once. You can
>> >> try increasing this value from its default (8).
>> >>
>> >> Roman
>> >>
>> >>> Thanks
>> >>>
>> >>> 2009/11/25 Roman Chertov <rchertov at cs.ucsb.edu
>> >>> <mailto:rchertov at cs.ucsb.edu>>
>> >>>
>> >>> When you run your original config on the gateway device, look at
>> the
>> >>> dmesg output. If there are queue drops in any of the queues, you
>> will
>> >>> notice that. If that is the case, you will have to modify your
>> >>> config.
>> >>> For example, you can play with the BURST parameter.
>> >>>
>> >>> Yongheng Qi wrote:
>> >>> > Thanks, Roman,
>> >>> >
>> >>> > I have test the FromDevice(eth0) -> ctr :: AverageCounter ->
>> >>> Discard and
>> >>> > FromDevice(br-lan)
>> >>> >
>> >>> > both can get the 100Mbps throuthput, it is my etherlink limit.
>> >>> >
>> >>> >
>> >>> >
>> >>> > 2009/11/25 Roman Chertov <rchertov at cs.ucsb.edu
>> >>> <mailto:rchertov at cs.ucsb.edu>
>> >>> > <mailto:rchertov at cs.ucsb.edu <mailto:rchertov at cs.ucsb.edu>>>
>> >>> >
>> >>> > You can run Click on the receiver with the following config
>> >>> file.
>> >>> >
>> >>> > FromDevice(devX) -> ctr :: AverageCounter -> Discard;
>> >>> >
>> >>> > Then, you can look at the ctr stats to see what throughput
>> you
>> >>> are
>> >>> > getting at the receiver.
>> >>> >
>> >>> > Yongheng Qi wrote:
>> >>> > > en, I am not sure, but I don't know how test the wireless
>> >>> > throughout put.
>> >>> > >
>> >>> > > but the wireless card on ap sta mode can get the 140Mbps.
>> >>> the monitor
>> >>> > > mode is
>> >>> > >
>> >>> > > our optimized. so it can get the same throughout put as ap
>> >>> sta mode.
>> >>> > >
>> >>> > > 2009/11/25 Roman Chertov <rchertov at cs.ucsb.edu
>> >>> <mailto:rchertov at cs.ucsb.edu>
>> >>> > <mailto:rchertov at cs.ucsb.edu <mailto:rchertov at cs.ucsb.edu>>
>> >>> > > <mailto:rchertov at cs.ucsb.edu <mailto:rchertov at cs.ucsb.edu
>> >
>> >>> <mailto:rchertov at cs.ucsb.edu <mailto:rchertov at cs.ucsb.edu>>>>
>> >>> > >
>> >>> > > Are you sure that your wireless link can transmit more
>> >>> than
>> >>> > 90Mbps? I
>> >>> > > would try to test the base performance of your source
>> and
>> >>> > > destination first.
>> >>> > >
>> >>> > > Roman
>> >>> > >
>> >>> > > Yongheng Qi wrote:
>> >>> > > > Thanks, you advise is very importent for me. I think
>> >>> it not
>> >>> > the TCP
>> >>> > > > problem, because I test the UDP thoughout put. The
>> same
>> >>> as
>> >>> > TCP. Cliff
>> >>> > > > say about kernel will memcpy every packet. Have the
>> way
>> >>> > solve the
>> >>> > > > question? In the test, the kclick thread use more
>> then
>> >>> 95%
>> >>> > CPU. The
>> >>> > > > eth0 driver use the opewrt include and the ath2 use
>> the
>> >>> > atheros sdk.
>> >>> > > > These drivers may have problem?
>> >>> > > >
>> >>> > > > On 11/25/09, Roman Chertov <rchertov at cs.ucsb.edu
>> >>> <mailto:rchertov at cs.ucsb.edu>
>> >>> > <mailto:rchertov at cs.ucsb.edu <mailto:rchertov at cs.ucsb.edu>>
>> >>> > > <mailto:rchertov at cs.ucsb.edu
>> >>> <mailto:rchertov at cs.ucsb.edu> <mailto:rchertov at cs.ucsb.edu
>> >>> <mailto:rchertov at cs.ucsb.edu>>>>
>> >>> > wrote:
>> >>> > > >> I failed to notice the config file...
>> >>> > > >>
>> >>> > > >> In addition to what Cliff said, you can try a
>> simple
>> >>> test
>> >>> > where you
>> >>> > > >> configure Click as a transparent bridge to forward
>> >>> packets
>> >>> > > between two
>> >>> > > >> devices. Then, you can look at the counters to see
>> >>> where
>> >>> > the packet
>> >>> > > >> drops occur.
>> >>> > > >>
>> >>> > > >> FromDevice(eth0) -> Queue -> ToDevice(eth1);
>> >>> > > >>
>> >>> > > >> If the counters for FromDevice, Queue, and ToDevice
>> >>> are the
>> >>> > same, it
>> >>> > > >> means that you are dropping packets at eth0 driver.
>> >>> You
>> >>> > also need to
>> >>> > > >> keep track of how many packets you sent from the
>> >>> source to
>> >>> > help you
>> >>> > > >> diagnose the issue.
>> >>> > > >>
>> >>> > > >> Roman
>> >>> > > >>
>> >>> > > >> Cliff Frey wrote:
>> >>> > > >>> Your config looks reasonable to me.
>> >>> > > >>>
>> >>> > > >>> How are you measuring performance? I know if you
>> >>> are running
>> >>> > > TCP on the
>> >>> > > >>> devices as well (if you are testing
>> tcp-to-the-device
>> >>> > rather than
>> >>> > > >>> forwarding
>> >>> > > >>> perfomance) that can slow things down (because of
>> TCP
>> >>> > > checksumming and
>> >>> > > >>> because linux will keep a copy of every packet,
>> >>> causing
>> >>> > there to
>> >>> > > be a lot
>> >>> > > >>> more memcpy overhead).
>> >>> > > >>>
>> >>> > > >>> Also, often the drivers contribute a lot of the
>> >>> slowdown, even
>> >>> > > though this
>> >>> > > >>> is very hard to measure/see.
>> >>> > > >>>
>> >>> > > >>> It also seems as though you are using a br-lan
>> >>> device from
>> >>> > > linux, perhaps
>> >>> > > >>> the linux bridge code isn't very fast as well.
>> >>> > > >>>
>> >>> > > >>> You can benchmark click by loading the same
>> config,
>> >>> but
>> >>> > with an
>> >>> > > >>> InfiniteSource instead of a FromHost or
>> FromDevice,
>> >>> and a
>> >>> > > Discard instead
>> >>> > > >>> of
>> >>> > > >>> a ToHost/ToDevice, and seeing what performance you
>> >>> get there.
>> >>> > > That can
>> >>> > > >>> give
>> >>> > > >>> you a benchmark for the maximum possible speeds
>> that
>> >>> you will
>> >>> > > see with
>> >>> > > >>> click. If that number is very high, then you need
>> to
>> >>> be
>> >>> > > optimizing your
>> >>> > > >>> drivers or linux. If the number is low, then the
>> >>> problem
>> >>> > > probably is in
>> >>> > > >>> click.
>> >>> > > >>>
>> >>> > > >>> I know from experience that it is possible to
>> >>> forward more
>> >>> > than
>> >>> > > 140Mbps
>> >>> > > >>> using kernel click with linux on a mips board in
>> the
>> >>> > 600-800 MHz
>> >>> > > range.
>> >>> > > >>>
>> >>> > > >>> Cliff
>> >>> > > >>>
>> >>> > > >>> On Tue, Nov 24, 2009 at 1:48 AM, Yongheng Qi
>> >>> > <jetever at gmail.com <mailto:jetever at gmail.com>
>> >>> <mailto:jetever at gmail.com <mailto:jetever at gmail.com>>
>> >>> > > <mailto:jetever at gmail.com <mailto:jetever at gmail.com>
>> >>> <mailto:jetever at gmail.com <mailto:jetever at gmail.com>>>> wrote:
>> >>> > > >>>
>> >>> > > >>>> Click performance is so poor. I only use 3
>> >>> classifier and 1
>> >>> > > iprewrite and
>> >>> > > >>>> other general packet process elements.
>> >>> > > >>>>
>> >>> > > >>>> At 680Mhz MIPS CPU, click actually can't process
>> >>> over 90Mbit
>> >>> > > data per
>> >>> > > >>>> second.
>> >>> > > >>>>
>> >>> > > >>>> The attachment is the click config file. anyone
>> can
>> >>> tell
>> >>> > me how to
>> >>> > > >>>> optimize
>> >>> > > >>>> it.
>> >>> > > >>>>
>> >>> > > >>>> Thanks very much
>> >>> > > >>>>
>> >>> > > >>>>
>> >>> > > >>>> 2009/11/20 Yongheng Qi <jetever at gmail.com
>> >>> <mailto:jetever at gmail.com>
>> >>> > <mailto:jetever at gmail.com <mailto:jetever at gmail.com>>
>> >>> > > <mailto:jetever at gmail.com <mailto:jetever at gmail.com>
>> >>> <mailto:jetever at gmail.com <mailto:jetever at gmail.com>>>>
>> >>> > > >>>>
>> >>> > > >>>>> Dear everyone.
>> >>> > > >>>>>
>> >>> > > >>>>> I use click roofnet process the 802.11n packet.
>> >>> test it use
>> >>> > > IxChariot.
>> >>> > > >>>> find
>> >>> > > >>>>> about 90Mbps, click use 100% cpu.
>> >>> > > >>>>>
>> >>> > > >>>>> I use routeros 433AH boardband.the cpu is MIPS
>> >>> 680Mhz.
>> >>> > > >>>>>
>> >>> > > >>>>> I don't know how to make click have more
>> eiffciency.
>> >>> > > >>>>>
>> >>> > > >>>>> please help me, Thanks very much.
>> >>> > > >>>>>
>> >>> > > >>>>> --
>> >>> > > >>>>> Yongheng Qi
>> >>> > > >>>>>
>> >>> > > >>>>> Mobile: +86 1390 119 7481
>> >>> > > >>>>>
>> >>> > > >>>>
>> >>> > > >>>> --
>> >>> > > >>>> Yongheng Qi
>> >>> > > >>>>
>> >>> > > >>>> Mobile: +86 1390 119 7481
>> >>> > > >>>>
>> >>> > > >>>> _______________________________________________
>> >>> > > >>>> click mailing list
>> >>> > > >>>> click at amsterdam.lcs.mit.edu
>> >>> <mailto:click at amsterdam.lcs.mit.edu>
>> >>> > <mailto:click at amsterdam.lcs.mit.edu
>> >>> <mailto:click at amsterdam.lcs.mit.edu>>
>> >>> > <mailto:click at amsterdam.lcs.mit.edu
>> >>> <mailto:click at amsterdam.lcs.mit.edu>
>> >>> > <mailto:click at amsterdam.lcs.mit.edu
>> >>> <mailto:click at amsterdam.lcs.mit.edu>>>
>> >>> > > >>>>
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>> >>> > > >>>>
>> >>> > > >>>>
>> >>> > > >>> _______________________________________________
>> >>> > > >>> click mailing list
>> >>> > > >>> click at amsterdam.lcs.mit.edu
>> >>> <mailto:click at amsterdam.lcs.mit.edu>
>> >>> > <mailto:click at amsterdam.lcs.mit.edu
>> >>> <mailto:click at amsterdam.lcs.mit.edu>>
>> >>> > <mailto:click at amsterdam.lcs.mit.edu
>> >>> <mailto:click at amsterdam.lcs.mit.edu>
>> >>> > <mailto:click at amsterdam.lcs.mit.edu
>> >>> <mailto:click at amsterdam.lcs.mit.edu>>>
>> >>> > > >>>
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>> >>> > > >>>
>> >>> > > >>
>> >>> > > >
>> >>> > >
>> >>> > >
>> >>> > >
>> >>> > >
>> >>> > > --
>> >>> > > Yongheng Qi
>> >>> > >
>> >>> > > Mobile: +86 1390 119 7481
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Yongheng Qi
>> >>> >
>> >>> > Mobile: +86 1390 119 7481
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Yongheng Qi
>> >>>
>> >>> Mobile: +86 1390 119 7481
>> >>
>> >
>>
>>
>
>
> --
> Yongheng Qi
>
> Mobile: +86 1390 119 7481
>
--
Yongheng Qi
Mobile: +86 1390 119 7481
More information about the click
mailing list