Hello Gary, Thank you for your mail.
We are using a USB 3G wireless modem rated at 21Mbps on a 21Mbps network. Depending on site, we get somewhere between 6 and 14Mbps. When doing large HTTP transfers, the throughput is fine, and running wireshark on captures doesn't show signs of retransmissions, so it's not a 3G or networking stack problem. But when throughput is high, tcpdump's end-of-session stats shows that "packets dropped" is approaching 25%, and wireshark's tcp.analysis.ack_lost_segment filter shows lots of dropped packets. The modem does not support ethtool -g. Running tcpdump at a higher priority helps, as does capturing to a RAM disk, but does not solve the problem. On Thu, Sep 3, 2009 at 1:51 PM, Gary Gatten<[email protected]> wrote: > I don't know much about details of pf_ring, but if you have lipcap packet > loss on a 3G network something is not right. IMO I'd fix that vs using > pf_ring. I hope the above details helps. I suspect that the in-kernel buffer for captured packets is very shallow, and tcpdump is not scheduled often enough or reliably enough to pick up all captured packets from the kernel, leading to loss of captured packets. Can you be more specific about what the "something not right" might be, and how it might be fixed? Thank you, Mitch. _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop
