bandwidth and multiple NICs - BSD
This is a discussion on bandwidth and multiple NICs - BSD ; Good Evening Newsgroup!
Today I suddenly become interested in the topic of using multiple network
interfaces in the same machine to increase network transfer speed to and
from this machine.
I learnt about this in concept years ago in college, ...
-
bandwidth and multiple NICs
Good Evening Newsgroup!
Today I suddenly become interested in the topic of using multiple network
interfaces in the same machine to increase network transfer speed to and
from this machine.
I learnt about this in concept years ago in college, and in theory I am
relatively familiar with the topic (at least I believe so), but I have
never tried it in practice.
The plan is as follows:
I have two machines, both running FreeBSD 6.2-PRERELEASE. I also have an 8
port 10/100 desktop switch the machines are hooked up to. I'd like to add
one extra 100Mb/s interface card to each of the test machines and
configure them to see how much I can increase (maybe double) the transfer
speed between the hosts. For this I will need to do some magic on FreeBSD
so that both NICs are listening and transferring on the same IP address.
How can I do that magic? Could someone point me to some appropriate
reading on this, or tell me the keywords for this topic I should look for
in the handbook, faq or google.
Thanks!
Regards,
Keve
--
if you need to reply directly:
keve(at)mail(dot)poliod(dot)hu
-
Re: bandwidth and multiple NICs
Keve Nagy wrote:
> Good Evening Newsgroup!
>
> Today I suddenly become interested in the topic of using multiple network
> interfaces in the same machine to increase network transfer speed to and
> from this machine.
>
> I learnt about this in concept years ago in college, and in theory I am
> relatively familiar with the topic (at least I believe so), but I have
> never tried it in practice.
> The plan is as follows:
> I have two machines, both running FreeBSD 6.2-PRERELEASE. I also have an 8
> port 10/100 desktop switch the machines are hooked up to. I'd like to add
> one extra 100Mb/s interface card to each of the test machines and
> configure them to see how much I can increase (maybe double) the transfer
> speed between the hosts. For this I will need to do some magic on FreeBSD
> so that both NICs are listening and transferring on the same IP address.
> How can I do that magic? Could someone point me to some appropriate
> reading on this, or tell me the keywords for this topic I should look for
> in the handbook, faq or google.
man ng_fec
>
> Thanks!
>
> Regards,
> Keve
>
--
Michel TALON
-
Re: bandwidth and multiple NICs
Keve Nagy wrote:
> Good Evening Newsgroup!
> Today I suddenly become interested in the topic of using multiple network
> interfaces in the same machine to increase network transfer speed to and
> from this machine.
> I learnt about this in concept years ago in college, and in theory I am
> relatively familiar with the topic (at least I believe so), but I have
> never tried it in practice.
> The plan is as follows:
> I have two machines, both running FreeBSD 6.2-PRERELEASE. I also have an 8
> port 10/100 desktop switch the machines are hooked up to. I'd like to add
> one extra 100Mb/s interface card to each of the test machines and
> configure them to see how much I can increase (maybe double) the transfer
> speed between the hosts. For this I will need to do some magic on FreeBSD
> so that both NICs are listening and transferring on the same IP address.
> How can I do that magic? Could someone point me to some appropriate
> reading on this, or tell me the keywords for this topic I should look for
> in the handbook, faq or google.
I don't know the BSD specifics, but typically that means
aggregating/bonding/trunking the two NICs together. Note though, that
unless you use a potentially unpleasant round-robbin packet
scheduling algorithm, aggregation/bonding/trunking does _not_ increase
the performance of a single "flow" (eg TCP connection). It only
increases the aggregate throughput of flows between the endpoints.
Why might round-robbin packet scheduling be unpleasant? Because it
can lead to out-of-order traffic, and if there is enough out of order
traffic, it can make TCP rather nonplussed.
If you need a single TCP connection between a pair of machines to go
faster, generally one needs to install a faster NIC.
rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway... 
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
-
Re: bandwidth and multiple NICs
Begin
On 2007-02-01, Rick Jones wrote:
> I don't know the BSD specifics, but typically that means
> aggregating/bonding/trunking the two NICs together.
[snip: useful note on round-robin drawbacks in this application]
I'll chip in with a mention that the term is ``fast etherchannel'' (in
the case of fast ethernet, presumably s/fast/gigabit/g but who knows),
and that is where the already mentioned ng_fec gets its name. The
associated manpage has an usage example.
Alternatively, there is ng_one2many.
--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.
-
Re: bandwidth and multiple NICs
Michel, Rick & JPD,
Great help, guys.
Thank you very much!
These pointers and keywords are exactly what I was after.
JPD is right (and this is annoyingly usual with him!
) regarding the fec
-> gec correlation. Both the "gigabit etherchannel" and "gec" terms exist,
and also belong to Cisco as "fast etherchannel" or "fec" does. Googling
for any of these keywords yields multiple useful hits.
I red the ng_fec and ng_one2many man pages, still trying to sort out which
one is better for what.
It appears that our (FreeBSD's) ng_fec applies to everything ethernet,
therefore also works for gigabit (acts for a nonexisting ng_gec).
I also found references for "ng_fec hashes based on layer2 (MAC)". Now I
couldn't honestly state that I understand what this hashing thing really
is, but since I plan to increase my bandwidth for tcp/udp traffic between
2 hosts (and tcp/udp/ip are layer 3 and 4) I assume that ng_fec might not
exactly be what I need. On the other hand, "man ng_one2many" has an
example mentioning an actual 4x faster point-to-point connection between
two IP peers, so I thing I am better off starting with ng_one2many.
Thank you again!
Your help is very much appreciated!
Best regards,
Keve
--
if you need to reply directly:
keve(at)mail(dot)poliod(dot)hu
-
Re: bandwidth and multiple NICs
Begin <52n2v9F1p6u75U1@mid.individual.net>
On 2007-02-04, Keve Nagy wrote:
> I also found references for "ng_fec hashes based on layer2 (MAC)". Now I
> couldn't honestly state that I understand what this hashing thing really
> is, but since I plan to increase my bandwidth for tcp/udp traffic between
> 2 hosts (and tcp/udp/ip are layer 3 and 4) I assume that ng_fec might not
> exactly be what I need.
ng_fec looks at the destination mac addresses to work out which NIC
to hand the packet to. Alternatively, it can use the destination IP
for that decision -- but that means the packet has to be an IP packet.
Either means that a single target will always use the same pipe. To be
useful to you it would have to hash on TCP port numbers instead. And
even then that may not be enough as it may be that you're using lots
of consecutive TCP connections and not enough parallel ones.
> On the other hand, "man ng_one2many" has an
> example mentioning an actual 4x faster point-to-point connection between
> two IP peers, so I thing I am better off starting with ng_one2many.
The drawback there is that you're stuck to a round-robin algorithm. That
will work for your two hosts, but it does add a risk of out-of-order
packets. As already pointed out, if those happen too often then TCP
performance will suffer -- defeating the purpose.
In your case you're likely to be better off with gigabit or something
even better, altough ng_one2many may be interesting to test with.
It makes me wonder, though, whether some queueing implementation like
dummynet could be adapted to do useful things here. But I'll have to
leave the answer to someone who actually knows things about that. :-)
--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.