monitoring queue length

[Azin Neishaboori]

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 <chromatix99 at gmail.com>
wrote:

> > On 1 Dec, 2018, at 9:37 am, Azin Neishaboori <azin.neishaboori at gmail.com>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat-devel/attachments/20181201/bfe0948e/attachment-0001.html>