inline... On Mon, Jun 8, 2009 at 6:03 AM, Faustino Frechilla<frechi...@gmail.com> wrote: > Hi again, > > I made some testing today in my desktop machine, I won't try it again > in the server until I make some progress in my machine since it is > shared and someone can kill me if I break the network connection again > :). > > About the issue playing the file 10 times slower, this only happened > in that shared server with catapulta linux when I ran with the latest > tcpreplay version, 3.4.2. This is the network card if that is of any > help (it is using the e1000 driver): > > 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 > Gigabit Ethernet (rev 12) > Subsystem: Hewlett-Packard Company NC373i Integrated Multifunction > Gigabit Server Adapter > Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 > Memory at f8000000 (64-bit, non-prefetchable) [size=32M] > [virtual] Expansion ROM at d1200000 [disabled] [size=2K] > Capabilities: [40] PCI-X non-bridge device > Capabilities: [48] Power Management version 2 > Capabilities: [50] Vital Product Data > Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ > Queue=0/0 Enable-
No, that should be the bnx2 driver. The e1000 driver won't work with Broadcom cards. Maybe Broadcom added a Intel compatibility layer (I doubt it), but if so, that's probably your problem right there. > Using the desktop machine I had no luck. These are the stats for > running the original SCTP file at the original speed. Playing the file > at a fixed rate usgin the --mbps option doesn't help. > > Actual: 97337 packets (45000654 bytes) sent in 136.50 seconds > Rated: 329675.1 bps, 2.52 Mbps, 713.09 pps Sorry, what did you mean "doesn't help"? Performance didn't match the --mbps option or you weren't able to reproduce the other problem? > Then I generated a tcp file and played it (instead of my SCTP one) at > original speed. The network connection behaved the same, after some > time it was gone. These are the stats running this TCP file at > original speed: > > Actual: 47596 packets (49788435 bytes) sent in 17.79 seconds > Rated: 2798675.5 bps, 21.35 Mbps, 2675.44 pps So the problem is specific to sctp packets? Have you tried unloading the sctp kernel module and see what happens? It shouldn't matter- the sctp driver shouldn't see the packets tcpreplay sends, but I guess anything is possible. > Setting manually the timing to random speeds in both files made no > difference, the network connection goes dead too, just as if I play > the file at original speed. I also looked for strange kernel messages > in the log but I found nothing. And more strangely, I am positive the > switch is not causing the problem. I played the file from one machine > to another without any switch, just a cable connecting them, and the > network interface of the machine playing the file is gone in the same > way. I ran out of ideas or things to check, any advise? Well, you can run configure with --enable-debug and then use -d5 to get lots of debugging. Should help track down where the delays are happening. As for dropping off the network, if you've removed the switch as a culprit then the problem is either hardware or your kernel/drivers. Tcpreplay doesn't use any "special" or non-standard API's which should be able to do this. The only other case like this was a bug in the OS X kernel which caused the wifi network card to disassociate from the AP when tcpreplay was run. If this was a bug in Tcpreplay, I'd have a few hundred people complaining by now. :) Have you looked in dmesg for any errors/warnings? > > This is the network card and driver in this Desktop machine I'm using > to test right now: > > 00:19.0 Ethernet controller: Intel Corporation 82567LM-3 Gigabit > Network Connection (rev 02) > Subsystem: Dell Device 027f > Flags: bus master, fast devsel, latency 0, IRQ 2299 > Memory at febe0000 (32-bit, non-prefetchable) [size=128K] > Memory at febd9000 (32-bit, non-prefetchable) [size=4K] > I/O ports at ecc0 [size=32] > Capabilities: [c8] Power Management version 2 > Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ > Queue=0/0 Enable+ > Capabilities: [e0] PCIe advanced features <?> > Kernel driver in use: e1000e > Kernel modules: e1000e You might want to try the e1000 driver (if it works with that chipset)- it's been around a lot longer then the e1000e and may be more stable. As I said, the dropping off the network has to be hardware/kernel related. Running much slower then it should be could be a tcpreplay bug, but I'd need to get a sample of the pcap in question to check. It could also be a kernel issue. It would be worth reading about timing and tuning in the manual: http://tcpreplay.synfin.net/trac/wiki/tcpreplay#ChoosingaTimingMethod http://tcpreplay.synfin.net/trac/wiki/tcpreplay#TuningforHigh-Performance -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ 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
