"Kenneth D. Merry" wrote: > > Wes Peters wrote... > > Bill Paul wrote: > > > > > > Of all the gin joints in all the towns in all the world, Charles Randall > > > had to walk into mine and say: > > > > > > > Bill Paul has developed a driver for the Alteon Tigon 1 and 2 cards. > > > > > > > > http://www.freebsd.org/~wpaul/Alteon/ > > > > > > > > FYI, > > > > Charles > > > > > > > > -----Original Message----- > > > > From: David Miller [mailto:dmil...@search.sparks.net] > > > > Sent: Wednesday, August 18, 1999 1:55 PM > > > > To: freebsd-hackers@freebsd.org > > > > Subject: Gigabit ethernet support? > > > > > > > > > > > > Any supported cards in 3.2.x? The HCL pages don't list any:( > > > > > > The ti driver supports several cards, including the Alteon AceNIC, > > > the 3Com 3c985-SX, the Netgear GA620, the DEC EtherWORKS 1000, the > > > SGI PCI gigabit ethernet card, the NEC gigabit ethernet card and > > > possibly some from IBM as well, though I don't know the PCI vendor/device > > > IDs for those so I can't be sure (if you find them out, you can try > > > hacking them into the driver). All of these are supported by the same > > > driver because they're all OEMed from Alteon. > > > > We have two of the NetGear GA620's here, and they work quite nicely. I use > > them for testing throughput via Gig-E on our switches. Mine is running in > > a lowly PII/233, on a 32-bit x 33 Mhz slot, and can push bits at 320 Mbps. > > The GA620 will work in any 32 or 64 bit, 33 or 66 Mhz slot. A 64x66 slot > > would probably speed things up appreciably. > > I doubt a faster PCI interface would really speed things up. My guess is > that you've got some other bottleneck other than PCI bandwidth. Is the CPU > pegged on either end?
Not on mine, it's running about 45%. The other end is much faster, a PII/400, and is just discarding the packets, so it's not sweating. > I would recommend that you make sure you've got a couple of things tweaked, > they may increase your performance somewhat: > > - set your MTU to 9000, unless of course you're going through a switch that > can't handle it Not yet, that's part of what I will be developing. ;^) Due to architectural limitations, we may not be able to support jumbo frames larger than 8k. > - turn on net.inet.tcp.rfc1323, it enables support for TCP windows larger > than 64K OK. > - increase net.inet.tcp.sendspace and net.inet.tcp.recvspace to 256K. > You'll have to edit src/sys/socketvar.h and increase SB_MAX. From what > I've seen (this may not be quite correct, but it's close enough) SB_MAX > has to be double whatever you want to set sendspace and recvspace to. > This has the effect of changing the TCP window size to 256K, I think. > From what I've seen, increasing it to 512K is counterproductive unless > you've got a card with 1MB of SRAM on board. (The Netgear boards have > 512K.) OK. > And finally, netperf seems to work reasonably well for testing performance: > > http://www.netperf.org Cool. I've been using several tools, since we do our real performance testing with a SmartBits. I use spray to generate UDP traffic and a hacked-up version of tcpblast for tcp traffic. I'll clean it up and re-release it one of these days. > > They're relatively cheap, too, going for $339 at DataComm Warehouse. > > FWIW, NECX has them for $310. Cool. We don't have an account there; if I get one from DataComm all I have to do is give them the account number and it shows up on my desk the next morning. It's MORE convenient than going to the store. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
