From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 02A653BA8E for ; Sat, 1 Dec 2018 02:37:44 -0500 (EST) Received: by mail-vs1-xe32.google.com with SMTP id r14so4711275vsc.13 for ; Fri, 30 Nov 2018 23:37:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oCCYnaNtAJFlDuJvKExKs2eyZonSK9Fyxz7L4ODVJgI=; b=lx3zSffGMI1g59ScCTpU1eFBai9EY+7DuG+KB7KJRBFK3D7Fprp1bRmjoXe3yZjMyV /CGj3iDE2tn6Q6GFQFhYzuCxbSnCFHw5C9PRscKqiMpbynGag+4F/ttl33C0VlhWy3NL 4rQciTn/p90zLPzsCgaHRV59rqAsKRkTpAQzr0MmILLvIk3CZFNios/1ajXaEOnVUBAH fDL9HbLq2FzQhM8Q2URqt1dwtO2JFAiV9UnQoEmOc/zaTgX/x/FtTNpnl5kqYfZSo04a /EtUeGSWI5ArXzoo2dSlJSLKUHuBmShjyn/kgn9P5KC6LO9uaqmS610iLucJwPWjwp4i 91gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oCCYnaNtAJFlDuJvKExKs2eyZonSK9Fyxz7L4ODVJgI=; b=JWVb9uGWIbdCmqbFX5wyrWlR/LWjnNRpNjgQ4F5XbqJSWTAlcg00kbZ5DUvy7FnJdw n3pvCSCUhRAxWECWKaaUwH5KxP6rZc2GIekTBpC+OFpQDCoZI3QgXfdDyzzdQ1bXJXeC h2zkNCkIFrJjOiKFhoc+ZYWABWR618jJvbku2IUgjHkO3kyPzv3b7z8UlbdYu1HMu9ae eNPSV5r7/Xwcgca23zGulAjXEmumHe+lsZXgdI2Yv9WspWC/6CEEp2vOPa7BLUEOKgAt 24rfCqLEnhwSfLWkjd/Mft1Wtu08GwN2CQ6MELCVUZ3+l5b4wkKcJOPWf7fVhCEIxCku ZisQ== X-Gm-Message-State: AA+aEWaFkqW7PvfXPVAppnwZIbwHo7UbUj6qXi82/n+LfJM8pH0h9fj4 vkB3KPu5fa8YTnIdYdKaHasaOqiI/DnbuVqGfVk= X-Google-Smtp-Source: AFSGD/WtkSkzpGEfMqEGyzKJJXxsWOgoDtDoqenMeal3GUqmnXSJSv/3c5yFxVkppPpCtv+Z3zXVwmtiJMohsDbv7eE= X-Received: by 2002:a67:ce95:: with SMTP id c21mr1340916vse.112.1543649864544; Fri, 30 Nov 2018 23:37:44 -0800 (PST) MIME-Version: 1.0 References: <3D0D58C0-B601-413B-B3EA-80C396E6187B@gmail.com> In-Reply-To: <3D0D58C0-B601-413B-B3EA-80C396E6187B@gmail.com> From: Azin Neishaboori Date: Sat, 1 Dec 2018 02:37:33 -0500 Message-ID: Subject: Re: monitoring queue length To: Jonathan Morton Cc: bloat-devel@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000d574c7057bf0fd1e" X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 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: Sat, 01 Dec 2018 07:37:45 -0000 --000000000000d574c7057bf0fd1e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jonathan Thank you for your response. I think did not describe my setup well in the first email. So here it goes: I have an ubuntu virtual machine on my laptop that sends/receives data from remote iperf servers. My laptop is connected by a 100Mbps Ethernet cable to a router, and the router has two cellular antennas and an LTE SIM. The router routes all the incoming and outgoing traffic to/from the VM from/to remote iperf servers using the cellular link. The cellular link is thus my bottleneck link, and I am looking for queue buildup at the router=E2=80=99s= egress interface, i.e., the cellular interface. I am looking into uplink mostly, and the uplink rate of LTE is both limited and has errors. The uplink rate I see is around 10 Mbps on a good received signal strength condition. So based on the dumbbell topology you described, I should see queue buildup at the egress cellular interface of the router, right? But when I periodically (once every second) run tc -s qdisc ls, the backlog is consistently zero. Am I looking at the wrong information? Or am I missing something even bigger? Thanks a lot Azin On Fri, Nov 30, 2018 at 10:14 PM Jonathan Morton wrote: > > On 1 Dec, 2018, at 12:05 am, Azin Neishaboori < > azin.neishaboori@gmail.com> wrote: > > > > I do not know if this backlog is indeed queue length or not. It seems > strange to be queue length, because even when I flood the network with hi= gh > UDP data rates over capacity, it still shows 0b of backlog. Am I looking = at > the wrong parameter? If so, could you please point out the tool that show= s > the instantaneous queue length? > > There are two potential points of confusion here: > > 1: Linux throttles both TCP and UDP at the application socket level to > prevent queues building up in the qdiscs and HW devices. If it's your > machine producing the packets, that's probably the effect you're seeing; > there'll be a few packets queued in the HW (invisibly) and none in the > qdisc. That's approximately true regardless of which qdisc is in use, > though with a shaping qdisc you might see a few packets collect there > instead of in the HW. > > 2: If your traffic is coming from outside, it won't be queued upon receip= t > unless you introduce an artificial bottleneck. There are ways of doing > that. > > For queuing experiments, we normally set up a "dumbbell" topology in whic= h > two different machines act as source and drain of traffic, and a third > machine in the middle acts as a network emulator with artificial delays, > losses and bandwidth limits. That middlebox is where you would then > observe the queuing. > > - Jonathan Morton > > --000000000000d574c7057bf0fd1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jonathan=C2=A0
Thank you for your response. I think did not describe= my setup well in the first email. So here it goes:

