[Click] click optimize efficiency
Roman Chertov
rchertov at cs.ucsb.edu
Fri Nov 27 12:53:19 EST 2009
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
>>
>
More information about the click
mailing list