From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.hp.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 54F5821F1D7 for ; Mon, 2 Dec 2013 10:11:59 -0800 (PST) Received: from g2t2360.austin.hp.com (txe01lbes9037-9038-vl451-snat0.austin.hp.com [15.216.28.90]) by g1t0029.austin.hp.com (Postfix) with ESMTP id B4B5C3804D; Mon, 2 Dec 2013 18:11:57 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g2t2360.austin.hp.com (Postfix) with ESMTP id 2B15446; Mon, 2 Dec 2013 18:11:55 +0000 (UTC) Message-ID: <529CCD6B.8000805@hp.com> Date: Mon, 02 Dec 2013 10:11:55 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= , "Eggert\, Lars" Subject: Re: One-way delay measurement for netperf-wrapper References: <87zjoojr5u.fsf@toke.dk> <87mwknk0hw.fsf@toke.dk> In-Reply-To: <87mwknk0hw.fsf@toke.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "bloat-devel@lists.bufferbloat.net" X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 18:11:59 -0000 On 11/29/2013 01:42 AM, Toke Høiland-Jørgensen wrote: > Well, what the LINCS people have done (the link in my previous mail) is > basically this: Sniff TCP packets that have timestamps on them (i.e. > with the TCP timestamp option enabled), and compute the delta between > the timestamps as a latency measure. Now this only gives an absolute > latency measure if the clocks are synchronised; however, if we're > interested in measuring queueing latency, i.e. induced *extra* latency, > this can be calculated as (latency - min-latency) where min-latency is > the minimum observed latency throughout the lifetime of the connection > (this is the same mechanism LEDBAT uses, btw). Those TCP timestamps are generated (iirc) when TCP transmits the data, not when the application presents the data to TCP. Not a deal breaker necessarily, but something to keep in mind. rick jones