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 B3AB7138330 for ; Wed, 21 Sep 2016 19:42:18 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C5267E0B12; Wed, 21 Sep 2016 19:42:08 +0000 (UTC) Received: from blaine.gmane.org (unknown [195.159.176.226]) (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 4C7A7E0AA9 for ; Wed, 21 Sep 2016 19:42:08 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1bmnP1-0002tV-QH for gentoo-user@lists.gentoo.org; Wed, 21 Sep 2016 21:41:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Kai Krakow Subject: [gentoo-user] Re: TCP Queuing problem Date: Wed, 21 Sep 2016 21:41:38 +0200 Message-ID: <20160921214138.3ca8a146@jupiter.sol.kaishome.de> References: <20160921060118.759d94ba@jupiter.sol.kaishome.de> <20160921212913.352eae72@jupiter.sol.kaishome.de> 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@blaine.gmane.org X-Newsreader: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) X-Archives-Salt: 55f4f86a-e8bf-4965-a775-191f94f5db6b X-Archives-Hash: 4752b0cd7c660b20866f76818a34db44 Am Wed, 21 Sep 2016 21:29:13 +0200 schrieb Kai Krakow : > Am Wed, 21 Sep 2016 07:30:40 -0700 > schrieb Grant : > > > [...] > > [...] > [...] > > > > > > 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. > > 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/ And this: https://github.com/tohojo/sqm-scripts -- Regards, Kai Replies to list-only preferred.