Interesting enough, this appears as a Samba server configuration issue:
I've never thought SMB server is the one the blame, until the other day I realized I'm getting way better throughput from FTP comparing to SMB, which means it should not be a NIC driver issue. Around the same time I've noticed if I run Linux instead of Windows on the same PC I'm also getting way better throughput through SMB, which is really odd.
After putting on telnet I've noticed this line in Samba server configuration file (/etc/samba/smb.conf):
socket options = TCP_NODELAY SO_RCVBUF=65535 SO_SNDBUF=65535
Now that's interesting. When it comes to Samba performance tuning everywhere I look it recommends setting SO_RCVBUF/SO_SNDBUF to around 8192 to start with, why this little box needs 64K? So I changed it to 8K to see how it looks:
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
This change will not survive from a reboot because the firmware will recreate this file based on smb.default, so to make it take effect I had to kill all "smbd" processes, and re-launch "/usr/sbin/samba/smbd -D" at the end. As I expected, after making this change now I'm getting a healthy 9~10MB/s read/write speed from my Windows XP laptop with a 100Mbps NIC, it was only 2~3MB/s before I made the change (7~8MB/s if I force DNS-323 run at 100Mbps instead of gigabit).
On my laptop with gigabit connection the throughput has also been improved, but still a bit slow, I will tweak more to see if I can make it better.
Probably SMB server on DNS-323 was not optimized for Windows client? That is odd considering the main purpose of SMB is sharing for Windows.