From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A80CD3B2A4 for ; Sat, 18 Nov 2017 08:18:30 -0500 (EST) Received: by mail-wm0-x22e.google.com with SMTP id r68so11189903wmr.3 for ; Sat, 18 Nov 2017 05:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=aYVa8E2VOeS+rkpxfu/Il/ZCTTF5FwRUgUCsOlT7Fo0=; b=GUSuYB1OyCVwpydTWNlbojL83WALqzu4/Akhd1bLpq+U8aPKnM0cEmN07ME4XhNhJt zKrDXFUAkdqsZhtJod171/O1NLPndwRcR1WusMCOgZXjaJlMZRhTLxHfZ3rv3Ajd5Kyt VzkqJRuVtAZSQ21QDPWL+q0z3wyR0fMKKeKkin8Qzcu48r1RCWJN5RmQD5IYfQCoxenZ rjn90ToA/ZRG710EfamNU86Yd4JZT9SmSlL5Y+q/XwRR2nWpt9Fw7+eVja8AczZrW+G4 k4PlqSP5WdR+XYnfNYBT0fZm0pZzE4WpK7MLTxE9RQQEaW9tkuyLUsr5PKy7cn+yE+5M pm8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=aYVa8E2VOeS+rkpxfu/Il/ZCTTF5FwRUgUCsOlT7Fo0=; b=n8hoyyCtQqd+uV8XLZMNx9/jrL0DcaFwxXfXsiZImjOrTg8ntm/a08hwLJbnnKN1Ai tlwX6ylFQUzX4SPbkdeF4BEMR1A675zdifl37C5EZDK6vNl+eRxKiNV/EddXRqimWeIa E3gEdHJjuBl6rmAN0rBd/qWELtoVyUxTLAee2IE48qxWWtUKdhPQRhtfIRzU2JYZNoxT nydSB/h5ObPbVXRbo3xOTnIOIgjN2ARKJE7keSE8T5UOgxsCCMhd1LYqKh+Bo8G/lX4x auCwHKwl4KP+rJWfRwoALy5b882EblRq4s2aFf2jDMnmquAWrVe8Xa4jkh8Pb3RV+C+n KsQQ== X-Gm-Message-State: AJaThX6xyI17w0nSJ8mYhiVT9mmlEbVtLaG4RIEgG/Rnr3TaOQrX8FZ/ InDvUpytmEAwQmEnKGe9o00= X-Google-Smtp-Source: AGs4zMb27b/jJ9hxKZMosgJjEO9bhJlewlLq4Cto9VzHrHCzSI/HODWDkk9LPjzv5b0MZ11fVAtKYA== X-Received: by 10.28.56.5 with SMTP id f5mr6457283wma.159.1511011109704; Sat, 18 Nov 2017 05:18:29 -0800 (PST) Received: from [10.72.0.130] (h-1169.lbcfree.net. [185.99.119.68]) by smtp.gmail.com with ESMTPSA id u33sm4122251wrf.42.2017.11.18.05.18.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 18 Nov 2017 05:18:29 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_89BA3720-1928-48A5-8F32-DE4E39CC3AF5" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pete Heist In-Reply-To: Date: Sat, 18 Nov 2017 14:18:28 +0100 Cc: cake@lists.bufferbloat.net Message-Id: References: To: Dave Taht X-Mailer: Apple Mail (2.3124) Subject: Re: [Cake] [RFC PATCH 4/5] q_netem: support delivering packets in delayed time slots X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2017 13:18:30 -0000 --Apple-Mail=_89BA3720-1928-48A5-8F32-DE4E39CC3AF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 17, 2017, at 11:55 PM,dave.taht@gmail.com wrote: >=20 > Slotting is a crude approximation of the behaviors of shared media = such > as cable, wifi, and LTE, which gather up a bunch of packets within a > varying delay window and deliver them, relative to that, nearly all at > once. Nice=E2=80=A6 One of the things I also notice in my LAN tests is latencies for = different flows staying at more or less fixed (and different) positions = relative to the mean in flent results. Those positions, and the mean, = can change with each test run. Do you think this could result from the = hashing to different hardware queues (four in my case) changing between = test runs? And is it worth trying to simulate this effect, or not = really? Just for info, in my case (Intel i210) the hashing is documented = starting on page 254 of the specs: = https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/i2= 10-ethernet-controller-datasheet.pdf = (7.1.2.10.1 RSS Hash Function). = For TCP/UDP it uses source and destination addresses and ports. I = suppose this could be smoothed over in testing by using a spread of = ports for the latency test.= --Apple-Mail=_89BA3720-1928-48A5-8F32-DE4E39CC3AF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 17, 2017, at 11:55 PM,dave.taht@gmail.com = wrote:

Slotting is a crude = approximation of the behaviors of shared media such
as = cable, wifi, and LTE, which gather up a bunch of packets within a
varying delay window and deliver them, relative to that, = nearly all at
once.

Nice=E2=80=A6

One of the things I also notice in my LAN tests is = latencies for different flows staying at more or less fixed (and = different) positions relative to the mean in flent results. Those = positions, and the mean, can change with each test run. Do you think = this could result from the hashing to different hardware queues (four in = my case) changing between test runs? And is it worth trying to simulate = this effect, or not really?

Just for = info, in my case (Intel i210) the hashing is documented starting on page = 254 of the specs: https://www.intel.com/content/dam/www/public/us/en/documents/da= tasheets/i210-ethernet-controller-datasheet.pdf (7.1.2.10.1 RSS = Hash Function). For TCP/UDP it uses source and destination addresses and = ports. I suppose this could be smoothed over in testing by using a = spread of ports for the latency test.
= --Apple-Mail=_89BA3720-1928-48A5-8F32-DE4E39CC3AF5--