From: "Jonas Mårtensson" <martensson.jonas@gmail.com>
To: bloat <bloat@lists.bufferbloat.net>
Subject: [Bloat] powerboost and sqm
Date: Fri, 29 Jun 2018 12:56:17 +0200 [thread overview]
Message-ID: <CAM9iV=Ldp2YsTHDeF60jn1bP_yCAbbx7FEiVpxHBSNFcEDj=jQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]
Hi,
I have a 100/100 Mbit/s (advertised speed) connection over fiber (p2p, not
PON). The actual link rate is 1 Gbit/s. My ISP seems to be using
burst-tolerant shaping (similar to powerboost) as can be seen in this
speedtest where the download rate is 300+ Mbit/s and the upload rate is
around 150 Mbit/s for the first few seconds:
http://www.dslreports.com/speedtest/35205027
It can be discussed why they are doing this but my questions are more
related to the impact on the quality of my connection. The ISPs shaper used
to introduce some bufferbloat, especially on the downlink, and I've been
using sqm for a while to mitigate this. But recently they seem to have
changed some configuration since the bufferbloat is now almost zero, except
for some very short spikes which only show up when I check "Hi-Res
BufferBloat" in test preferences (see speedtest above). When I enable sqm
on my router with htb/fq_codel or cake the spikes disappear:
htb/fq_codel:
http://www.dslreports.com/speedtest/35205620
cake:
http://www.dslreports.com/speedtest/35205718
Another difference is that the "Re-xmit" percentage (which I guess is
related to packet loss) is much higher without sqm enabled. Intuitively
this makes sense since temporarily allowing a higher rate should result in
more buffer overflow when the rate is decreased.
So, what do you think:
- Are the latency spikes real? The fact that they disappear with sqm
suggests so but what could cause such short spikes? Is it related to the
powerboost?
- Would you enable sqm on this connection? By doing so I miss out on the
higher rate for the first few seconds. What are the actual downsides of not
enabling sqm in this case?
/Jonas
[-- Attachment #2: Type: text/html, Size: 2185 bytes --]
next reply other threads:[~2018-06-29 10:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-29 10:56 Jonas Mårtensson [this message]
2018-06-29 11:23 ` Sebastian Moeller
2018-06-30 6:26 ` Jonas Mårtensson
2018-06-30 7:20 ` Jonathan Morton
2018-06-30 7:46 ` Pete Heist
2018-06-30 11:22 ` Dave Taht
2018-07-01 21:49 ` Jonas Mårtensson
2018-07-04 20:25 ` Benjamin Cronce
2018-06-29 12:22 ` Jonathan Morton
2018-06-29 14:00 ` Dave Taht
2018-06-29 14:42 ` Sebastian Moeller
2018-06-29 15:45 ` Jonas Mårtensson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAM9iV=Ldp2YsTHDeF60jn1bP_yCAbbx7FEiVpxHBSNFcEDj=jQ@mail.gmail.com' \
--to=martensson.jonas@gmail.com \
--cc=bloat@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox