jimmejames
There are a stack of reasons why this might be the case - but let me start by saying that on your HP you are getting roughly 30Mbps (or 30%). This is well within the normal range for a 100M NIC. Reasons that it might not be 100Mbps:
1) It will always be somewhat lower than the max, even if only by a few percent
2) CIFS is an extremely inefficient protocol, as is SMB - starting at the application layer, if your HP for any reason is slow in acknowledging a section, this will cause the transfer to slow down.
3) At the network layer, TCP must acknowledge every segment before the sender can start sending the next segment. If it is slow in doing so, this will cause the TCP back-off congestion mechanism to dramatically reduce the window size, which in turn causes the transfer rate to drop dramatically.
4) The switch can cause packet drops due to blocking or congestion, which forces retransmits. This also causes significant drops in transfer rate due to retransmitting data already transmitted and also due to the TCP congestion control mechanism backing off.
5) Auto speed and duplexing, or incorrect duplexing settings will cause collisions that massively impact transmit rates... often only in one direction.
6) A million other reasons!
Point 5 is unlikely as the performance impact would probably be much greater than you are experiencing. However, be aware that some NICs and switch ports don't play well together in auto-neg mode and cause this problem. You could try patching the HP directly to the internal NIC of the core. Assuming that at least one NIC does auto-crossover, you can then use ethtool to confirm that auto-neg is getting 100/Full duplex, then try the transfer again.
I assume that you are using KDE desktop to time these transfer rates? Try both "pushing" and "pulling" the data to see if there is any difference in each direction. This also goes to point 5.
Even on a quality 100M Cat5e LAN with an enterprise grade switch, I have often seen transfer rates to Windows machines around the 30-40M mark (although 60-70M is more common). Many NAS systems are based on Windows, so this has an impact. Be aware that in TCP transfers (particularly CIFS/SMB) the transfer rate can be highly variable. Windows machines not uncommonly ramp up very fast to 70M, then after a little while of consistent speed, suddenly back off to much slower, extremely variable speeds. Unless you are looking directly at the net utilisation whilst this happens, it isn't obvious and will just look like an overall slower speed.
Perhaps try the other NAS on the external network and compare speed.
On point 2 - perhaps try switching that NAS device to the other protocol - if it is currently CIFS (default) switch to SMBFS or vice versa.
NIC drivers and hardware compatibility between them and switches often causes performance problems. Try moving the NAS's from internal to external and vice versa to see if there is an element of that. And as I say, eliminating the switch as a cause is good too, by bypassing them and direct connecting. In this config (and others for that matter) ethtool is your friend and will tell you if the interfaces have autonegotiated the same speed and duplex settings. If you see 100/Half or worse 10/half then that is your problem.
Either way, I would recommend you move your HP NAS to the internal network anyway! There's no reason why a single rule on the core can't provide all the access to that NAS needed from the external network anyway....
Good luck!
