Intermittent problems with LAN transfer speeds

[John]

Long -
Adam wrote:
> Any suggestions on how to test this effectively?
SInce this is very intermittant and to the point where you have to reboot my
first suggestion:
Run  top  and check for a  memory leak from a process. I had this once where
apache would slowly use up the memory then all the swap space until after a
month the box was thrashing  and a restart of apache (or box) was required.
In  top  the more 'Free' on the Mem and the Swap lines the better. Let top
run and/or check daily.
 I also recently discovered that 'screen' when installed using pkg_add is a
CPU pig but runs fine when installed from ports.

I've had my share of mis-matched switches - usually on the more expensive
brands that can't seem to handle auto-negotiate very well (but for the $$$
they should :)
and usually on a co-lo's gear or some peering point down the ISP so I had to
go out of my way to prove the problem was on their side. The first tests I
run are to ping with a large packet size to emulate file transfers and not
Internet browsing, this is a common problem I had with ISP techs - They
would say "Oh it pings fine, 0% loss" then I have to try and get them to use
large packets because file transfers, ftp's are not the same as browsing.

Network Testing:
I'll assume neither box is under heavy load prior to testing.
192.168.0.10 = W2K box,  so from the BSD:
ping -i 0.01 -D -p ff -s1472 -c 1000 192.168.0.10
man ping for the option's but a quick rundown:
-i 0.01 = interval between in secs.
-D - don't fragment the packets
-p ff = fill the packets with data.
-s 1472 = the size of each packet , if you get a "ping: sendto: Message too
long" then reduce this number by 5's. This (1472) was as high as I could go
on my LAN. Their is some overhead to the 1500 so you won't get that.  If you
have to reduce this by a lot to get proper output that would be strange.
-c 1000 = number of pings (side bar - I dropped in at a remote site and
turned on the console and found I'd left a regular ping running to the next
hop. I hadn't visited the site or rebooted the box in 6 months -doh- so I
use the '-c' flag now in case I get sidetracked)

Now try
ping -f -D -p ff -s1472 -c 250000 192.168.0.10
Replace '-i 0.01' with  '-f' to do a flood ping, BTW only do this on your
own network never public, else you may get visit from your ISP.
Bump up the count to -c 250000 or more.
For reference my results:
ping -f -D -p ff -s1472 -c 250000 192.168.0.10
PATTERN: 0xff
PING 192.168.0.10 (192.168.0.10): 1472 data bytes
...........
--- 192.168.0.10 ping statistics ---
250000 packets transmitted, 249994 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.610/0.785/54.674/0.264 ms

If you get 100% Packet Loss then your firewall is in the way.
If you get any other packet loss (well I dropped a few on the flood ping but
not enough to bump the %)  then it could be hardware on any of the 3 devices
or some kind of load on 1 of them.
On mismatched duplexes I 've seen between 10-25% packet loss. Another
symptom is (on a synchronous link) would be regular speed ftp transfers in
one direction and very slow in the other direction.

Some  Inexpensive hardware checks:
Put in a crossover cable between the 2 systems thus eliminating the switch
and retest.
Borrow another NIC and re-test in both boxes.
Probably won't help and only if you are comfortable doing it - enter the
BIOS on each box and change the settings for IRQ's and see if you can get
the NIC's on separate IRQ #'s - try to keep the video IRQ off the NIC's On
my BSD servers I also always do this plus disable the USB, printer and
serial ports if not in use.
Could it be hard disk errors/retry's on either box ? If the room is quiet
you might be able to hear it - check the logs.

Software tools for the BSD side.
Install the port (or package) 'trafshow' and then have it running on
consoles for each card.
trafshow -nifxp0
trafshow -nidc0
When you get the slowdowns you can see if something other than your transfer
is going on.
Check to see if someone is bashing on your public connection, but for 2
years probably not :)
Take the public NIC down during these slowdowns to see what happens.

Good luck let us know how you make out.
Regards, JT

Adam's History:
> Since I first installed FreeBSD 2 years ago, I have intermittent
> problems with my LAN transfer speeds. It doesn't happen often, but when
> it does, I've not found any solution other than rebooting the server.
>
> My network configuration looks like this:
> cable modem --> freebsd 5.1-R --> dlink switch --> win2k workstation
>
> I normally get appx 10MB/s between my two machines. However,
> occasionally I'll fire up a transfer and only get 50-200KB/s, which is
> really awful.
>
> I've tried rebooting the Win2k machine, disconnecting the ethernet
> cables, even power cycling the switch; nothing helps.
>
> The only thing that seems to help is rebooting the server, which I
> really hate to do.
> Here's the output of ifconfig:
> -$ ifconfig
> fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         options=3<RXCSUM,TXCSUM>
>         inet 192.168.56.2 netmask 0xffffff00 broadcast 192.168.56.255
>         ether 00:02:b3:a8:1d:19
>         media: Ethernet 100baseTX <full-duplex>
>         status: active
> dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet 146.115.***.*** netmask 0xffffff00 broadcast
> 255.255.255.255        ether 00:04:5a:7b:a7:d0
>         media: Ethernet autoselect (100baseTX <full-duplex>)
>         status: active