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