I've seen a lot of little el cheapo network switches "go crazy" in the last year or so. The failure mode is super-slow transfers and packet drops. (I've seen it mainly with LinkSys switches in the last year). I'd suspect that, though not necessarily as the very first thing. Luckily, a simple speed test is pretty easy w/ "File and Print Sharing".

You can do a "quick and dirty" test for file server throughput by creating a large temporary file on your client computer with the fsutil command, and then timing the transfer to the server computer:

fsutil file createnew temp-file-name 209715200

That would create 200MB temporary file. You can do a quick copy w/ timing using the following script (from the directory where you created the temporary file, and assuming you have rights to copy to some share on the server computer):

@echo off
echo.|time
copy temp-file-name \\server-computer-name\share-name
echo.|time

Subtract the ending time from the starting time, convert to seconds, and divide 209715200 by the number of seconds elapsed to get bytes-per-second.

You should see upwards of 7,000,000 bytes per second (roughly 56Mbps) on a 100Base-TX LAN. Anything below that and I'd begin to suspect that something is up. Assuming that the server computer is reasonably modern, it should be able to fill a 100Mbps pipe with no problem. If you're seeing transfer speeds slower than that, I'd start to look at the error counters in the administration interface of the switch that the server and client are connected to. You could have faulty cabling, a duplex mismatch, or NIC driver problems. It's all just a matter of tracking the problem down methodically.

Edit: The file copy test is a nice test because you can conduct it w/o any third-party software. Since you've found a bottleneck does exist, the next step is to identify the bottleneck's cause.

The WSTTCP utility (available at http://www.pcausa.com/Utilities/pcattcp.htm) is a quick and dirty test of your NIC driver and network infrastructure hardware. It sends data that's not coming off disk or being written to disk, so the disk subsystems on the client and server end up being factored out of the equation.

On one machine, execute the following (after you've unpacked WSTTCP!) to "listen" for a connection:

wsttcp -r

On the other machine, execute the following to transmit a test to the remote machine:

wsttcp -t <hostname>

On 100Mbps Ethernet, you might want to modify the transmit command (re-running the receive command on the receiver before you start the transmitter again) to send more buffers, because you'll get slightly more accurate numbers with a longer test:

wsttcp -t -n8192 <hostname>

That will move 64MB of traffic. Increase the "8192" number to send more traffic.

You'll need to either allow the listener thru your firewall software on the listening computer (TCP port 5001, by default) or disable the firewall temporarily.

If you're seeing good transfer speeds with WSTTCP but slow transfers with the file copy, start looking at your disk subsystem (and consider running a hard disk drive benchmark). If the network transfers are still cruddy w/ WSTTCP, keep investigating the network infrastructure, cabling, NIC drivers, or NIC hardware.

Good hunting.

I have quite a similar setup WRT54GS with 60/70 computers and DDWRT 0.24SP1.

Try looking for connection timeout, if set to 3600 set it down to 300, look for max active connections as well and set it to a reasonable value like 1024/2048 for your network size. I'm rarely having more than 1000 active connections at a time with timeout set to 300.

[EDIT] For the memory issue it might be related to the maximum active connection setting. Do not set it to 4096 as it consumes quite a bit of memory. Set it to 1024.