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 71081138330 for ; Wed, 21 Sep 2016 19:53:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 36CBFE09AF; Wed, 21 Sep 2016 19:53:20 +0000 (UTC) Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com [209.85.220.176]) (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 DCEFAE0979 for ; Wed, 21 Sep 2016 19:53:18 +0000 (UTC) Received: by mail-qk0-f176.google.com with SMTP id t7so56632203qkh.2 for ; Wed, 21 Sep 2016 12:53:18 -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=MZoTdOdBWH8m6LdXdjOg3lRHw6I1CR/ILXALaFkjzc8=; b=VBh4E+BgsKGSNcHE5gbwp4g55nE9IVLurw8zQ/9dTp/ecJpV+0C5FTT701eJpaQHeq GzPOL9kyzhW9B9Z5SkiKD2OMez7BM5dasMsBJeAB+LIFc1jqFgdW0089puZps5JWBd/J ILbLLOsKZnrOy/XiAV8Q5HOafI9BGDP0PPmtOKoxkhRe7lIezgB5I9c1nDC6yeOrr5bI T27g4TGelEMnTc0VOYzjWOD9Bb1VeG6plOukxCk9R9wWWJq7f0FCgwh7Jyy0+QbHb5O/ QziTS+vDkHIqoAzFXcm9MnOejzkm2y65YRp2ylJ3u6cuGcpZK9jTUQGLBAYzChlfgCdD 3acw== 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=MZoTdOdBWH8m6LdXdjOg3lRHw6I1CR/ILXALaFkjzc8=; b=FUB0EiqO4CuqXitVcCQFwK4jx7EEoVyHrTAw43XixmSva90dAte7+MvzsrnH9+Pfh7 MnLGeQpUCLuUawjtfjiArjUjd0h/Ga7n9CXn7XcrQ1m5IucC1SO4f/lx4VgWYKC+r1/I FWyLxPHaUwu/yIzeBhL3YkH2T6gzGzB7kqZf9b+QTKDJfeqMp0j4s8zdV0OvB75BP9R3 RNmDpu+V+OsghDOL5rtaYmxVGXpVX+wBJc0XYV+nnFk7Gz+LOfvRBlACjM4SNiUhB/qb x6KTzGa2CPU1jJ0Q3MSqlC2MoBvnNADUMV/gj1PZn2P4meAQLz4kXHkFELkltapEMFlm Il+w== X-Gm-Message-State: AE9vXwM2Q1KWnyMZ2iNu5c6K58cqQvIF4NHVk3N28KeGUQcVb0r5MUQ6OmcfSWdUBlMp3pLaLZyxu3ikQJODgg== X-Received: by 10.55.147.66 with SMTP id v63mr32947590qkd.298.1474487598051; Wed, 21 Sep 2016 12:53:18 -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:53:17 -0700 (PDT) In-Reply-To: <20160921214138.3ca8a146@jupiter.sol.kaishome.de> References: <20160921060118.759d94ba@jupiter.sol.kaishome.de> <20160921212913.352eae72@jupiter.sol.kaishome.de> <20160921214138.3ca8a146@jupiter.sol.kaishome.de> From: Grant Date: Wed, 21 Sep 2016 12:53:17 -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: 9c169132-e38d-4a3c-9b6c-9e6e40ad8864 X-Archives-Hash: cce1dc0f835b20cfec9a2ad6dd1172f7 >> > > 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 I haven't mentioned it yet, but several times I've seen the website perform fine all day until I browse to it myself and then all of a sudden it's super slow for me and my third-party monitor. WTF??? - Grant