From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-12-iad.dyndns.com (mxout-107-iad.mailhop.org [216.146.32.107]) by lists.bufferbloat.net (Postfix) with ESMTP id DB0892E0297 for ; Sat, 12 Mar 2011 13:57:28 -0800 (PST) Received: from scan-12-iad.mailhop.org (scan-12-iad.local [10.150.0.209]) by mail-12-iad.dyndns.com (Postfix) with ESMTP id 93E4F3732CF for ; Sat, 12 Mar 2011 21:57:26 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 209.85.215.171 Received: from mail-ey0-f171.google.com (mail-ey0-f171.google.com [209.85.215.171]) by mail-12-iad.dyndns.com (Postfix) with ESMTP id 821CC3705AE for ; Sat, 12 Mar 2011 21:57:25 +0000 (UTC) Received: by eydd26 with SMTP id d26so1467148eyd.16 for ; Sat, 12 Mar 2011 13:57:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=qUe0YSLkDqeehDE/Xgpbzd+dQ8reI1DZDakL3sgfCj0=; b=jrqXnDlF1WJT7iywpEbAU7092B2KTjor8fvmquB5INi4KCLYCkb2SLUtjIXiuVt9kK n7d/PafJavSSUmgyN5kQtkZ02pbs5+W3TYgBTVduGqnHPVuVxp6TmCw6cjCqPTKQYMHZ Qgffr9eOnAzBWiFNRP1HgMeQdC/37bD/rvT8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=r4yS+kyy8yGrvE+RnszzxNHppWew8EYks/o0VTMI8teEhVeJeYXk/2+8zjL4STIF71 pzzsAgVUkwzSAd3eROnegl08Qj8lEcj/fVzaJC+qIJCwpaTGU/VgG93kZf/N+P1OX7dz 4i2Q+LhFGF7ujHM2X7waEvTC8BtVTrNIvR+gE= Received: by 10.213.23.91 with SMTP id q27mr528624ebb.68.1299967044701; Sat, 12 Mar 2011 13:57:24 -0800 (PST) Received: from [192.168.239.42] (xdsl-83-150-84-172.nebulazone.fi [83.150.84.172]) by mx.google.com with ESMTPS id x54sm4613355eeh.23.2011.03.12.13.57.23 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2011 13:57:24 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: <1299902651.31981.7.camel@amd.pacdat.net> Date: Sat, 12 Mar 2011 23:57:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <462034BF-919D-4AE4-BA58-EA98C95D870F@gmail.com> References: <16808EAB-2F52-4D32-8A8C-2AE09CD4D103@gmail.com> <1299899959.1835.10.camel@amd.pacdat.net> <10491D5A-AA1B-4F41-99A9-15A0C06ADF25@gmail.com> <1299902651.31981.7.camel@amd.pacdat.net> To: richard X-Mailer: Apple Mail (2.1082) Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Measuring latency-under-load consistently X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 21:57:29 -0000 On 12 Mar, 2011, at 6:04 am, richard wrote: > OK - you make a good case for a new measure as my understanding of > jitter is latency related and typically measured at the link level = (udp) > rather than at the application level. >=20 > I infer then that this will do things like impact the CPU load and = disk > load, and might for example introduce "ringing" or harmonics into such > sub systems if/when applications end up "in sync" due to being "less > smooth" in their data output to the lower level IP levels. I'm not sure how significant those effects would be, compared to simple = data starvation at the client. Most Web servers operate with all the = frequently-accessed data in RAM (via disk cache) and serve many clients = at once or in quick succession, whose network paths don't have the same = bottlenecks in general. It was my understanding that UDP-bsed protocols tended to tolerate = packet loss through redundancy and graceful degradation rather than = retransmission, though there are always exceptions to the rule. So a = video streaming server would be transmitting smoothly, with the client = giving feedback on how much data had been received and how much packet = loss it was experiencing. Even if that status information is = considerably delayed, I don't see why load spikes at the server should = occur. A fileserver, on the other hand, would not care very much. Even if the = TCP window has grown to a megabyte, it takes longer to seek disk heads = than to read that much off the platter, so these lumps would be absorbed = by the normal readahead and elevator algorithms anyway. However, large = TCP windows do consume RAM in both server and client, and with a = sufficient number of simultaneous clients, that could theoretically = cause trouble. Constraining TCP windows to near the actual BDP is more = efficient all around. > It will be affected by session drops due to timeouts as well as the = need > to "fill the pipe" on a reconnect in such applications as streaming > video (my area) so that a key frame can come into the system and = restart > the interrupted video play. In the event of a TCP session drop, I think I will consider it a test = failure and give zero scores across the board. Sufficient delay or = packet loss to cause that indicates a pretty badly broken network. With that said, I can think of a case where it is likely to happen. = Remember that I was seeing 30 seconds of buffering on a 500kbps 3G = link... now what happens if the link drops to GPRS speeds? There would = be over a megabyte of data queued up behind a 50Kbps link (at best). No = wonder stuff basically didn't work when that happened. - Jonathan