After installing Bigleaf at a customer location(s), some users experience slower than expected file transfer speeds between sites. Other related issues are a delay while browsing file shares between sites, or opening Microsoft Office documents in a file share.

This article provides information about how to alleviate slower than expected speeds with legacy file sharing applications with on-premises Windows Servers functioning as File Servers, for example, Microsoft Windows Session Message Block (SMB). This article is not intended to be a step-by-step guide for Windows SMB or TCP tuning and configuration. Instead, it’s meant to be a starting point to find solutions and changes that may improve throughput for SMB file transfers.

Note: Before spending time debugging or making changes to your Windows environment, see the troubleshooting steps we describe in the Help Center article Site speeds are too slow.

Bigleaf Support highly recommends that customers perform their own due diligence to understand and test changes before deploying to production. Unless otherwise noted, most of these changes are benign and easily reversible.

Not covered in this document is how to use Group Policy or other configuration management tools to enforce and push changes in your environment. Many of the links to vendor documentation also contain solutions for other corner cases that could help in some scenarios, so we advise users to carefully read linked documentation.

Reasons for slow speeds

Microsoft Windows file sharing and the SMB protocol were designed to operate in LAN conditions. SMB transfer throughput is constrained by latency. Prior to using Bigleaf, a business could be operating multiple locations within the same metro area, where there would be “LAN-like” latency of 5-10ms between locations. It’s also common in these legacy WAN edge architectures that a business would have the same ISP at each location. Site-to-site communication would never leave that ISP’s edge network, so latency is minimal. However, in this architecture, a customer has no last-mile diversity or Bigleaf’s optimized connectivity to deliver reliable internet.

The Bigleaf site-to-cloud SDWAN overlay architecture transports all internet and site-to-site traffic to your configured Bigleaf Point of Presences (POP). In some metro areas, there could be up to 15-20ms of latency to the nearest Bigleaf POP. The transition from the previously described legacy WAN architecture to Bigleaf could increase latency between sites from 10ms to 30ms.

The potential throughput difference can be calculated. For example, at 30ms, potential throughput could be 71Mbps with a single TCP connection. By comparison at 10ms, potential throughput is 214Mbps (see TCP throughput calculator). In addition, there is often other overhead that lower these throughput values by up to 20%, such as IPsec overhead for the site-to-site connectivity and/or Bigleaf’s SDWAN overhead.

Solutions and tuning

Most of the configuration changes are made using Windows PowerShell in a Microsoft Windows environment. Refer to their documentation for Set-SmbClientConfiguration and Set-SmbServerConfiguration, which has basic info, syntax, and default values.

SMB multichannel

For high performance Windows file sharing, using SMB multichannel is highly desirable. The earlier throughput calculations don’t have this feature, as they are for a single TCP flow. Most common between an end user client and file server, you’d have 2 or 4 TCP flows enabled by SMB Multichannel, which could result in 2-4x speeds. SMB Multichannel must be enabled on both the client and server in the file transfer. Refer to the Microsoft documentation Deploy SMB Multichannel on SMB multichannel deployment and requirements. It is likely both server and client will rely on Receive Side Scaling (RSS) to meet the requirements, especially on the client side.

Not all network adapters on end user computers support RSS. You can check this with the PowerShell command Get-NetAdapterRSS, or refer to the section "Verify that SMB Multichannel works" in the Deploy SMB Multichannel article. The Intel i219 is a very common desktop computer NIC, and it does not support RSS. As a comparison, the Intel i211 NIC does support RSS. WiFi NIC’s will not support RSS.

In addition to ensuring that SMB Multichannel is enabled, you should lower the connection threshold to always use it. This blog post from a Microsoft engineer discusses a recommended SMB client configuration on end user computers:

Set-SmbClientConfiguration -WindowSizeThreshold 1

SMB client tuning

Disable bandwidth throttling across high-latency links. If a file transfer across a WAN or the Bigleaf service is unstable with high peaks and valleys seen in transfer progress graph, disabling bandwidth throttling should enable steadier transfer, possibly with higher speeds.

