On Tue, Oct 01, 2002 at 08:34:35AM +0300, Ari Suutari wrote: > Hi, > > Great to see natd maintained. As original author, I kind of miss > the long command line options (ie. something like > --daemon in addition to -d). >
I used getopt(3) to parse the commandline because I hate to reinvent the wheel all the time. > The new code seems to use always a select-recvfrom combination > to get the data. Someone complained to me about the old natd performance > when that was used (the old code does not always use it). However, > I must say that I'm not sure about how much it affects performance > (having two syscalls instead of one). > In my first test I was able to nat a single ftp transfer at almost 100Mbps (10.10 MB/s) on a VIA C3 800 MHz (using 2 onboard fxp). Snapshot of top while doing transfer: last pid: 223; load averages: 0.21, 0.06, 0.02 up 0+00:21:44 12:07:17 24 processes: 2 running, 22 sleeping CPU states: 2.7% user, 0.0% nice, 43.6% system, 24.1% interrupt, 29.6% idle Mem: 5712K Active, 6596K Inact, 10M Wired, 4K Cache, 6880K Buf, 217M Free Swap: 128M Total, 128M Free PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 222 root 2 0 520K 284K RUN 0:21 34.89% 34.77% natd 84 root 2 0 2596K 1856K select 0:00 0.00% 0.00% sshd 223 root 28 0 1908K 1180K RUN 0:00 0.00% 0.00% top A single ftp transfer is probably not representative but shows the (top) performance. The new code uses the select-recvfrom combination because of the extended capabilities. A simple solution would be to set the divert sockets to nonblocking and do a select-recvfrom-recvfrom* loop as long as packets are received. If more speed is needed every syscall and packet copying should be avoided and natd/libalias should be merged into ipfw. -- :wq Claudio To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
