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 97FDF3BA8E for ; Sat, 1 Dec 2018 03:05:02 -0500 (EST) Received: by mail-vs1-xe32.google.com with SMTP id z3so4752111vsf.7 for ; Sat, 01 Dec 2018 00:05:02 -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=Lb88rVzFy7c6GhUn85Ady0iPAU58O8kGr4qGE+0vDAQ=; b=Q7cqVV7eJqW9z6M20gG6kgwmsO1c3WwRPvBKmuv63kqtSlFwR485xI/+eI06ecY6uR zqucw/i7MrOE/SIw4csklQWS63jgPz1snkrsphyGMEoCE/R1krwAClQjXZt3AjUOFsYL wgzfd7zTtXOG+6cAtPSnQhqdn3UArz/Cr/D2073P83UpW4S1ODgKk5HnXDCvMd8yIkZL bTfO79rF6OK6YQvuUoMX1HVfF03OH6DQJ3fEWt8LnKjbWitl9VAXo9XZ2lilPMViaJHe pRxJXEwuWg2asu1P4xG5elmVYt81ocClSxB25ncBLb3Uj2YwoWXN9yFFO5akBrvG6CDu G2qg== 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=Lb88rVzFy7c6GhUn85Ady0iPAU58O8kGr4qGE+0vDAQ=; b=CgcnmqdvaF+rM03XGfeZVPmQrI4/EPdbuhOYLpo0fFXrqgNs9FNqrjkJW1agg7UHBu gQC1P70W9mkpwZVdCA0Xy1pg1lftLTi6c9WxS5KnMkyAUWKex7ApeCUuzJ7jJ1S7Vs5a i/oXSR2kd3AfrW/Xq+sMmPGHXqt8nWJIofsjJtDvz8TLWj/uS0aze1oOFoSPbinSGgK5 qmfYpef7oRkk1vETCiorxVWRy6HthBzOZjjxZlpy15iOWN4si3V/fsscbEWzbLyRjkfd gh3OU5IzcKY2DZuf6M5bHOQRIKMoLPbhRpZdyQ6aopJH+k1OIf2GdDvMh47F+FjudddJ KrYg== X-Gm-Message-State: AA+aEWYU8qW5z8JBy0jBcwTzFZ0xnOfAx2aWZQ52uhckrKL/OweAndis EkZADpTIRy3gAcQLfX/E2uUUAe86g9m8u9chhWQ= X-Google-Smtp-Source: AFSGD/V2k8myWxphatVR0ANIlRp195qRf41kWILANQt37wxIuh7moS8vaLXxE0WQaAHb4FNzDv/Dqwc/22qlVhSkxiA= X-Received: by 2002:a67:8291:: with SMTP id e139mr3936188vsd.3.1543651502228; Sat, 01 Dec 2018 00:05:02 -0800 (PST) MIME-Version: 1.0 References: <3D0D58C0-B601-413B-B3EA-80C396E6187B@gmail.com> <7ACB9F40-A42B-4807-85EF-10500F11E437@gmail.com> In-Reply-To: <7ACB9F40-A42B-4807-85EF-10500F11E437@gmail.com> From: Azin Neishaboori Date: Sat, 1 Dec 2018 03:04:51 -0500 Message-ID: Subject: Re: monitoring queue length To: Jonathan Morton Cc: bloat-devel@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000728b94057bf15f17" 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 08:05:02 -0000 --000000000000728b94057bf15f17 Content-Type: text/plain; charset="UTF-8" Hi Jonathan Thank you for your very helpful insight. I can see the effect of bufferbloat in increased RTT, but when trying to further support the data with the queue size, I encountered the zero-backlog data which was very confusing to me. So now I know :) Thanks a lot for taking time, reading my message and providing helpful insight. Best Azin On Sat, Dec 1, 2018 at 2:47 AM Jonathan Morton wrote: > > On 1 Dec, 2018, at 9:37 am, Azin Neishaboori > wrote: > > > > So based on the dumbbell topology you described, I should see queue > buildup at the egress cellular interface of the router, right? > > Yes - but the actual cellular interface is on the far side of a > translation device, and so its queue is hidden from Linux. That's > unfortunately true of *every* 3G or LTE interface I've yet seen. Older > devices have a virtual serial PPP interface to the translator, newer ones > pretend to be Ethernet devices on the near side of the translator - in both > cases with much more bandwidth than the cellular interface itself. > > This is actually quite a serious problem for people trying to improve the > quality of cellular Internet connections. All of the low-level stuff that > would be useful to experiment with is deliberately and thoroughly hidden. > > If you put in an artificial bottleneck of 10Mbps on the outgoing > interface, you should be able to develop a queue there. You can use HTB or > HFSC, with the qdisc of your choice as a child on which the actual queuing > occurs. > > A better way to measure the impact of queuing in the raw device is to > observe the increase of latency when the link is loaded versus when it is > idle. I recommend using the Flent tool for that. > > - Jonathan Morton > > --000000000000728b94057bf15f17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jonathan=C2=A0

Thank you for your very helpful insigh= t.=C2=A0

I can see the effect of bufferbloat in in= creased RTT, but when trying to further support the data with the queue siz= e, I encountered the zero-backlog data which was very confusing to me. So n= ow I know :)

Thanks a lot for taking time, reading= my message and providing helpful insight.

Best
Azin



On Sat, Dec 1, 2018 at 2:47 AM Jonathan Morton <chromatix99@gmail.com> wrote:
> On 1 Dec, 2018, at 9:37 am, Azin= Neishaboori <azin.neishaboori@gmail.com> wrote:
>
> So based on the dumbbell topology you described, I should see queue bu= ildup at the egress cellular interface of the router, right?

Yes - but the actual cellular interface is on the far side of a translation= device, and so its queue is hidden from Linux.=C2=A0 That's unfortunat= ely true of *every* 3G or LTE interface I've yet seen.=C2=A0 Older devi= ces have a virtual serial PPP interface to the translator, newer ones prete= nd to be Ethernet devices on the near side of the translator - in both case= s with much more bandwidth than the cellular interface itself.

This is actually quite a serious problem for people trying to improve the q= uality of cellular Internet connections.=C2=A0 All of the low-level stuff t= hat would be useful to experiment with is deliberately and thoroughly hidde= n.

If you put in an artificial bottleneck of 10Mbps on the outgoing interface,= you should be able to develop a queue there.=C2=A0 You can use HTB or HFSC= , with the qdisc of your choice as a child on which the actual queuing occu= rs.

A better way to measure the impact of queuing in the raw device is to obser= ve the increase of latency when the link is loaded versus when it is idle.= =C2=A0 I recommend using the Flent tool for that.

=C2=A0- Jonathan Morton

--000000000000728b94057bf15f17--