What follows is not my work; it was submitted by Richard Haselgrove [r.haselgrove@btopenworld.com] to the boinc_dev mail list. It is a change to the Windows registry that greatly improves download performance. Since I installed it, I have not had any download failures, even temporary ones. Please respond if you know something that is wrong with it.

RFC1323 (http://www.ietf.org/rfc/rfc1323.txt) provides two "TCP extensions to improve performance over large bandwidth*delay product paths": Window scaling and Timestamps.

It's recently come to light that the two big OSs handle these differently.

Linux enables them by default - http://man7.org/linux/man-pages/man7/tcp.7.html
Windows supports them, but doesn't enable them automatically - http://technet.microsoft.com/en-us/library/cc938205.aspx

This is particularly noticeable on heavily congested network links with sporadic packet drop. This is exactly the situation foreseen (back in 1992!) by the authors of RFC1323:
(2) Recovery from Losses Packet losses in an LFN can have a catastrophic effect on throughput. Until recently, properly-operating TCP implementations would cause the data pipeline to drain with every packet loss, and require a slow-start action to recover. Recently, the Fast Retransmit and Fast Recovery algorithms [Jacobson90c] have been introduced. Their combined effect is to recover from one packet loss per window, without draining the pipeline. However, more than one packet loss per window typically results in a retransmission timeout and the resulting pipeline drain and slow start.
In the BOINC environment, Linux users see a slow but steady download over a congested link: Windows users see a timeout, http error, and exponential transfer and project backoff timers quickly reaching several hours.


This has come to light at SETI, which constantly teeters on the brink of 100% network utilisation: but I'm sure other projects experience bursts of high network utilisation, for example when the application executables of a new app or version are being distributed - especially if the application requires the use of the now-large cufft.dll files for nVidia GPUs.

In the (near?) future, BOINC will be offering distributed storage facilities alongside distributed computing. Having 90% of the volunteer userbase subject to multi-hour delays on file transfers will be discouraging, to say the least.

Windows hosts can enable the use of RFC1323 optimisation for TCP by setting a single registry value: two alternative simple one-line representations are

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters]
"Tcp1323Opts"=dword:00000003


and

REG ADD "HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters" /v "Tcp1323Opts" /t REG_DWORD /d 3 /f


I'm sure that no project transaction with a BOINC client could operate at that level within the local Windows registry, without raising the most horrendous security uproar.

But - with appropriate documentation and opt-out facilities - it could be legitimately be incorporated in the Windows BOINC installer - which specifically seeks and requires user authorisation to make changes to the host system settings.

Reference: http://setiathome.berkeley.edu/forum_thread.php?id=71002

---