I have an ubuntu virtual machine on my laptop that sends/receives data fr= om remote iperf servers. My laptop is connected by a 100Mbps Ethernet cable= to a router, and the router has two cellular antennas and an LTE SIM. The = router routes all the incoming and outgoing traffic to/from the VM from/to = remote iperf servers using the cellular link. The cellular link is thus my = bottleneck link, and I am looking for queue buildup at the router=E2=80=99s= egress interface, i.e., the cellular interface. I am looking into uplink m= ostly, and the uplink rate of LTE is both limited and has errors. The uplin= k rate I see is around 10 Mbps on a good received signal strength condition= .=C2=A0

So based on the dumbbell topology you desc= ribed, I should see queue buildup at the egress cellular interface of the r= outer, right?
=C2=A0But when I periodically (once every second) r= un tc -s qdisc ls, the backlog is consistently zero. Am I looking at the wr= ong information? Or am I missing something even bigger?

Thanks a lot=C2=A0
Azin


On Fri, Nov 30, 2018 at 10:14 PM Jonathan Morton <= chromatix99@gmail.com> wrot= e:
> On 1 Dec, 2018, at 12:05 am= , Azin Neishaboori <azin.neishaboori@gmail.com> wrote:
>
> I do not know if this backlog is indeed queue length or not. It seems = strange to be queue length, because even when I flood the network with high= UDP data rates over capacity, it still shows 0b of backlog. Am I looking a= t the wrong parameter? If so, could you please point out the tool that show= s the instantaneous queue length?

There are two potential points of confusion here:

1: Linux throttles both TCP and UDP at the application socket level to prev= ent queues building up in the qdiscs and HW devices.=C2=A0 If it's your= machine producing the packets, that's probably the effect you're s= eeing; there'll be a few packets queued in the HW (invisibly) and none = in the qdisc.=C2=A0 That's approximately true regardless of which qdisc= is in use, though with a shaping qdisc you might see a few packets collect= there instead of in the HW.

2: If your traffic is coming from outside, it won't be queued upon rece= ipt unless you introduce an artificial bottleneck.=C2=A0 There are ways of = doing that.

For queuing experiments, we normally set up a "dumbbell" topology= in which two different machines act as source and drain of traffic, and a = third machine in the middle acts as a network emulator with artificial dela= ys, losses and bandwidth limits.=C2=A0 That middlebox is where you would th= en observe the queuing.

=C2=A0- Jonathan Morton

--000000000000d574c7057bf0fd1e--