[Click] click optimize efficiency

[Yongheng Qi]

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> 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> 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>
>>>
>>>> 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
>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>
>>>
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>
>
>

-- 
Sent from my mobile device

Yongheng Qi

Mobile: +86 1390 119 7481