Set-SmbClientConfiguration -EnableBandwidthThrottling 0

Another method to optimize SMB file transfers across a WAN is to reduce protocol overhead. Reducing the number of SMB protocol exchanges increases the uptime of data transfer rates. Each of these next SMB client configuration changes can optimize an end user client computer for accessing remote file shares, particularly over high-latency networks. A General tuning parameters for clients article from Microsoft talks more about each of these. The end result is higher potential throughput or more quickly rendered file and folder enumeration.

Set-SmbClientConfiguration -MaxCmds 1024
Set-SmbClientConfiguration -FileInfoCacheEntriesMax 8192
Set-SmbClientConfiguration -DirectoryCacheEntriesMax 4096
Set-SmbClientConfiguration -FileNotFoundCacheEntriesMax 8192

SMB server tuning

The primary source for tuning and configuration is Microsoft’s Performance Tuning for SMB file servers. Your version of Windows can impact performance and configuration options due to different SMB client and server default values and other kernel and networking stack improvements. This is mentioned in the previous link and also in Performance Tuning Network Adapters.

Set-SmbServerConfiguration -MaxThreadsPerQueue 40
Set-SmbServerConfiguration -AsynchronousCredits 2048
Set-SmbServerConfiguration -MaxWorkItems 4096

Create or modify the REG_DWORD value of ‘64’ in HKLM\System\CurrentControlSet\Control\Session Manager\Executive\AdditionalCriticalWorkerThreads

Set-SmbServerConfiguration -TreatHostAsStableStorage $true

Setting TreatHostAsStableStorage to true, as seen above, can improve file transfer performance. Only set this to true if the underlying storage system has a battery-backed write cache or other write protection to prevent data loss or corruption in the event of a power loss or unexpected shutdown. Data could be lost or corrupted if it was only stored in volatile memory and not yet written to non-volatile storage.

TCP and Networking Server Changes

From Performance Tuning Network Adapters, some network adapters may be configured by default with too low buffers to conserve memory. In transfer-intensive scenarios, modifying these values can improve performance. You can determine the value prior to changing it with Get-NetAdapterAdvancedProperty -RegistryKeyword "*Buffers”:

Set-NetAdapterAdvancedProperty -RegistryKeyword "*ReceiveBuffers" -RegistryValue 2048

Set-NetAdapterAdvancedProperty -RegistryKeyword "*TransmitBuffers" -RegistryValue 2048

If you’re using VMware virtualization for your Windows Servers, best practices recommend using vmxnet3 instead of e1000e for your virtual networking adapter. Vmxnet3 has a 10Gbps link speed, while e1000e is 1Gbps. This will increase the default TCP window size before calculating scaling from 64KB to 128KB.

You can easily check this from the Windows Server using ipconfig or Get-NetAdapterAdvancedProperty. If you see Intel(R) 82574L, then the e1000e NIC in VMware is being used.

Be aware of some well-known caveats, such as those described in https://kb.vmware.com/s/article/87353. Perform the necessary due diligence and testing before making this change to validate that your Windows Server version and environment are compatible with this change.

Underlying problem and known issues

By default on Windows 10 and Server 2019, a TCP connection for an SMB file transfer will not exceed a 262KB TCP window size. The earlier throughput calculations alluded to this limitation. This is the underlying problem dragging throughput over high latency links. Description of Windows TCP features: Windows scaling and TCP receive window autotuning discuss this further. You can double check TCP window size and scaling factor with a packet capture to examine the initial TCP handshake and subsequent data transfer packets in an SMB file transfer.

If you’re transferring many small files, the protocol overhead will cause slow transfer speeds. Microsoft’s documentation speaks to this in more detail: Slow transfer of small files.

Need help?

If you’re troubleshooting a slow file transfer issue and you require additional assistance or questions about this content, contact Bigleaf Support. It’s always a valuable first step to verify and validate WAN circuits, and we can help with this and other site-to-site connectivity troubleshooting.