From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "alln-iport.cisco.com", Issuer "HydrantID SSL ICA G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6F9CF21F3F2; Fri, 15 May 2015 06:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2693; q=dns/txt; s=iport; t=1431695429; x=1432905029; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OFIroiD1sTwsbM3k96VTAXR1w5NV9kDEG6J4YFdut2U=; b=G3zqC90m1PnnXSZw8zWbm/Tr5HytVTaczgEHnY+LIEofqSJYoXmm4Q/p X+FIFhUaeKsR7NKiOB1lipnXwqdxA507nG03IFcE1N6rL9sEtJwcTXTzc ytWdhPoSQ+vw8z7hE4VjwVDA5ciHUe9JELECSGAnzvWtYla2cqFDDgTBb 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BUBAD271VV/4gNJK1SCoMPgTIGxF8JgU+GAAKBOTgUAQEBAQEBAYEKhCIBAQEDAQECNz8FBwQCAQgRBAEBAQoUCQchBwoUCQgCBA4FCIgPAwoI0W4NhQMBAQEBAQEBAQEBAQEBAQEBAQEBAQEXizqCTYFbEhoxBwaDEYEWBZJhiEBekV2GdyODeG+BRYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,433,1427760000"; d="scan'208";a="150333123" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 15 May 2015 13:09:59 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t4FD9x6l009742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 May 2015 13:09:59 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.121]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Fri, 15 May 2015 08:09:59 -0500 From: "Bill Ver Steeg (versteb)" To: "Eggert, Lars" Thread-Topic: [Bloat] [Cerowrt-devel] heisenbug: dslreports 16 flow test vs cablemodems Thread-Index: AQHQjui69c9aWQ5xNU2UnOoKMUD60p185OHggABqy4D//7M0sA== Date: Fri, 15 May 2015 13:09:58 +0000 Message-ID: References: <8C015B1B-EFBA-4647-AD83-BAFDD16A4AF2@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.227.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cake@lists.bufferbloat.net" , "Klatsky, Carl" , "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Cerowrt-devel] [Bloat] heisenbug: dslreports 16 flow test vs cablemodems X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 13:10:30 -0000 Lars- You make some good points. It boils down to the fact that there are several= things that you can measure, and they mean different things. Bvs -----Original Message----- From: Eggert, Lars [mailto:lars@netapp.com]=20 Sent: Friday, May 15, 2015 8:44 AM To: Bill Ver Steeg (versteb) Cc: Aaron Wood; cake@lists.bufferbloat.net; Klatsky, Carl; cerowrt-devel@li= sts.bufferbloat.net; bloat Subject: Re: [Bloat] [Cerowrt-devel] heisenbug: dslreports 16 flow test vs = cablemodems Hi, On 2015-5-15, at 13:27, Bill Ver Steeg (versteb) wrote: > But the TCP timestamps are impacted by packet loss. You will sometimes ge= t an accurate RTT reading, and you will sometimes get multiples of the RTT = due to packet loss and retransmissions. right. But those will be transient, and so you can identify them against th= e baseline. > You really need to use a packet oriented protocol (ICMP/UDP) to get a tru= e measure of RTT at the application layer. I disagree. You can use them to establish a lower bound on the delay an app= lication over TCP will see, but not get an accurate estimate of that (becau= se socket buffers are not included in the measurement.) And you rely on the= network to not prioritize ICMP/UDP but otherwise leave it in the same queu= es. > If you can instrument TCP in the kernel to make instantaneous RTT availab= le to the application, that might work. I am not sure how you would roll th= at out in a timely manner, though. That's already part of the TCP info struct, I think. At least in Linux. Lars > I think I actually wrote some code to do this on BSD many years ago, and = it gave pretty good results. I was building a terminal server (remember tho= se?) and needed to have ~50ms +- 20ms echo times. >=20 >=20 > Bvs >=20 > From: bloat-bounces@lists.bufferbloat.net [mailto:bloat-bounces@lists.buf= ferbloat.net] On Behalf Of Eggert, Lars > Sent: Friday, May 15, 2015 4:18 AM > To: Aaron Wood > Cc: cake@lists.bufferbloat.net; Klatsky, Carl; cerowrt-devel@lists.buffer= bloat.net; bloat > Subject: Re: [Bloat] [Cerowrt-devel] heisenbug: dslreports 16 flow test v= s cablemodems >=20 > On 2015-5-15, at 06:44, Aaron Wood wrote: > ICMP prioritization over TCP? >=20 > Probably. >=20 > Ping in parallel to TCP is a hacky way to measure latencies; not only bec= ause of prioritization, but also because you don't measure TCP send/receive= buffer latencies (and they can be large, auto-tuning is not so great.) >=20 > You really need to embed timestamps in the TCP bytestream and echo them b= ack. See the recent netperf patch I sent. >=20 > Lars