Is there any objective info, good or bad, on other low end ethernet chips, like the Davicom DM9102 or the Sis 900? Realtek/Davicom/Sis-based NICs sell for 4-5 dollars each down here, so they're usually what you'll find in small setups like router/firewall boxes.
-----Original Message----- From: Fleming, John (ZeroChaos) [mailto:[EMAIL PROTECTED] Sent: Friday, August 19, 2005 9:15 AM To: Scott Ullrich; M. Kohn Cc: [email protected] Subject: RE: [pfSense-discussion] Multi-WAN and routable subnets... Speaking rl nics we should post this somewhere in the faq section on why we don't like rl nics. This is from the driver's source. /usr/src/sys/pci/if_rl.c /* * The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is * probably the worst PCI ethernet controller ever made, with the possible * exception of the FEAST chip made by SMC. The 8139 supports bus-master * DMA, but it has a terrible interface that nullifies any performance * gains that bus-master DMA usually offers. * * For transmission, the chip offers a series of four TX descriptor * registers. Each transmit frame must be in a contiguous buffer, aligned * on a longword (32-bit) boundary. This means we almost always have to * do mbuf copies in order to transmit a frame, except in the unlikely * case where a) the packet fits into a single mbuf, and b) the packet * is 32-bit aligned within the mbuf's data area. The presence of only * four descriptor registers means that we can never have more than four * packets queued for transmission at any one time. * * Reception is not much better. The driver has to allocate a single large * buffer area (up to 64K in size) into which the chip will DMA received * frames. Because we don't know where within this region received packets * will begin or end, we have no choice but to copy data from the buffer * area into mbufs in order to pass the packets up to the higher protocol * levels. * * It's impossible given this rotten design to really achieve decent * performance at 100Mbps, unless you happen to have a 400Mhz PII or * some equally overmuscled CPU to drive it. * * On the bright side, the 8139 does have a built-in PHY, although * rather than using an MDIO serial interface like most other NICs, the * PHY registers are directly accessible through the 8139's register * space. The 8139 supports autonegotiation, as well as a 64-bit multicast * filter. * * The 8129 chip is an older version of the 8139 that uses an external PHY * chip. The 8129 has a serial MDIO interface for accessing the MII where * the 8139 lets you directly access the on-board PHY registers. We need * to select which interface to use depending on the chip type. */ -----Original Message----- From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: Friday, August 19, 2005 8:52 AM To: M. Kohn Cc: [email protected] Subject: Re: [pfSense-discussion] Multi-WAN and routable subnets... Right now a minimum of 3 public ips will be required between the two boxes: 2 - Each machine will share one REAL ip 1 - Each machine will both share one virtual ip ------------------------------------------------------------------- 3 total needed Carpdev changes this to need 1 total for both hosts but this is not ready in FreeBSD just yet. Scott On 8/19/05, M. Kohn <[EMAIL PROTECTED]> wrote: > We have a dual WAN setup (WAN and OPT1). > Every WAN interface takes a /29 subnet. > We have also an additionaly /29 subnet, which is routable (to the DMZ) > for every WAN. > In addition to that we also have an private class-C net for our DMZ. > > So I need to setup the DMZ with three different subnets, one outgoing > NAT and two routable. > > I setup DMZ interface with real IP and right netmask, which works > (extended NAT aktivated). > Than I tested adding a CARP virtual IP with /32, or CARP virtual IP > with /29 from the other subnet but no success... > > The CARP (failover) status page shows no MASTER and no carp interface > for this. And an ifconfig shows the carpX interface with no IP. > > I fear it is the same problem missing carpdev patch from OpenBSD like > Bill wrote yesterday, is it? > > > Regards, > Michael > > >
