For interest sake can you post your the config you are using? On Mon, Dec 5, 2011 at 4:37 AM, Bingyang LIU <[email protected]> wrote:
> Hi all, > > I need some help on PollDevice. I found that PollDevice caused some packet > loss rate (less than 1%) even at low input rate (50kpps). > > To be accurate, I found the statistics of switch, which showed that the > number of packets sent out the switch port to the machine's interface was > 20000000, while the "Count" handler of the PollDevice element was 19960660. > > I tuned the driver buffer by "ethtool -G eth0 rx 2096" (default is 256), > but nothing got better. > > Could anyone help me with this? > > Thanks very much. > Bingyang > > On Sun, Dec 4, 2011 at 3:38 PM, Bingyang LIU <[email protected]> wrote: > > > Hi~ > > > > I used CPUQueue and found that it didn't drop packets any more. So the > > only problem is that PollDevice drops packets, actually I think it > couldn't > > poll all the ready packets from devices. > > > > Does anyone has similar problem with PollDevice, and is there any > solution > > or best practices? > > > > best > > Bingyang > > > > > > On Sun, Dec 4, 2011 at 2:10 PM, Bingyang LIU <[email protected]> wrote: > > > >> Hi Cliff, > >> > >> I couldn't use multi-threading when using FromDevice. When I used > >> multi-threading and FromDevice together, the system crashed. So I had to > >> use single thread when using FromDevice, and use 4 threads when using > >> PollDevice. > >> > >> The router I tested has four gigabit interfaces, each of which connected > >> with a host. All hosts sent packets to each other at the given rate. > >> When the sending rate is 50kpps (200kpps in total), FromDevice gave the > >> output ratio of 99.74%, while PollDevice gave 99.94%. > >> When the sending rate is 200kpps (800kpps in total), FromDevice only > gave > >> the output ratio of 62.63%, while PollDevice gave 99.29%. > >> > >> That's why I think PollDevice works much better than FromDevice. > >> Actually, both of them cause some packet loss at low input rate. > >> > >> And I think click 1.8 is also a mainline source code. But you are right, > >> I should try 2.0. However, I'm not sure whether the same thing will > happen > >> to 2.0. > >> > >> best > >> Bingyang > >> > >> > >> > >> > >> On Sun, Dec 4, 2011 at 2:29 AM, Cliff Frey <[email protected]> wrote: > >> > >>> What performance numbers did you see when using FromDevice instead of > >>> PollDevice? > >>> > >>> Have you tried mainline click? > >>> > >>> > >>> On Sat, Dec 3, 2011 at 10:57 PM, Bingyang Liu <[email protected] > >wrote: > >>> > >>>> Thanks Cliff. Ya, I have tried fromdevice, and it gave worse > >>>> performance. > >>>> > >>>> I think Queue should be a very mature element, and there should not be > >>>> a bug there. But the experiment results told me that something got > wrong. > >>>> Should I use a thread safe queue instead of queue, when I use > multithreads? > >>>> > >>>> Thanks > >>>> Bingyang > >>>> > >>>> Sent from my iPhone > >>>> > >>>> On Dec 4, 2011, at 12:31 AM, Cliff Frey <[email protected]> wrote: > >>>> > >>>> You could try FromDevice instead of PollDevice. I'd expect that it > >>>> would work fine. If it is not high performance enough, it would be > great > >>>> if you should share your performance numbers just to have another > datapoint. > >>>> > >>>> I doubt that Queue has a bug, you could try latest click sources > though > >>>> just in case. As for finding/fixing any polldevice issues, I don't > have > >>>> anything to help you there... > >>>> > >>>> Cliff > >>>> > >>>> On Sat, Dec 3, 2011 at 8:49 PM, Bingyang LIU <[email protected] > >wrote: > >>>> > >>>>> Hi Cliff, > >>>>> > >>>>> Thank you very much for your help. I followed your suggestion and got > >>>>> some results. > >>>>> > >>>>> 1. It turned out that "PollDevice" failed to get all the packets from > >>>>> NIC, even if the packet sending rate is only 200kpps with the packet > size > >>>>> of 64B. > >>>>> 2. I used "grep . /click/.e/*/drops", all of them reported 0 drops. > >>>>> 3. I put a counter between every two connected elements, to determine > >>>>> which element dropped packet. Finally I found a queue dropped > packets, > >>>>> because the downstream counter reported less "count" than the > upstream one. > >>>>> However, it was straight that this queue still reported 0 drops. I > think > >>>>> there might be some bug with the element, or I mis-used the elements. > >>>>> > >>>>> So I have two questions. First, how can I make PollDevice work > better, > >>>>> which means that it won't drop packets at low rate. (Should I use > Stride > >>>>> Scheduler?) Second, is there any bug with Queue in Click 1.8.0, in > terms of > >>>>> dropping packets without reporting the drops? > >>>>> > >>>>> My experiment environment and configuration: > >>>>> * Hardware: CPU Inter Xeon X3210 (quad core at 2.13Ghz), 4GB RAM. (a > >>>>> server on deterlab) > >>>>> * Software: Ubuntu8.04 + Click1.8, with PollDevice and > >>>>> multi-thread enabled. > >>>>> * Configuration: ./configure > >>>>> --with-linux=/usr/src/linux-2.6.24.7 --enable-ipsec --enable-warp9 > >>>>> --enable-multithread=4 > >>>>> * Installation: sudo click-install --thread=4 site7_router1.click > >>>>> > >>>>> thanks! > >>>>> best > >>>>> Bingyang > >>>>> > >>>>> On Sat, Dec 3, 2011 at 12:42 PM, Cliff Frey <[email protected]> > wrote: > >>>>> > >>>> > >>> > >> > >> > >> -- > >> Bingyang Liu > >> Network Architecture Lab, Network Center,Tsinghua Univ. > >> Beijing, China > >> Home Page: http://netarchlab.tsinghua.edu.cn/~liuby > >> > > > > > > > > -- > > Bingyang Liu > > Network Architecture Lab, Network Center,Tsinghua Univ. > > Beijing, China > > Home Page: http://netarchlab.tsinghua.edu.cn/~liuby > > > > > > -- > Bingyang Liu > Network Architecture Lab, Network Center,Tsinghua Univ. > Beijing, China > Home Page: http://netarchlab.tsinghua.edu.cn/~liuby > _______________________________________________ > 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
