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