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.
How do you think? On 11/28/09, Roman Chertov <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> >> >> 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 <[email protected] >> <mailto:[email protected]> >> > <mailto:[email protected] <mailto:[email protected]>>> >> > >> > 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 <[email protected] >> <mailto:[email protected]> >> > <mailto:[email protected] <mailto:[email protected]>> >> > > <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>> >> > > >> > > 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] >> <mailto:[email protected]> >> > <mailto:[email protected] <mailto:[email protected]>> >> > > <mailto:[email protected] >> <mailto:[email protected]> <mailto:[email protected] >> <mailto:[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] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> > > <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[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] >> <mailto:[email protected]> >> > <mailto:[email protected] <mailto:[email protected]>> >> > > <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[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] >> <mailto:[email protected]> >> > <mailto:[email protected] >> <mailto:[email protected]>> >> > <mailto:[email protected] >> <mailto:[email protected]> >> > <mailto:[email protected] >> <mailto:[email protected]>>> >> > > >>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> > > >>>> >> > > >>>> >> > > >>> _______________________________________________ >> > > >>> click mailing list >> > > >>> [email protected] >> <mailto:[email protected]> >> > <mailto:[email protected] >> <mailto:[email protected]>> >> > <mailto:[email protected] >> <mailto:[email protected]> >> > <mailto:[email protected] >> <mailto:[email protected]>>> >> > > >>> 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 > > -- Sent from my mobile device Yongheng Qi Mobile: +86 1390 119 7481 _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
