HI, I 'am analysing very poor performances between a windows 7 pc and an Hitachi NAS Protocol used is SMB2. A sniffer trace has been made on the PC. Minimum bandwith between the two ends is 100 Mb/s : -protocol=SMB2 -pc says MSS=1460, HNAS says MSS=1460 -pc says windows scaling factor 8 , HNAS says windows scaling factor 3 -RTT between the two ends =14ms -No retansmission, no segment lost , no dup ack -Troughput of transfer is about 1,2 Mb/s The PC receive about 123 MB of applicative bytes(about 230 files) from the NAS and this takes about 970 s . (when the PC gets the same among of data (and same number of files) from a another remote site with an higher RTT of 23 ms , it takes only 600 s ..) The PC always advertises a 64KB window (64 KB plateau curve). Bytes in flight (send by the NAS) show only a 2 KB plateau curve (since the PC requests only PDU of 2048 Bytes, I presume the server cannot sends more without an acknowledge, this may explain the seen value of bytes in flight) My explanation for this slow transfer is : The PC uses very often SMB2 READ REQUEST of 2048 Bytes instead of higher length (seen with wireshark io graph using "smb2.read_length" filter) This behavior generates too many applications turns and the latency makes the rest ... Well, at those steps of my investigations my questions are : How the heck does not the PC send SMB2 READ REQUESTs with a requested "read length" greater than 2048 ? Why is the PC advertised received windows at only 64KB (according it has a windows scaling factor of 8, it could increase at 16MB maximum..) Any advice would be appreciated , regards jm asked 27 Oct '15, 06:15  jmnogues |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
Wireshark will tell you what is in the frames and you've found that yourself. However it won't be able to tell you why a system behaves in a certain way.
sounds like a good question for the Microsoft support people.
BTW: Did you search this site for SMB? I believe we had similar cases, but I can't remember if there was a solution.
SMB2 has a 64k limit, can't remember the math. There is a registry setting.. don't quote me but I think it was DisableLargeMtu=0 in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters
Edit: it has to be enabled on both ends for it to work when both are windows boxes
"SMB2 has a 64k limit, can't remember the math"
In the "SMB2 NEGOTIATE Response" of the server we see "MaxReadSize (4 bytes): The maximum size, in bytes, of the Length in an SMB2 READ Request that the server will accept. (https://msdn.microsoft.com/en-us/library/cc246561.aspx)
In my case the server is effectively giving this value 65536 which seems to be the default for SMB2.
So this would let think that when receiving a 64K Maxreadsize from the server, the client will unconditionaly sets its windows size to 64K.. why not , seems rather logical ..;-)
Anyway this is not the main issue and I would even be very happy if the 64K Windows was really used on the wire (i.e.if bytes in flight were 64K and not only 2K ..;-)
But as mentionned above , the client requests only 2048 bytes blocks despite the server can accept 65536 bytes blocks .. ;-(.
jm