Date: Fri, 10 Sep 1999 14:53:15 -0400 From: Ugen Antsilevitch <ugen@xonix.com> To: hackers@FreeBSD.org Subject: NAT speed - part 1. Message-ID: <37D9539B.68103393@xonix.com>
next in thread | raw e-mail | index | archive | help
Good day.
This is part one of what is (hopefully) will be my long and hard look in the
IP routing in FreeBSD as we know it. I must admit that i am out of shape on
many subjects and so much of this data may be wrong because of me doing
the Wrong Thing.
Anyway - these are the compressed results of day of testing.
Machine - Celeron 450MHZ (overclocked) , 128Mb ram, WD IDE drive,
NE2000 compatible PCI 10Mbps card.
Test application: netpipe - do you know of anything better/more exact?
Test conditions: various packet sizes/amounts through the loopback.
Netowrk setup: with FIREWALL compiled in.
Here are some numbers (i am not going to give any long lists here, just a general idea).
a) Firewall set to pass everything. No other switching/routing.
1Kb data - 200Mb/s (thats Megabit just in case)
4Kb data - 400Mb/s
>4Kb data (up to 1Mb) - 400Mb/s
b) Firewall set to divert all traffic on lo0 to nat. Nat set in dynamic, does not translate
anything obviously. (In this configuration any packet sent to nat will be matched against
hash and immediately found a match. Since there is only one connection at a time,
nat's hash has no chains of linked values and this therefore is as fast as it can work.)
1Kb data - 55Mb/s
4Kb data - 98Mb/s
>4Kb data - 100Mb/s
Quite consistently as you can see, moving packets betwin kernel and user world and
then back is 4 times slower then doing all the work in kernel.
Obviously the difference comes mostly from kernel/user switch, since the processing
of a packet is quite similar to kernel procedures and in fact should not be more then
a couple of firewall rules/routing table rules in time equality.
c) Simulating load on the machine. Well, i have no idea how to simulate a load of real
working Apache servers and in fact this will vary greately depending on multitude of
things. Loads siumlated therefore using make's of large applications (kernel, pine, tcsh etc).
nat is turned off. all ipfw rules flushed.
4Kb data sent.
0 makes - 400Mb/s
1 make - 310-320Mb/s
2 makes 220-240 Mb/s
3 makes 190-220 Mb/s
I am really not sure what to make of it, it is fairly linear which is expected, however i
am not sure how to translate it into real world's data (machine loaded with web applications,
mail etc). Looking at %% of CPU usage from top does not give a good idea of loads since
make is not a single process and numbers given for gcc etc running under it are quite low
and vary over time (1.5% - 3% as opposed to >40% for each netpipe process).
d) I did some tests on the actual Ethernet, however at home the best i have is this and another
machine and 10Mb crosslinked wire. The only thing i found (which is almost obvious without
testing) is that up to 4Kb maximal transfer rates are not reached. Around 4Kb transfer rate becomes
7Mb/s and stays there, raising top to 8Mb/s around 12Kb of data. 80% performance is quite
characteristic of the 10Mb/s ethernet but i have no bandwith to try nat etc since these
numbers are quite lower then speed if internal kernel switching.
Therefore if any of you are interested in deeper understanding of this whole thing and have
3 machines with 100Mb ethernet on them, i would appreciate access to those to do some more
thorough testing. Also if anyone is in NYC are and can loan me just one machine and a couple
of fast Ethernet cards - i can stage it right here at home.
I didn't look at the kernel code implementing fast switching so i don't know at this point if
loopback traffic ever passes that, however changing net.inet.ip.fastswitching to 1 did not
influence any of this data. What other options do we have to play with? MTU size?
What else? I am however looking for major numbers, not minor tweaking. Also if anyone
has a good idea about traffic switching speeds in "real" routers such as Cisco - i would
appreciate a look at that.
Thanx!
--Ugen
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37D9539B.68103393>