Looking for some ideas. We have a pretty basic network setup in a remote office with very few users. Our ISP provides us with a 100MBit ethernet connection to their equipment, so this office is connected to our main office literally on a 100MBit switched connection. Traffic is passed to and from this office on a VLAN I created and gets passed through a queue in queue tunnel created by our ISP. At my end, I have a cisco catalyst switch. At the other end they have a 3Com 4400. They have been complaining of very general network speed issues for quite some time. To troubleshoot, I grabbed a guy from our ISP and did a few tests.
I tried another switch at the remote location with the same results. I also have another building set up in an identical fashion. If I try the same file downloads from the same server the files download in seconds. So I am now capturing packets on that VLAN trying to look for any clues that might indicate a problem from that location. With respect to SMB, what sorts of things would you folks look for that might indicate a bottleneck of some sort? asked 23 Mar '11, 09:11  tandrews |
3 Answers:
You definitely want to compare the round trip time between the sites. Imagine that you want to order one extra-large pizza for you and your friends. FTP is like "bring me one extra-large pizza with my favorite topics". The pizza man will deliver one box that keeps everyone happy. If the shop is in another town you wait a bit longer, but once the delivery is made you dig in and everybody is munching away. SMB is like ordering one slice at a time. A new order can only be placed, after the last slice has been delivered. Then you pick up the phone, place a new order, wait until the second slice is delivered, then order the next slice and so on. For the FTP approach you wait only once for the delivery. In the SMB approach the pizza boy has to make several trips to your home. If the pizza shop is far away the driving time will be longer than the time required to prepare the dish. It this large number of round trips that has a big impact on the transfer times. You might want to visualize the network load from a single transfer by looking at the IO Graph with Statistics -> IO Graphs. answered 23 Mar '11, 16:06  packethunter showing 5 of 9 show 4 more comments |
Just a few things to do with Wireshark when analyzing SMB:
Something more exotic:
External references: Article from the Microsofts Cable Guy on Auto Tuning Article from Citrix on the maximum number of SMB commands Video recording of a presentation on SMB 2.1 from Microsoft Hope that helps a little. Good hunting! answered 23 Mar '11, 09:40 packethunter Thanks Packethunter... Just to clarify a few things:
(23 Mar '11, 09:49) tandrews |
I'll second packethunter's suggestion of looking at the end-to-end latency. SMB is incredibly latency sensitive. This is one of the most common bottlenecks we face in our corporation. Out of the box SMB on Windows <=2003 experiences performance degradations as latency increases. The way the protocol will work, out of the box, will be to send just two (2) payload bearing packets leave the server, it will then wait until an ACK packet is received from the host before sending the next two packets. This is regardless of the negotiated MSS or RecvWindow size...this is a layer 4/5 bottleneck. You won't notice the problem in a low latency LAN. FTP is a much more efficient protocol for file transfer, but it offers few of the whistles/bells that SMB offers. SMBv2 (specifically that which is included in Windoze 2008R2) is much more efficient. There are several registry tweaks that you can put on the client and server to increase the SMBv1 throughput. Server 2003 Tuning doc from MS. There are lots of good hints in here, be sure to check out the TCPAckFreq key. http://download.microsoft.com/download/2/8/0/2800a518-7ac6-4aac-bd85-74d2c52e1ec6/tuning.doc answered 23 Mar '11, 12:41  GeonJay |
Understood. But as I indicated above, using the same laptop downloading the same file from the same server on a different (but identically configured) network, I get a significantly faster download time... seconds as opposed to minutes.
I believe that I can safely eliminate client and/or server configuration issues as the cause given the above.
I really believe that there is some sort of bottleneck between my remote switch and my local switch.
What do your ping times look like? From the "good" and "bad" site? Are you actually seeing lower throughput, or are there delays in transmission?
Check for a duplex mismatch. I'm assuming your latency between the two test beds are similar enough (not 5 ms vs 200ms for example)
Next time I order pizza, I make sure they FTP it to me instead of SMBing it ;-)
Hey PH, I'm going to use this analogy from now on, it's a good one!
We actually went to our ISP's switch in the CO that feeds our remote office. The problem exists there as well. The switch in question is a fast ethernet switch, the others are tied to Gig switches. So we may be on to something. Thanks for the suggestions.
I would appreciate if you share the solution with us.
Gladly. We had to cut our investigation short, but will likely continue it in a week or so. I will update here.
I had the same issue, but in the same machine, one day in the afternoon I copyied a 2 MB file in 4 seconds without retransmissions, but the next day in the morning it took like 2 minutes and the number of packet utilized in retransmissions mechanisms where like the 30% of the total numbers of the capture.
Regards!