From owner-freebsd-net Sat Apr 8 9:50:11 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B854737BB77 for ; Sat, 8 Apr 2000 09:50:05 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id MAA01608; Sat, 8 Apr 2000 12:50:01 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Sat, 8 Apr 2000 12:50:00 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: thierry.herbelot@alcatel.fr Cc: net@freebsd.org Subject: Re: [long] test report for 4.0 and dc(4) In-Reply-To: <38D786E0.15EC21BC@telspace.alcatel.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 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: on motherboard > npx0: INT 16 interface > pcib0: on motherboard > pci0: on pcib0 > pcib1: at device 1.0 on > pci0 > pci0: on pcib0 > pcib1: at device 1.0 on > pci0 > pci1: on pcib1 > pci1: 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: at device 15.0 on pci0 > pci2: on pcib2 > dc0: port 0x1000-0x107f mem > 0x40000000-0x400003ff irq > 11 at device 4.0 on pci2 > dc0: Ethernet address: 00:80:c8:c9:88:bc > miibus0: on dc0 > ukphy0: on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ... other dc ports > isab0: at device 20.0 on pci0 > isa0: on isab0 > atapci0: 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: at 20.2 irq 11 > chip1: port 0xfc00-0xfc0f at > device > 20.3 on pci0 > > fdc0: 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: at port 0x60-0x6f on isa0 > atkbd0: irq 1 on atkbdc0 > psm0: irq 12 on atkbdc0 > psm0: model Generic PS/2 mouse, device ID 0 > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on > isa0 > sc0: 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: 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: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > plip0: on ppbus0 > ata1-slave: ata_command: timeout waiting for intr > ata1-slave: identify failed > ad0: 6149MB [13328/15/63] at ata0-master using UDMA33 > acd0: CDROM 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 > (+33) 1 46 52 47 23 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