Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755913AbZJ2QyO (ORCPT ); Thu, 29 Oct 2009 12:54:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755855AbZJ2QyN (ORCPT ); Thu, 29 Oct 2009 12:54:13 -0400 Received: from mail-out2.uio.no ([129.240.10.58]:45849 "EHLO mail-out2.uio.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755856AbZJ2QyL (ORCPT ); Thu, 29 Oct 2009 12:54:11 -0400 Message-ID: Date: Thu, 29 Oct 2009 17:54:15 +0100 Subject: Re: [PATCH 2/3] net: TCP thin linear timeouts From: apetlund@simula.no To: "Arnd Hannemann" Cc: "Andreas Petlund" , "Eric Dumazet" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "shemminger@vyatta.com" , "ilpo.jarvinen@helsinki.fi" , "davem@davemloft.net" User-Agent: SquirrelMail/1.4.19 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 2 sum rcpts/h 28 sum msgs/h 4 total rcpts 441 max rcpts/h 37 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: CAA65BCFD2B7CEA7A68578F0C3FA146E8F31577B X-UiO-SPAM-Test: remote_host: 129.240.4.214 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 261 total 1920329 max/h 678 blacklist 0 greylist 0 ratelimit 0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2609 Lines: 57 > Andreas Petlund schrieb: >> We have found no noticeable degradation of the goodput in a series of experiments we have performed in order to map the effects of the modifications. Furthermore, the modifications implemented in the patches >> are explicitly enabled only for applications where the developer knows that streams will be thin, thus only a small subset of the streams will apply the modifications. >> Graphs presenting results from experiments performed to analyse latency and fairness issues can be found here: >> http://folk.uio.no/apetlund/lktmp/ > > How often did you hit consecutive RTOs in these measurements? > As I see you did a measurement with 512 thick vs. 512 thin streams. Lets do a hypothetical calculation with only 512 "thin" streams. Lets further assume the rtt is low, so that RTO is around 200ms. Assume each segment has 128 Bytes (already very small...). > Assume after a period of normal operation all streams are in > timeout-based loss recovery. (e.g. because destination endpoint > suddenly behaves like a black hole) > As all streams are in timeout-based loss recovery, each stream > will transmit 5 segments each second with your modification. > This would result in a throughput around 512*5*1024bit = 2560 kbit/s and a goodput of 0 kbit/s (because the receiver is a black hole). So you can easily saturate a 2 MBit/s link, only with retransmissions. I have not yet performed experiments where the receiver becomes a black hole, but I recognise the problem. Eric Dumazet suggested that the mechanism switch to exponential backoff after 6 linear retries. This would avoid situation where the link stays congested indefinitely, and I will implement this in the next iteration. > Unfortunately in Germany an ADSL uplink of 786 kbit/s is still quite common, and its already called "broadband"... I believe that a subscriber for such an uplink would not keep several hundred thin-stream connections, though accidents do happen. > Regarding the "small subset", why have a global sysctl option, then? And I think "tcp_stream_is_thin(tp)" will be true for every flow in the RTO case, at least for consecutive RTOs. The sysctl is ment for cases of proprietary code that will benefit from the modifications. In our experiments, we have found it useful in many cases for such applications (like game clients). Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/