This works. The 8MB task downloads from seti and setibeta were constantly backing off on my win7 machine. Since adding the first registry key about four days ago, not one has backed off.
-----Original Message----- From: Richard Haselgrove <[email protected]> To: BOINC Dev MailingList <[email protected]> Sent: Fri, Mar 8, 2013 6:22 pm Subject: [boinc_dev] RFC 1323: Different network defaults between *nix and Windows 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 Comments? _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
