[Click] Packet loss even at low sending rate

[Cliff Frey]

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 <bjornliu at gmail.com> 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 <cliff at meraki.com> wrote:
>