[Click] click optimize efficiency
Yongheng Qi
jetever at gmail.com
Fri Nov 27 12:28:28 EST 2009
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.
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
>
>
--
Sent from my mobile device
Yongheng Qi
Mobile: +86 1390 119 7481
More information about the click
mailing list