On Thu, 7 Mar 2013, Stan Hoeppner wrote:
I think you missed the point. SMB with TS<->DC is ~10MB/s, but should be more like 100MB/s. Run the FTP client on TS against the FTP service on the DC. Get and put files from/to the 300GB NTFS volume that is shared. If FTP is significantly faster then we know SMB is the problem, or something related to SMB, not TCP.
Don't know if it's obvious to everybody, so if you already know the internals of SMB, you can stop reading:
Older versions of SMB uses a 60 kilobyte block for transferring files. This works by requesting a block, waiting for that block to be delivered, then requesting the next one. Those who remember Xmodem will know what I'm talking about.
So if there is latency introduced somewhere, SMB performance deteriorates severely, to the point where if there is 30 ms delay, one can't really get more than 1 megabyte/s transfer speed, even if there is a 10GE pipe between the involved computers.
1 second / 30 milliseconds = 33 roundtrips, 60 kilbytes per roundtrip means 1980 kilobytes/s max theoretical throughput for SMB on 30 ms link.
Latencies can be introduced by trying to read for HDDs as well, so... this might be worthwile to look at.
I don't know exactly when the better versions of SMB/CIFS were introduced, but I believe it happened in Vista / Windows server 2008.
-- Mikael Abrahamsson email: swmike@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
