8.0 network problem

[Jeremy Chadwick]

On Sun, Jul 04, 2010 at 07:52:11PM -0500, David Warren wrote:
>      I've got a persistent problem with my LAN.  I'm running a FreeBSD 8.0
> box as a home server performing the following functions for wired and
> wireless networks: router; firewall; DHCP server; and file server.  For what
> it's worth, I've got ZFS up and running as the main filesystem.  The
> recurring issue is that file transfers from the FreeBSD box to computers on
> the wired network (gigabit) start out fast and then become agonizingly
> slow.  I'm sharing home directories over Samba, and those transfers work
> briefly and then tail off to a few kilobytes per second.  The failure is
> somewhat predicatable in that it tends to happen once a few hundred
> megabytes have been transferred.

Your system has 3 different network interfaces on it (em, ral, nfe), but
you don't tell us across which interface the slow transfers happen.  You
also don't tell us which firewalling stack you're using (ipfw, ipfilter,
pf).  Let us know.

I'm going to make the assumption that based on your "...on the wired
network (gigabit)..." statement that the transfers are going across the
em0 interface, but again, I'm not sure.

Relevant interfaces (wlan0 is tied to ral0):

> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>         options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
>         ether 00:0e:0c:b7:71:44
>         inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
>         media: Ethernet autoselect (1000baseT <full-duplex>)
>         status: active
> ral0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 2290
>         ether 00:1f:1f:3f:76:f3
>         media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap>
>         status: running
> nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>         options=8<VLAN_MTU>
>         ether 00:01:29:d4:2d:6b
>         inet XXX.XXX.XXX.XXX netmask 0xfffffc00 broadcast 255.255.255.255
>         media: Ethernet autoselect (100baseTX <full-duplex,flag0,flag1>)
>         status: active
> [...]
> wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>         ether 00:1f:1f:3f:76:f3
>         inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
>         media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap>
>         status: running
>         ssid FreeBSD_AP channel 7 (2442 Mhz 11g) bssid 00:1f:1f:3f:76:f3
>         country US authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit
>         txpower 0 scanvalid 60 protmode CTS dtimperiod 1 -dfs

First and foremost: is the problem specific to Samba?  Can you reproduce
the problem when using the FTP protocol?

Are there any indications of problems in "dmesg" when the issue is
happening?

Can you provide output from "vmstat -i" while the problem is happening?

Can you provide output from "pciconf -lvc"?  Only interested in the
sections relevant to the above devices.

Can you provide contents of /etc/make.conf, /etc/sysctl.conf, and
/boot/loader.conf?

Have you looked at "netstat -I <iface> -indb" output during the slow
transfers to see if there's any indication of problems, or some sort of
"common rate" (transfer, etc.)

Does disabling the firewalling stack improve things at all?

Can the slowness be reproduced using benchmarks/netperf or only when
using something that involves actual disk I/O?  (To use netperf you'll
need two FreeBSD boxes).  If only disk I/O, then ZFS analysis might be
needed (there are some performance adjustments that are often required).

Focusing more on em0:

Have you tried disabling rxcsum and txcsum (using ifconfig) to see if
there's any improvement?  I don't see TSO used by your interface, so
that should rule out any problems with that feature.

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |