Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Sep 2002 18:21:06 -0400 (EDT)
From:      Kenneth Culver <culverk@yumyumyum.org>
To:        David Kelly <dkelly@hiwaay.net>
Cc:        Cody Swanson <cswanson@pei.eastlink.ca>, <freebsd-questions@FreeBSD.ORG>
Subject:   Re: Performance issues with natd
Message-ID:  <20020925182007.M55006-100000@alpha.yumyumyum.org>
In-Reply-To: <20020925220803.GC17390@grumpy.dyndns.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> > I just setup a 4.6.2 machine locally on my network at home to replace an
> > aging Linux NAT box I had going. Clients behind the new box can only get
> > 100k/sec downloads while clients behind the old Linux box (running ipchains)
> > get 400k/sec+ downloads off the same cable modem. Locally on the new FreeBSD
> > box I can get 400k/sec downloads with lynx, it just seems as if the NAT is
> > not framing packets right. Also, I have tried downloads from other freeBSD
> > machines, Linux machines and windows2000 machines from inside the network.
> > All max out at around 100k/sec on a download through the NAT box. Again, if
> > I download on the
> > box it self I can see 400k/sec.
> >
> > The machine is a PIII500 with 512mb ram. I have a 3com 3c905 nic for the
> > internal LAN and a D-Link 530TX revA card for the external link to my cable
> > modem. I rebuilt the GENERIC kernel with the following options:
> >
> > options         IPFIREWALL
> > options         IPDIVERT
> >
> > And I added the following lines to rc.conf (as noted in the handbook)
> >
> > gateway_enable="YES"
> > kern_securelevel_enable="NO"
> > ifconfig_xl0="inet 192.168.1.254  netmask 255.255.255.0"
> > ifconfig_vr0="DHCP"
>
> One thing to try is to invert the functions of vr0 and xl0.
>
> Another Good Thing To Try is to read man pages and source code on the
> devices you are using. This is found in /usr/src/sys/pci/if_vr.c:
>
>  *
>  * The Rhine has a serious flaw in its transmit DMA mechanism:
>  * transmit buffers must be longword aligned. Unfortunately,
>  * FreeBSD doesn't guarantee that mbufs will be filled in starting
>  * at longword boundaries, so we have to do a buffer copy before
>  * transmission.
>  */
>
> Am suggesting replacing the vr0 with something else such as another
> 3c905. I use a pair of Intel 10/100's in my PIII-500 box and would have
> to measure carefully to detect any thruput blockage.
>
> My guess as to what is happening is the additional copy required by the
> vr0 interrupts the rhythm between your inside client and the outside
> cable system so that data doesn't stream at full rate when passing thru
> but is OK when it stops at the FreeBSD firewall/router/gateway.
>
> In a PII-300 system I use an onboard 3c905 and an Intel 10/100. IPFW,
> NATD, DIVERT, essentially the same as you but only 64MB, and once again
> the restriction is too small to notice without careful measurement. It
> too is connected to a cable modem but throttled at 500kbits/sec.
>
> I have a spare PII but have not bothered to benchmark it ethernet to
> ethernet.
>
> When I last paid close attention to Linux it had some odd notions as to
> who and what should have priority and when. Years ago a Linusian
> trolling the FreeBSD lists was mighty proud of the lack of latency in
> his gigabit ethernet driver. The performance quoted was such the driver
> must have had nearly exclusive access to the CPU. Not so bad if you have
> nothing else to do but feed that driver.
>
All that said, it wouldn't hurt to try to use ipfilter or something like
that... that would avoid any extra money being spent if it solves the
problem (I doubt that it will but it might).

Ken


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020925182007.M55006-100000>