[Bloat] Win10 Updates vs cake

Ryan Mounce ryan at mounce.com.au
Thu Dec 28 23:44:06 EST 2017


On 29 December 2017 at 04:18, Benjamin Cronce <bcronce at gmail.com> wrote:
>
>
> On Thu, Dec 21, 2017 at 8:55 PM, Ryan Mounce <ryan at 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 at 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 at lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/bloat
>> _______________________________________________
>> Bloat mailing list
>> Bloat at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>
>


More information about the Bloat mailing list