Hi Peter,
At 11:02 PM 26/03/2003 +0100, Peter T. Breuer wrote:
>I'll content myself with mentioning that ENBD has /always/ throughout
>its five years of life had automatic failover between channels. Mind
>you, I don't think anybody makes use of the multichannel architecture in
>practice for the purposes of redundancy (i.e. people using multiple
>channels don't pass them through different interfaces or routes, which
>is the idea!), they may do it for speed/bandwidth.
>
>But then surely they might as well use channel bonding in the network layer?
>I've never tried it, or possibly never figured out how ..
"channel bonding" can handle cases whereby you lose a single NIC or port --
but typically channeling means that you need multiple paths into a single
ethernet switch.
single ethernet switch = single point of failure.
hence, from a high-availability (HA) perspective, you're better off
connecting N NICs into N switches -- and then load-balance (multipath)
across those.
an interesting side-note is that channel-bonding doesn't necessarily mean
higher performance.
i haven't looked at linux's channel-bonding, but many NICs on higher-end
servers offer this as an option, and when enabled, you end up with multiple
NICs with the same MAC address. typically only one NIC is used for one
direction of traffic.
> > the reason why goes back to how SCSI works. take a ethereal trace of
> iSCSI
> > and you'll see the way that 2 round-trips are used before any typical i/o
> > operation (read or write op) occurs.
>
>Hmm.
>I have some people telling me that I should pile up network packets
>in order to avoid too many interrupts firing on Ge cards, and other
>people telling me to send partial packets as soon as possible in order
>to avoid buffer buildup. My head spins.
:-)
most "storage" people care more about latency than they do about raw
performance. coalescing packets = bad for latency.
i figure there has to be middle ground somewhere -- implement both and have
it as a config option.
decent GE cards will do coalescing themselves anyway.
cheers,
lincoln.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Mar 31 2003 - 22:00:26 EST