From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CF28E3B25D for ; Sat, 16 Jul 2016 09:37:29 -0400 (EDT) Received: from [10.24.230.221] ([80.187.96.17]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LlleO-1apM0r3UPI-00ZO1t; Sat, 16 Jul 2016 15:37:26 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <578A2030.5050409@darbyshire-bryant.me.uk> References: <5789FFEF.9010408@darbyshire-bryant.me.uk> <578A2030.5050409@darbyshire-bryant.me.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----W2XM6C134GSD2SDQ4TC8TL9QZXV58B" Content-Transfer-Encoding: 7bit From: Sebastian Moeller Date: Sat, 16 Jul 2016 15:37:22 +0200 To: Kevin Darbyshire-Bryant , cake@lists.bufferbloat.net Message-ID: <2213BDE7-17D2-4228-ACF4-51B341B926DF@gmx.de> X-Provags-ID: V03:K0:rSs8+KixpaLQf0RgCg9kIKRgYP7cZlQBPNwRsoHaeB2dfgLnNb4 y1OaQCw9onw5wnsTIhF6bhFX3Nhdl6ZntQ+97SqBzIjEHuYGYlFheVyo39qWhfjw81iAerG wKMlWmfTn1/7mjXzEvKQ92chlw0RTrcfAguXv2JFx3f2Vs4u29GsJfy7hdcDGrvD2tVrqoV Zeszt/vqT9WVwjlO5Orqg== X-UI-Out-Filterresults: notjunk:1;V01:K0:pI7knYhjvos=:zO8CcxPciv568jV934AXzJ vuQTscP+Og67v3ZvAnx9nb6sYPRFwI4aoEQzONUW4HwoufDOO531R3Tvm76FH9YUmoaGgpUyi 2k7EWUjFBtX+EgsUviyhzYpBtal3EqgezuPbfVSR1+MfPp5zrhgu/YZ9+z+F96p8kC5Vymybt PYa0JcpLDXDKf9Z/ZgNhffCZVhKx3rh8GyfB5fCfuN6oYi8lPe0b0ksiAl8Jz16b+Rt+vch0w QYK2/oi/xEsTcqEDqjRt/3ihwPJ1thvHPf8dVFmznWV9yldNn41hWU7igY0ZXiC8C1QNAMVyY CtCtuT8/9HBCpAcOxbTetifTjTqriuFxlYutrKGPLNcs2Rwadz5gAwHpLT5kK/mOup98CvVQo nk8vd1Vg9EJZw3/UaC81mAgwiivFWHmE3aHr9NdlvfPIpK3svEyE3iqIO9wNK9xiixqkBDL24 YoVgblrIbAhavrkHI0I+bKMzHCgraTp6Iy1xs6JNzQKJzujHhjErgo8C3sBVEmRu95bpQuRsO L1QxAn6DrpcfyKoMonsc8C6PbkK8ahEE2tcn1mCBPG433CmNJ+zpqndVcop9TJcJy4+6CfhKc fAIXB9Hs03oRXIWchfpFGm1c63IXCG2LU8DdvVtsDx746VCwA/r1cKygt6y9LNNwyGXjSZ459 Va9oGJ5/CYxcHBlCrqd9BBHykre4Ipqs24zyW7c4WasFa4tv4Ue9FULqt8w/99JfWp7ljnB8k iolJW1slHinHaX9MhrkXN/tumqlh0Iti/LtnrTk4sZe/gVGN+UamVJ/cLi+YJvNei/9sUB/Hq E2D4hWI Subject: Re: [Cake] Cake strange behaviour X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2016 13:37:30 -0000 ------W2XM6C134GSD2SDQ4TC8TL9QZXV58B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Kevin, Silly idea, use the Windows rollback point (or what is it called) from bef= ore the update and then run Windows upgrade again=2E Sebastian On July 16, 2016 1:53:20 PM GMT+02:00, Kevin Darbyshire-Bryant wrote: > > >On 16/07/16 11:59, Dave T=C3=A4ht wrote: >> I would repeat the same test with htb+fq_codel=2E > >Hi Dave, > >That's more challenging than it sounds - reproducing the test scenario=20 >would require the windows box going back in time=2E What could it be=20 >doing that so far any of the flent tests fail to replicate? Hmmm, so=20 >far I've used a local flent server=2E=2E=2EI wonder if RTT is at play her= e? > >Kevin > >> >> On 7/16/16 11:35 AM, Kevin Darbyshire-Bryant wrote: >>> Hi guys, >>> >>> Encountering some behaviour that I don't understand=2E Line is a >40/10 >>> cake limited to 39000/9840=2E Overheads 12, 'dual-dsthosts' in >ingress, >>> 'dual-srcshosts' on engress - limiting the on the WAN line=2E Take a >look >>> at my ping response graph >>> >>> >http://www=2Ethinkbroadband=2Ecom/ping/share/9822cb5160582fa6abee29b60d80= 7766-16-07-2016=2Ehtml >>> >>> >>> Around 20:30 I fired up a windows machine that was behind on its >updates >>> so it generated a bit of ingress traffic=2E Note the comparatively >high >>> latency (40ms) and stupidly high ping packet loss (50%) The 3-5ms >>> steady (blue) latency you can see is a system backup (so egress >traffic) >>> running till around 23:00=2E >>> >>> The really strange bit is that cake stats show it has only dropped >10 >>> (yes 10!) packets=2E >>> >>> I'm not the only person encountering 'interesting' behaviour with >regard >>> to windows updates inducing high latency and high packet loss=2E It's >as >>> if cake weren't there managing flows and this is the ISP's rate >limiter >>> in action=2E >>> >>> Kevin >>> >>> _______________________________________________ >>> Cake mailing list >>> Cake@lists=2Ebufferbloat=2Enet >>> https://lists=2Ebufferbloat=2Enet/listinfo/cake >> _______________________________________________ >> Cake mailing list >> Cake@lists=2Ebufferbloat=2Enet >> https://lists=2Ebufferbloat=2Enet/listinfo/cake > >_______________________________________________ >Cake mailing list >Cake@lists=2Ebufferbloat=2Enet >https://lists=2Ebufferbloat=2Enet/listinfo/cake --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------W2XM6C134GSD2SDQ4TC8TL9QZXV58B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Kevin,

Silly idea, use the Windows rollback point (or what is it called) from bef= ore the update and then run Windows upgrade again=2E

Sebastian

On July 16, 2016 1:53:20 PM GM= T+02:00, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant=2Eme=2Euk> = wrote:


On 16/07/16 11:59, Dave T=C3=A4ht wrote:=

 I would repeat the =
same test with htb+fq_codel=2E

Hi Dave,

=
That's more challenging than it sounds - reproducing the test scenario 
would require the windows box going back in time=2E  What could it be doing that so far any of the flent tests fail to replicate?  Hmmm, so far I've used a local flent server=2E=2E=2EI wonder if RTT is at play h=
ere?

Kevin


 On 7/16/16 11:35 AM, Kevin Darbyshire-Bryant wrote:
 Hi guys,

 Encounte=
ring some behaviour that I don't understand=2E  Line is a 40/10
 cake =
limited to 39000/9840=2E Overheads 12, 'dual-dsthosts' in ingress,
 'd=
ual-srcshosts' on engress - limiting the on the WAN line=2E Take a look
 at my ping response graph

 h=
ttp://www=2Ethinkbroadband=2Ecom/ping/share/9822cb5160582fa6abee29b60d80776=
6-16-07-2016=2Ehtml


 Around 20:30 I fired up a windows=
 machine that was behind on its updates
 so it generated a bit of ingr=
ess traffic=2E  Note the comparatively high
 latency (40ms) and stupid=
ly high ping packet loss (50%)  The 3-5ms
 steady (blue) latency you c=
an see is a system backup (so egress traffic)
 running till around 23:=
00=2E

 The really strange bit is that cake stats show it has onl=
y dropped 10
 (yes 10!) packets=2E

 I'm not the only person=
 encountering 'interesting' behaviour with regard
 to windows updates =
inducing high latency and high packet loss=2E  It's as
 if cake weren'=
t there managing flows and this is the ISP's rate limiter
 in action=
=2E

 Kevin


 Cake mailing list
 Cake@=
lists=2Ebufferbloat=2Enet
 https://lists=2Ebufferbloat=2Enet/listinfo/cake
<=
/blockquote>

 Cake mailing list
 Cake@lists=2Ebufferbloat=
=2Enet
 ht=
tps://lists=2Ebufferbloat=2Enet/listinfo/cake

<=
hr />
Cake mailing list
Cake@lists=2Ebufferbloat=2Enet
https://lists=2Ebuff=
erbloat=2Enet/listinfo/cake

--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------W2XM6C134GSD2SDQ4TC8TL9QZXV58B--