[Click] click optimize efficiency
Yongheng Qi
jetever at gmail.com
Fri Nov 27 13:00:19 EST 2009
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
More information about the click
mailing list