Date: Sat, 8 Apr 2000 12:50:00 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: thierry.herbelot@alcatel.fr Cc: net@freebsd.org Subject: Re: [long] test report for 4.0 and dc(4) Message-ID: <Pine.NEB.3.96L.1000408124322.963E-100000@fledge.watson.org> In-Reply-To: <38D786E0.15EC21BC@telspace.alcatel.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi there -- I've been doing some performance tests using if_dc with the kernel-based bridging in 4.0-RELEASE of FreeBSD. I was able to bridge at a rate of 55+Mbps, and source/sink without bridging at over 70Mbps on relatively old and slow Pentiums. This is with half-duplex hubs, so in the same collision domain for ACKs and so on. That said, I heard a report from a coworker that he was observing the following: he was using IPDIVERT to create a packet stream at the fastest rate possible (while(1) sendmsg();) and noticed that when a collision occurred on the ethernet segment, he would get a stream of buffer size errors from sendmsg, and no traffic would be sent out on the interface for about a second following the collision. He suggested this was a result of the interface reseting and dropping its queue following a collision, I have not had the opportunity to do any further testing--we switched to using the Intel-based PCI ethernet cards for further work for other reasons. If anyone else has seen this, we should take a look and see if it's an issue with our driver, or a function of the cards backoff mechanism. Without further testing, I'm reluctant to claim there is a problem, but figured I'd pass this on and see if anyone else had seen it. On Tue, 21 Mar 2000, Thierry Herbelot wrote: > Hello, > > I have a "SmartBits" test equipment on lease and I've played a little > with it and a Compaq PC with a 4-port 100Mbit NIC (DLINK DFE-570) > > The result is quite interesting : I've been able to route 4 full duplex > 50 Mbps flows with large frames (1500 bytes) with a negligible trafic > loss (see enclosed test_600x4.csv - comma-separated values) > > The first test bombed (this was with the GENERIC kernel), but everything > went fine with an "adapted" kernel config. > > the second test was a bit more difficult : the SmartBits was only > sending one flow of small Ethernet frames (64 bytes) at up to 36 Mbps > for the Compaq to route them from one port to another (the IP addresses > were fixed and the same for all frames) > > In this test, there is an interesting pattern : > - for less than 28 Mbps, the packet loss is acceptable (12 out of 386892 > for example), > - for 28,30 and 32 Mbps, the packet loss is very high (up to 80 % loss, > for example) > - for 34 and 36, the loss is back to normal (16 packets lost over 25 > secs) > (full results in test_25Mx64x1.csv, enclosed) > > when routing high numbers of small frames, the interrupt processing time > ends up taking all available ressource (according to systat -vmstat 1) > > All of the tests have been run without any "ipfw" processing. > > In fact, my test was to know wether a "normal" PC could do > some traffic shaping on a full 100 Mbps link. It seems the > answer is "maybe", but not with a standard PC (let's go > to PCI 64bits - 66MHz and a fast FSB ?) > > TfH > > here is the dmesg : > Copyright (c) 1992-2000 The FreeBSD Project. > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights > reserved. > FreeBSD 4.0-20000314-CURRENT #0: Mon Mar 20 18:22:33 CET 2000 > > herbelot@pc-bsd28.val9900.telspace.alcatel.fr:/usr/src/sys/compile/P6-dc > Timecounter "i8254" frequency 1193182 Hz > Timecounter "TSC" frequency 448054389 Hz > CPU: Pentium III/Pentium III Xeon (448.05-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x673 Stepping = 3 > > Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA > T,PSE36,MMX,FXSR,XMM> > real memory = 67108864 (65536K bytes) > config> q > avail memory = 62193664 (60736K bytes) > Preloaded elf kernel "kernel" at 0xc02bd000. > Preloaded userconfig_script "/boot/kernel.conf" at 0xc02bd09c. > Pentium Pro MTRR support enabled > md0: Malloc disk > npx0: <math processor> on motherboard > npx0: INT 16 interface > pcib0: <Intel 82443BX (440 BX) host to PCI bridge> on motherboard > pci0: <PCI bus> on pcib0 > pcib1: <Intel 82443BX (440 BX) PCI-PCI (AGP) bridge> at device 1.0 on > pci0 > pci0: <PCI bus> on pcib0 > pcib1: <Intel 82443BX (440 BX) PCI-PCI (AGP) bridge> at device 1.0 on > pci0 > pci1: <PCI bus> on pcib1 > pci1: <Matrox MGA G200 AGP graphics accelerator> at 0.0 irq 11 > xl0: <3Com 3c900B-TPO Etherlink XL> port 0x2000-0x207f mem > 0x42000000-0x4200007f > irq 11 at device 14.0 on pci0 > xl0: Ethernet address: 00:50:04:3f:09:0b > xl0: selecting 10baseT transceiver, half duplex > pcib2: <DEC 21152 PCI-PCI bridge> at device 15.0 on pci0 > pci2: <PCI bus> on pcib2 > dc0: <Intel 21143 10/100BaseTX> port 0x1000-0x107f mem > 0x40000000-0x400003ff irq > 11 at device 4.0 on pci2 > dc0: Ethernet address: 00:80:c8:c9:88:bc > miibus0: <MII bus> on dc0 > ukphy0: <Generic IEEE 802.3u media interface> on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ... other dc ports > isab0: <Intel 82371AB PCI to ISA bridge> at device 20.0 on pci0 > isa0: <ISA bus> on isab0 > atapci0: <Intel PIIX4 ATA33 controller> port 0x20a0-0x20af at device > 20.1 on pci > 0 > ata0: at 0x1f0 irq 14 on atapci0 > ata1: at 0x170 irq 15 on atapci0 > pci0: <Intel 82371AB/EB (PIIX4) USB controller> at 20.2 irq 11 > chip1: <Intel 82371AB Power management controller> port 0xfc00-0xfc0f at > device > 20.3 on pci0 > > fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on > isa0 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > atkbdc0: <keyboard controller (i8042)> at port 0x60-0x6f on isa0 > atkbd0: <AT Keyboard> irq 1 on atkbdc0 > psm0: <PS/2 Mouse> irq 12 on atkbdc0 > psm0: model Generic PS/2 mouse, device ID 0 > vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on > isa0 > sc0: <System console> on isa0 > sc0: VGA <16 virtual consoles, flags=0x200> > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/8 bytes threshold > ppi0: <Parallel I/O> on ppbus0 > lpt0: <Printer> on ppbus0 > lpt0: Interrupt-driven port > plip0: <PLIP network interface> on ppbus0 > ata1-slave: ata_command: timeout waiting for intr > ata1-slave: identify failed > ad0: 6149MB <Maxtor 90650U2> [13328/15/63] at ata0-master using UDMA33 > acd0: CDROM <Compaq CRD-8322B> at ata1-master using PIO4 > Mounting root from ufs:/dev/ad0s2a > dc1: TX underrun -- increasing TX threshold > dc0: TX underrun -- increasing TX threshold > dc2: TX underrun -- increasing TX threshold > dc3: TX underrun -- increasing TX threshold > dc2: TX underrun -- increasing TX threshold > dc3: TX underrun -- increasing TX threshold > dc0: TX underrun -- increasing TX threshold > dc1: TX underrun -- increasing TX threshold > > -- > Thierry Herbelot <thierry.herbelot@telspace.alcatel.fr> > (+33) 1 46 52 47 23 <thierry.herbelot@alcatel.fr> Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000408124322.963E-100000>