On Tue, May 20, 2008 at 2:29 AM, Daniel Migault <[EMAIL PROTECTED]> wrote: > >>> \# processing file: file.pcap >>> \# Actual: 5120395 packets (658752329 bytes) sent in 8084.26 seconds >>> \# Rated: 81485.8 bps, 0.62 Mbps/sec, 633.38 pps >>> >> >> Retried packets are when tcpreplay tries to send the packet and the >> the kernel comes back with an error. So yes, the kernel is >> "dropping the packet" but is telling us. >> >> Now if you're only doing .62Mbps and getting retried packets, then >> you've got something really hosed with your setup- you should be able >> to do 100's of Mbps before seeing this kind of error on most hardware >> nowadays. >> >> > True that I am not using state of the heart hardware, but since I am > replaying packets from a farm of servers, so maybe tcpreplay has > troubles to respect/evaluate the timing. Could it be an explaination?
Not sure what you mean a "farm of servers". If a bunch of boxes are all connected to a hub or a cheap switch, yeah that could cause serious problems. Same with using RealTek network cards (they're worthless POS's). Honestly though, I'd expect better much performance from an old Pentium II then what you're getting. Anyways, the lastest version of tcpreplay (3.3.1) breaks out the reasons for the retries. At least that would give you a starting point to debug this. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Tcpreplay-users mailing list Tcpreplay-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tcpreplay-users Support Information: http://tcpreplay.synfin.net/trac/wiki/Support
