[Click] click optimize efficiency

[Roman Chertov]

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> 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
>>>
>>
>