The FNN (Flat Neighborhood Network) paradox

[Jon Tegner]

>
> A word of caution:
> Most (all?) switches will get horrendously confused, if you connect
> two (or more) channel bonded NICs to the same switch.
> Linux assigns the same MAC address to all channel bonded NICs (I believe
> that by doing so Linux actually does not comply to the RFC on trunking,
> hence even if the docs for a certain switch say that it supports trunking
> it doesn't mean that that it supports Linux-type channel bonding; I'm
> not really on safe ground here, please correct me, if I'm wrong).
> Most (all?) switches cannot handle receiving the same MAC address from
> different NICs. Hence if you plan on doing channel bonding buy as many
> switches as you buy NICs/per box and connect each channel bonded NIC
> in a box to a different switch. Even if you can configure your switch
> (using VLANs, etc.) to accept identical MAC addresses from different NICs,
> the setup must be a nightmare.

We are using an inexpensive D-link switch (DES-3225G), and are using channel bonding through two VLANS on that
(one) switch. Really don't know what kind of improvement to expect, so I'm attaching two figures, the first one
shows signature graphs (throughput as a function of time) using mpi and tcp with and without channel bonding
(obtained by netpipe). From this one it looks like channel bonding is working OK.

But when it comes to my application (simulation of a detonation in gas phase) improvement is not very spectacular
(not worth it?). The figure shows the same case for three different meshes (480x50 cells to 1920x200 cells), and
displays the speed up as a function of number of nodes.
Obviously I couldn't expect better scaling for the large case, but for the medium and the small one, are they
showing the kind of improvement one could expect? Or is it likely that something is wrong with our set-up?

Thanks in advance for any comments,

/jon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sign_graph.eps
Type: application/postscript
Size: 14596 bytes
Desc: not available
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20010222/59f7ffb5/attachment.eps>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: speed_up.eps
Type: application/postscript
Size: 12283 bytes
Desc: not available
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20010222/59f7ffb5/attachment-0001.eps>