I think you're confusing MebiBytes/s (1,048,576's of 8-bit bytes) with megabits/s (1,000,000's of single bits). Local disk and file I/O is usually measured in MebiBytes/s, whereas network link speeds are usually measured in megabits/s.
Talking about remote fileserver performance requires caution because it's file I/O that rides on top of network I/O, so filesystem engineers (and file copy performance tools) want to talk about it in MebiBytes/s and network engineers (and network performance tools) want to talk about it in megabits/s.
Your Belkin N600 is capable of up to 300 megabits/s signaling, but you beware that Wi-Fi has a lot of overhead, so the rule of thumb is that your TCP throughput on Wi-Fi is usually about half your signaling rate. So 150 megabits/s, which is roughly 18 MebiBytes/s. But that's in idea RF conditions, with ideal TCP usage. Once you add the overhead of a remote filesystem protocol like SMB and whatever app you're using to do the copies, I think I'd be happy with 15 MebiBytes/s.
Then there's the question of how much throughput your WD ShareSpace 4TB NAS is capable of. According this review at SmallNetBuilder, that box is pretty slow and can only get about 20 MebiByte/s sustained throughput even on gigabit Ethernet. If that slowness is due to latency issues, then it'll have a big impact on what kind of throughput you can get from it even over wireless.
When you say "On the task manager, link speed varies between 76MB/s and 20MB/s", is that in reference to the network interface link speed or the file copy speed? And are you sure it's in MebiBytes/s or could it be in megabits/s? I would expect megabits/s since it's a network link.
If your Wi-Fi signaling rate is only 20 megabits/s at times, then your ideal TCP app throughput would be about 2.4 MebiBytes/s, further degraded by the WD ShareSpace NAS's latency and SMB and app copy overhead, and your 750 KibiByte/s throughput starts to make sense.
If I were you, there'd be two main things I'd be doing to speed this up:
Improve my Wi-Fi signaling rate to the 300 megabits/s the Belkin gear should be capable of. This might mean moving the PC closer to the AP, making sure wide (40MHz wide, HT40) channels are in use, making sure I selected nice clean channels in both 2.4GHz and 5GHz, and making sure my PC is joining on the less-likely-to-be-congested 5GHz band.
Improve my fileserver latency by getting a faster device to act as a fileserver.
First make sure that the Linksys AP and the D-Link AP are on separate, non-overlapping channels. When using typical 20MHz channel widths, channels 1, 6, and 11 don't overlap with each other. Manually set one AP to, say, channel 1, and the other to channel 11 (don't let them auto-pick or they may choose poorly on the next reboot).
If it's true that you had a D-Link DI-624, note that it did a nonstandard/proprietary 108mbps mode which probably used two contiguous channels' worth of bandwidth (i.e. 40MHz instead of the usual channel width of 20MHz). I don't know if it centered that 40MHz channel on the center frequency of the channel it was on, or if it used the next channel up, or the next channel down. But if you're not using any other D-Link 108 mbps gear from the same era, just turn off the proprietary 108 mbps mode of the D-Link (make it be a plain B/G 54mbps device) so that it only uses one 20MHz channel.
Make sure the two APs are not physically too close to each other. Even if they are on non-overlapping channels, if they are too close to each other, the transmissions from one can overload the notch filter on the other, desensitizing the other's receiver. (Think about how hard it is to hear people across the room while someone is shouting directly into your ear.) I recommend you keep APs at least 1 meter apart, although 2-3 meters might be even better.
After making the changes above, run a clean performance test using a tool such as IPerf, between a wireless client and a machine wired into the LAN port of the AP. Then repeat on the other AP. If you're still seeing problems, update your Question with the IPerf output from each case. (NB: Don't use some random file copy protocol on your local network, because those are often inefficient and muddle the measurement. Similarly, don't muddle the measurement by bringing your broadband connection into this, so don't use speedtest.net and don't time some download from the Internet.)
Seeing those well-quantified performance numbers would be a big help here. Note that under real-world conditions, 15 mbps is a respectable speed for TCP traffic over 802.11g, and most people never see above 25 mbps even under ideal conditions. See also: What's the maximum actual bit rate of an 802.11g connection?
Another thought that occurred to me as I was writing this is that if you had the Linksys and the D-Link in the same location because you preferred the Linksys's home gateway functions and the D-Link's wireless functions, why not just turn off the wireless interface of the Linksys? Let the Linksys just be your home gateway (NAT router, DHCP Server), and let the D-Link be just a simple bridging Wi-Fi AP.
Update: Okay, so rebooting the Linksys makes it work better, and you get respectable real-world 17-21 mbps IPerf TCP throughput for a few minutes, then it degrades again. That makes me suspect a memory leak or other resource problem in DD-WRT. Try going to the latest actual Linksys firmware for that revision of the WRT54G, and see if it does better. If it does, then try out the latest "stable" release of DD-WRT (if you weren't already up to date on a stable release line) with simple settings. Or maybe OpenWrt or Tomato or whatever else you want to try.
Best Answer
The rule of thumb for TCP throughput over Wi-Fi is that you can get 50-60% of your signaling rate. So in your case, you should see 75-90 megabits per second of TCP throughput.
Wait, why is your TCP window size just 8 KibiBytes? That strikes me as an absurdly low default.
Let's see what yours should be by calculating a "Bandwidth x Delay product" for your connection.
If Windows 7 is reporting that you're getting a 150 mbps signaling rate, that's 150,000,000 bits per second, so let's use that as the bandwidth number.
As for delay, well, my average ping round trip time over Wi-Fi to my AP is a little under 3 milliseconds. But you're going from one wireless client to another, which gets relayed by the AP (to avoid the hidden node problem), so I'm guessing if you pinged one of your wireless clients from the other one, you'd get a round trip time of up to 6ms.
So 150,000,000 bits/sec of bandwidth * 0.006 seconds of delay = 900,000 bits you need to be able to put "in flight" before getting an Ack back, in order to keep the pipe full.
900,000 bits / 8192 bits per KibiByte = about 110 KibiBytes of TCP window needed. Let's be generous and make it a nice round 128.
Try adding
-w 128Kto youriperfargument lists on both the client and the server to force the TCP window to something reasonable, and see if that helps.Since wireless is a fickle medium and there can sometimes be latency spikes due to transient noise forcing link-layer packet retransmissions, you could even try going larger than that, maybe up to 512KiB, but at some point there will be diminishing returns.
If increasing your TCP window size gets you up to around 75 megabits/sec of TCP throughput in IPerf, but if Windows 7 is defaulting your window size to 8KiB, then you probably need to figure out how to get Windows 7 to pick a better default TCP window size for all TCP connections.