2

Maybe I'm expecting way more from SMB2 than what's realistic. Here is the scenario.

  • Windows 7 Client (Local)
  • A) Win2008R2 Server (LAN -- 1GB, <1ms)
  • B) Win2008R2 Server (WAN -- 1GB, 10ms)
  • (Identical server hardware)

Scenario 1:
I have a single file, 1GB in size.
Transfer from Win7 to server A: 10 seconds
Transfer from Win7 to server B: 18 seconds

Scenario 2:
I have a directory, 275MB in size, approximately 2700 files.
Transfer from Win7 to Server A: 57 seconds
Transfer from Win7 to Server B: 551 seconds

Does the delay of only 10ms really cause that huge of a hit to SMB2, in scenario 2? I suppose this would make sense if SMB2 is chatting back/forth about each individual file (multiple calls per file), in addition to the time it takes to actually transfer the file, and it takes 10ms longer each way (client->server, server->client).

So I guess all I'm just asking -- is this truly as good as SMB2 gets over the WAN, without trying to play games with SMB2 acceleration, or other third-party tricks?


Update1:
To clarify: I'm not asking why lots of files take longer than one big one - I understand that this will add overhead despite the medium. I'm asking specifically if 10ms is enough to account for the difference of 10 minutes between server A, and server B, in scenario 2. I understand there is no precise yes or no answer.

Really just not familiar with how chatty SMB2 specifically, is. I acknowledge it HAS to be chatty, by nature of what it's doing. Just wondering what others have observed in similar situations. (transfer of complex directory structure -- over 10ms 1GB or higer link)

breckit
  • 43
  • 1
  • 4
  • What are the versions of srv2.sys and rdbss.sys on the server? – Greg Askew Jun 17 '14 at 14:24
  • 1
    @breckit There's a fairly easy way to test this yourself, you know... use ftp to transfer the files and see just how bad the transfer times are - essentially, repeat those four transfers in your question, using ftp. (I can't do this personally, and honestly, no one will be in a better position to test SMB2 performance on your network than you will be.) – HopelessN00b Jun 17 '14 at 14:51
  • @GregAskew srv2.sys: 6.1.7601.17608 rdbss.sys: 6.1.7601.17514 – breckit Jun 17 '14 at 15:03
  • @HopelessN00b definitely will evaluate other protocols for color, thanks. study started last night and just wondering if anyone obsessed about SMB2 over similar latency connection before – breckit Jun 17 '14 at 15:07
  • 1
    @breckit: You may want to re-test with the latest recommended hotfixes for File Services technologies described here: http://support.microsoft.com/kb/2473205 – Greg Askew Jun 17 '14 at 15:21
  • I am not a network guru but I have one question to ask and one point to make: `Question:` Is jitter on the WAN connection a factor? `Point:` The latency difference between server A and B is 10 fold. I don't see why you wouldn't expect a file transfer difference to approach 10 fold as well. That seems to bear out in Scenario 2. – joeqwerty Jun 18 '14 at 00:34
  • Again, I'm not a network guru but here are a few other things to consider (just spit-balling here): `1.` Is there a different MTU for the WAN connection as opposed to the LAN connection? A smaller WAN MTU means more packets being transmitted, carrying less data, which means more overhead, which means longer transfer times. `2.` Do you see any Duplicate ACK's and/or TCP Retransmits on the WAN connection? That's an indication of congestion and/or packet loss and is going to add overhead as those packets are retransmitted, causing longer transfer times. – joeqwerty Jun 18 '14 at 03:02

2 Answers2

2

No, that's not an SMB2 issue, it's a transferring-lots-of-small-files-over-any-protocol issue. In addition to more network overhead, you're dealing with a lot more seek time, and essentially random reads instead of sequential reads, so the disk operations are a lot slower as well. Test yourself with a USB flash drive or external hard drive, for example. And if you wish, a different network protocol, like FTP.

Your results will be very similar - transferring lots of small files in general takes a lot more time than transferring one large file. SMB2 may be poorly optimized (too chatty) for transferring many files and WAN links, but the basic performance issue you're seeing will persist, regardless of protocol.

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
0

10mc delay comes from where? It is WAY too high for a LAN and VERY small for a WAN.

And yes, it causes issues - SMB2 is quite chatty and not optimized for high latency. Many files is a LOT of operations. A lot. ALl running one by one. YOu would be better in case of scenario 2 to SPLIT the 2700 files and run multiple copy operations in parallel. THere is a reason MS did SMB3..

TomTom
  • 51,649
  • 7
  • 54
  • 136