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.
