I tested the NotifierQueue, the instance is the same as before. anyone have ideas? Thanks.
This is the top result: Mem: 20540K used, 106700K free, 0K shrd, 0K buff, 6656K cached CPU: 0% usr 27% sys 0% nice 0% idle 0% io 15% irq 56% softirq Load average: 0.95 0.88 0.50 PID PPID USER STAT VSZ %MEM %CPU COMMAND 777 2 root RW 0 0% 99% [kclick] 807 691 root R 1960 2% 0% top 682 664 root S 1992 2% 0% /usr/sbin/dropbear -p 22 691 682 root S 1972 2% 0% -ash 2009/11/28 Yongheng Qi <[email protected]> > 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 <[email protected]> > > 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 <[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 >> >> >> > >> >> > > > -- > 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
