Re: interface bonding
From: Igor Sobrado (sobrado_at_string1.ciencias.uniovi.es)
Date: 06/13/04
- Previous message: Brian A. Seklecki: "Re: interface bonding"
- In reply to: Brian A. Seklecki: "Re: interface bonding"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 13 Jun 2004 17:07:12 +0000 (UTC)
Brian A. Seklecki <lavalamp@spiritual-machines.org> wrote:
> the STP code in bridge(4) would need to be hacked on to take into
> account the new interface metrics. i don't know the highest-end CPU
> hardware available could nat/ipf/whatever net-appliance fast enough to
> drive demand for etherchannel / bonding. certainly overhead from software
> bridge(4) is self-eliminating. really high-throughput servers, maybe;
> still better off implementing all of this in hardware.
Hi Antoine, Gernot, and Brian!
I fully agree with all the ideas in this thread.
Support for IEEE 802.3ad would be great. I am not sure about the
price of gigabit hardware versus link aggregation. As I said,
gigabit hardware is not expensive now, and ten FastEthernet
adapters will probably be more expensive than a single gigabit NIC. On
the other hand, I doubt that we will find ten free IRQs on PC
hardware with a similar priority available for those NICs... :-)
But it is a way to double the bandwidth available on servers
without changing the networking technology. The amount of cables
required must be considered too.
Reliability is an important issue. A failure on a communication
link is not critical if it only reduces available bandwidth. But
a broken NIC can put noise in the network link too. A PC with
a damaged interface card does not perform well; the operating
system must be able to isolate the broken NIC instead of trying to
transmit half packets on that interface. Another approach is
providing backup lines, in the same way old 3Com switching hubs
worked.
The point of Brian is right too and must be considered. Hardware
engineers do not improve products as fast as network engineers.
In fact, a 1 MIPS computer was able to process packets on any
ARPAnet node, the interface message processors (IMPs) hardly
require sending more than a packet per second over 56k lines. Now,
high speed networking requires managing thousands of packets per second.
Hacking the bridge(4) code will not scale well on current networks.
One MIPS computers were able to run more than 10,000 instructions
for each packet, current 200 MIPS computers have difficults running
more than 500 instructions between packets.
One of the keys on the design of IPv6 was making headers (at least
the default header) more simple; in fact, IPv6 base header has a
small number of fields to reduce the time required to manage a packet.
IMHO, TCP/IP stacks must be as light as possible. In short, the
bottleneck on current networks is the computer, not the network
itself. I agree with Brian, we should not turn the bridge(4) device
on a resource expensive driver.
I think that it would be great releasing IEEE 802.3ad support
for NetBSD, but we must seriusly consider the post of Brian on this
thread before attempting to deploy an implementation.
Any ideas?
Igor.
-- Igor Sobrado, UK34436 - sobrado@acm.org
- Previous message: Brian A. Seklecki: "Re: interface bonding"
- In reply to: Brian A. Seklecki: "Re: interface bonding"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
