We too are experiencing the same problem. Anything larger than what can be transferred in the initial download burst (~3.7mb for us), trickles off to ~1-4kb a second regardless of the bandwidth available.
It seems to be a problem specific to and common with the SonicWall PRO 2040 Firewall - https://discussions.apple.com/message/12250946?messageID=12250946
The root of the problem is the firewall and the best long-term fix is to find a setting on the firewall to allow the TCP Window Scaling option to be turned on and also use the initiating machine's TCP Window Scale Factor correctly in the initialization of the connection.
Though this article refers to routers, the same logic applies to what's happening with the SonicWall Pro 2040 Firewall, http://lwn.net/Articles/92727/:
The details are still being figured out, but it would appear that some routers on the net are rewriting the window scale TCP option on SYN packets as they pass through. In particular, they seem to be setting the scale factor to zero, but leaving the option in place. The receiving side sees the option, and responds with a window scale factor of its own. At this point, the initiating system believes that its scale factor has been accepted, and scales its windows accordingly. The other end, however, believes that the scale factor is zero. The result is a misunderstanding over the real size of the receive window, with the system behind the firewall believing it to be much smaller than it really is. If the expected scale factor (and thus the discrepancy) is large, the result is, at best, very slow communication. In many cases, the small window can cause no packets to be transmitted at all, breaking TCP between the two affected systems entirely.
Similar to what was mentioned above, there are workarounds for individual machines - http://prowiki.isc.upenn.edu/wiki/TCP_tuning_for_broken_firewalls, by turning off the rfc1323 TCP extension, the firewall is never given the opportunity to pass a TCP Window Scale Factor of 0 and instead passes along that the rfc1323 extension is not enabled, presumably using the maximum allowed window size by TCP without the rfc1323 extension, which is 64kb.
Commands we've used on our various machines as a temporary workaround:
Ubuntu 10.10:
Change takes effect immediately:
sudo sysctl -w net.ipv4.tcp_window_scaling=0
Permanent change, after next reboot:
sudo sh -c 'echo "net.ipv4.tcp_window_scaling=0" >> /etc/sysctl.conf'
Mac OSx:
Change takes effect immediately:
sudo sysctl -w net.inet.tcp.rfc1323=0
Permanent change, after next reboot:
sudo sh -c 'echo "net.inet.tcp.rfc1323=0" >> /etc/sysctl.conf'
Win7:
See available options:
netsh interface tcp show global
Disable Command (Persistent):
netsh interface tcp set global autotuning=disabled
In response to why the Windows Server was not having any problems, I found this article - http://msdn.microsoft.com/en-us/library/ms819736.aspx
TCP window scaling is negotiated on demand in Windows Server 2003, based on the value set for the SO_RCVBUF Windows Sockets option when a connection is initiated. Additionally, the Window Scale option is used by default on a connection if the received SYN segment for that connection as initiated by a TCP peer contains the Window Scale option. Windows Server 2003 TCP does not initiate connections with window scaling by default. To instruct the Windows Server 2003 TCP stack to attempt to negotiate a larger receive window size by making use of the Window Scale option, set the Tcp1323Opts registry value to 1.
The fundamental problem you have is that QoS in the inbound direction (in to your router) to control traffic headed in your direction is relatively useless.
The congestion is occurring at the egress of the ISP device to which your Router attaches. That ISP interface has no relevant QoS applied - it is most certainly a FIFO queue. Thus if the bittorrent end points are sending you data faster than your HTTP end point, bittorrent wins in a classic FIFO queue and your HTTP download is starved.
This is a very common problem in almost every home networking setup. Bittorrent can easily starve not only SSH or RTP traffic, but VoIP traffic as well.
Use your Bittorrent software's built in rate limiting to cap up and down speeds at a rate lower than what is available.
Best Answer
Michael,
We have been Sonicwall users for a decade or so, and we have fought with this issue for that entire time. What you are trying to do is not possible with a Sonicwall. You can limit the total bandwidth to a particular protocol or port number, but not by per session. We currently have an NSA2400 with the application firewall, and it is still an aggregate limit rather than a per-session limit.
That being said, you can setup a low QOS on the HTTP protocol so that any other protocol will take precedence. This won't get anyone else's browsing to be any faster, but it won't kill email or real-time streaming (unless it's http).
One other solution, is to put certain offenders in a user group and limit them to some fraction of your total bandwidth and all the non-offenders would still have the remaining fraction left over for browsing. This would require users to login into the firewall before browsing, unless your 3060 has LDAP integration. If it does, then you could setup groups in your Active Directory and then the user won't have to login in each time...