From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id EFF55138330 for ; Wed, 21 Sep 2016 19:38:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3C61BE0B60; Wed, 21 Sep 2016 19:37:55 +0000 (UTC) Received: from mail-qt0-f181.google.com (mail-qt0-f181.google.com [209.85.216.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 10531E09B9 for ; Wed, 21 Sep 2016 19:37:52 +0000 (UTC) Received: by mail-qt0-f181.google.com with SMTP id 38so27692115qte.1 for ; Wed, 21 Sep 2016 12:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=KjMjw7pt+LhPHdguCq+l49Naqq3PqnmR9ry4WYyeX/4=; b=tlb/yBjDhwiJDo/FjZHOE3r0LetDAkrPK1q7bLchXvuhlbCQVh2bKiXyXqXNQbetFl pAs/GQVHp3WnETIZmPDULTSvTxw5yZPth36rrQZZ/9hVX4MAtojGNUDOSeIlBPtttgim avzkhmdAHzfZJ6cMiA2DoyoFz6ZoBVQszzINURcGQICSFi3PS3uc1u99bNEeE9OTUAvr F2vIT/ZqCsY+IpT+me9ny9uf3MUGKiP5Wxm1e5W1m5Xl6QQT8W2bLuoNJmb00K8kpQjP OZ5GIXFmypd29oy6wmyZfbnrKyYyJbNDk3x6BE+WZmPBSN5bdz0aQMBS++dq1f0+YjD0 BnAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=KjMjw7pt+LhPHdguCq+l49Naqq3PqnmR9ry4WYyeX/4=; b=JDmcN+XL6Mj43iXIFgTgGtbKVqWW4QjPIU3sz5NksDNLFdFz9s0c78jJGyBg8GyBlQ jX/bN8NV5+eGk7vIa6Z3ULfPktLJz3eNGbn8Op5muMexnzZtUGdX27PgU0z1nszKoq5q cXElbSC8/0scB2ZzuJyX9IuOxt/SCUxZ2Wwe7auqbGG6LIhDxfJvWvrb/sz740ERI+1D EAfCrgnBHQt5lqo0Zviu/bnh4BkkvpxAiFk87VZ+iXt3FE+yckmKSIr8syFef7mqlm9M DLYd7EaHrj78aXQJ3RmChyge0WZ6EK4uEGPCAzDg1gnZZ8m2GhXbW3T7LVH+jydfU5RH U1jA== X-Gm-Message-State: AE9vXwOc5G5wcsSsje3Z6/koctxN5bzqH3qdFenX/NHam+z9GMGq532ni/mC3jKHwU6sMZySq+bMdvXMBGUJWg== X-Received: by 10.237.60.44 with SMTP id t41mr43654254qte.102.1474486672126; Wed, 21 Sep 2016 12:37:52 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.140.38.179 with HTTP; Wed, 21 Sep 2016 12:37:51 -0700 (PDT) In-Reply-To: <20160921212913.352eae72@jupiter.sol.kaishome.de> References: <20160921060118.759d94ba@jupiter.sol.kaishome.de> <20160921212913.352eae72@jupiter.sol.kaishome.de> From: Grant Date: Wed, 21 Sep 2016 12:37:51 -0700 Message-ID: Subject: Re: [gentoo-user] Re: TCP Queuing problem To: Gentoo mailing list Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 4e6ca9fc-3e0d-4a8b-a5f4-8d124dd2491a X-Archives-Hash: a4473cbf5076421d0c278bc6259ab416 >> >> I just remembered that our AT&T modem/router does not respond to >> >> pings. My solution is to move PPPoE off of that device and onto my >> >> Gentoo router so that pings pass through the AT&T device to the >> >> Gentoo router but I haven't done that yet as I want to be on-site >> >> for it. Could that behavior somehow be contributing to this >> >> problem? There does seem to be a clear correlation between user >> >> activity at that location and the bad server behavior. >> > >> > If that device behaves badly in router mode by blocking just all >> > icmp traffic instead of only icmp-echo-req, this is a good idea. >> > You may want to bug AT&T about this problem then. It should really >> > not block related icmp traffic. >> >> >> Hi Kai, yesterday I switched my Gentoo router over to handling PPPoE >> and pings seem to be working properly now. The AT&T device is now >> functioning as a modem only and passing everything through. Today >> I'll find out if it helps with TCP Queuing and (supposedly) related >> http response slowdowns. > > You may want to set the default congestion control to fq-codel (it's in > the kernel) if you're using DSL links. This may help your problem a > little bit. It is most effective if you deploy traffic shaping at the > same time. There was once something like wondershaper. Trick is to get > the TCP queuing back inside your router (that is where you deployed > pppoe) as otherwise packets will queue up in the modem (dsl modems use > huge queues by default). This works by lowering the uplink bandwith to > 80-90% of measured maximum upload (the excess bandwidth is for short > bursts of traffic). Traffic shaping now re-orders the packets. It > should send ACK and small packets first. This should solve your > queuing problem. We're talking about optimizing the DSL connection at my office but the server is located in a data center. I can't imagine optimizing that office DSL connection is the way to solve this even though the http response slowdowns do correlate to office hours. As a note, the slowdowns are recorded by my third-party monitoring service. - Grant > Between each step check dslreports.com for bufferbloat. I'm guessing it > is currently way above 1000 ms while it should stay below 20-50 ms for > dsl. > > The fq-codel congestion control fights against buffer bloat. But it can > only effectively work if you're doing traffic shaping at least on your > uplink (downlink may or may not be worth the effort depending on your > use-case). > > Additionally, you can lower the priority of icmp-echo-reply this way so > during icmp flooding your uplink will still work. > > This link may help you: > https://www.bufferbloat.net/projects/codel/wiki/Cake/