General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Ryan Mounce <ryan@mounce.com.au>
To: Benjamin Cronce <bcronce@gmail.com>
Cc: Rich Brown <richb.hanover@gmail.com>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Win10 Updates vs cake
Date: Fri, 29 Dec 2017 15:14:06 +1030	[thread overview]
Message-ID: <CAN+fvRY9BA=q0mc7sfH50WshPnzpGOXtS8TCD4SyBoWotDdG-Q@mail.gmail.com> (raw)
In-Reply-To: <CAJ_ENFERD2+9k7_bO+wV7FWmgECNO0DHhye+O9JMbSmX=Q3dQg@mail.gmail.com>

On 29 December 2017 at 04:18, Benjamin Cronce <bcronce@gmail.com> wrote:
>
>
> On Thu, Dec 21, 2017 at 8:55 PM, Ryan Mounce <ryan@mounce.com.au> wrote:
>>
>> I've experienced this recently myself. In my case I have a 100Mbps
>> link from my ISP and their shaper will queue up to about 120ms worth
>> of packets (on top of the ~10ms baseline latency). I run cake in
>> ingress mode at 99.2Mbps, which has normally been enough to keep
>> everything in check and keep my ISP's queue empty at least in the
>> steady state.
>>
>> Boot up a Windows 10 PC that's been unused for a few months, let it
>> update and bam! 100-130ms RTT, family member's Netflix stream in the
>> next room stalls completely, and running a quick speedtest on a
>> different machine (that should get ~50% share of the link under normal
>> circumstances with dual-dsthost) yields about 1.2Mbps on a 100Mbps
>> link! I performed a quick pcap while this was happening and determined
>> that Windows Update had started on the order of 120 parallel HTTP
>> downloads from 2 different Akamai cache IPs (within my ISP's network
>> 20ms away).
>>
>> The 20ms jump in latency in your case just indicates that there is a
>> small buffer in your DSLAM, however it is still being flooded by the
>> parallel transfers from the CDN.
>>
>> Windows 10 probably deserves most of the blame for opening so many
>> parallel connections, however I think there is also some concern here
>> with Akamai's FastTCP not responding to congestion signals.
>
>
> Without packet pacing, this is impossible. All TCP implementations have a
> minimum window size of 2 segments. Assuming 1500 bytes per segment, that's
> 3,000 bytes. Divide by RTT of 20ms for 1.2Mb/s minimum bandwidth. Because
> there is no pacing, aka delaying packets, the packets are sent as soon as
> the ACK hits. With 120 connections, that's 144Mb/s. It can't respond to
> congestion by slowing itself down because it's already as slow as it can go.
> Packet pacing is very new and is slowly being standardized. Windows just
> needs to reduce the number of connections.


This can't be the reason, under this extreme load the queue of my
ISP's downstream shaper is permanently full and inducing at least an
additional 100ms of latency. Assuming an RTT to Akamai of 100ms this
gives a minimum bandwidth of 0.24Mbps, or 28.8Mbps for 120
connections. That is less than 1/3 of my link capacity.

Regards,
Ryan Mounce

>
>>
>> Regards,
>> Ryan Mounce
>>
>>
>> On 22 December 2017 at 12:31, Rich Brown <richb.hanover@gmail.com> wrote:
>> > I'm using LEDE 17.01.4 on my Archer C7v2. I have a 7mbps/768kbps ADSL2+
>> > connection through Fairpoint. The modem stats page shows its "attainable
>> > rates" (kbps): 13330/1272 and Rates: 8271/1181. My SQM settings are:
>> >
>> > Download: 7000 (kbps)
>> > Upload: 925
>> > Queue Disc: Cake/piece_of_cake.qos
>> > Link Layer: ATM/44 bytes overhead
>> > Advanced Options: default
>> >
>> > I have noticed that Win10 updates cause the network connection to become
>> > unusable for other services/people, as if I had bufferbloat. But ping times
>> > remain stable - they jump from ~20-22 msec unloaded to 40-50 msec.
>> >
>> > Experiments I have tried:
>> >
>> > - Setting download speed to 5000 makes the connection usable for other
>> > people, although the ping times remain about the same (40-50 msec)
>> >
>> > - Setting the download speed to 8600 still keeps ping times down, but
>> > that really harms other people's performance.
>> >
>> > - The link rates (download and upload) seem to track the SQM setting,
>> > measured with both YAMon and the built-in real-time graphs.  I get ~6,000
>> > kbps with a 7000 download setting, I got ~3,000kbps at the 5000 setting. I
>> > get ~8500 kbps after setting download to 8600.
>> >
>> > - This doesn't seem to happen when I'm downloading other kinds of files
>> > (I haven't tried torrenting files...) Downloading non-Win10 update files
>> > seems to leave the connection in a fairly responsive state.
>> >
>> > Any thoughts? What other experiments should I make? Thanks!
>> >
>> > Rich
>> > _______________________________________________
>> > Bloat mailing list
>> > Bloat@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/bloat
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>
>

  reply	other threads:[~2017-12-29  4:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-22  2:01 Rich Brown
2017-12-22  2:55 ` Ryan Mounce
2017-12-22  3:57   ` Ryan Mounce
2017-12-22  4:03     ` Jonathan Morton
2017-12-22  5:26     ` Jonathan Morton
2017-12-29  4:49       ` Ryan Mounce
2017-12-22  9:17     ` Kevin Darbyshire-Bryant
2017-12-22 13:07       ` Rich Brown
2017-12-28 17:48   ` Benjamin Cronce
2017-12-29  4:44     ` Ryan Mounce [this message]
2017-12-22  9:12 ` Mario Hock
     [not found] <mailman.56.1513933967.3659.bloat@lists.bufferbloat.net>
2017-12-22 13:13 ` Rich Brown

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='CAN+fvRY9BA=q0mc7sfH50WshPnzpGOXtS8TCD4SyBoWotDdG-Q@mail.gmail.com' \
    --to=ryan@mounce.com.au \
    --cc=bcronce@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=richb.hanover@gmail.com \
    /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