From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4A928201904 for ; Sun, 14 Sep 2014 09:56:31 -0700 (PDT) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XTD6C-0000nn-AS for cerowrt-devel@lists.bufferbloat.net; Sun, 14 Sep 2014 18:56:29 +0200 Received: from CPE-60-231-35-7.lns5.cha.bigpond.net.au ([60.231.35.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Sep 2014 18:56:28 +0200 Received: from rocon46 by CPE-60-231-35-7.lns5.cha.bigpond.net.au with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Sep 2014 18:56:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: cerowrt-devel@lists.bufferbloat.net From: Richard Date: Sun, 14 Sep 2014 16:56:18 +0000 (UTC) Message-ID: References: <55089E42-3800-42B9-AD4D-D6186C0335FE@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 60.231.35.7 (Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0) Subject: Re: [Cerowrt-devel] Possible Bug(s) in Cero 3.10.50-1 X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 16:57:01 -0000 Sebastian Moeller gmx.de> writes: > Too bad, in case you find a way to force this failure mode, please let me know so I can have a go at fixing it... > Will do. > > I think a number of people have been quite happy with the sysupgrade via the GUI (just de-select the “keep > sttings” check box and you should be fine). I think what really could cause the issues observed is when > SQM's stop.sh fails half-way through (I will try to have a look at that later...) I can't believe I've manage to overlook that a few times. Ugh, I guess I should pay more attention when going through the menus next time. > > But that is a systematic problem with downstream shaping after the the bottleneck-link (by creation of an > artificial bottleneck), too much incoming traffic of any kind will cause backlog in the buffers of the > device at the upstream end of the real bottleneck-link… So even if the ICMP packets reach cerowrt this > might still hose the downstream latency under load... Yeah, you're right about that. I'm just saying that dropping the ICMP echo requests may help in it's own small insignificant way by simply having less request being made by random bots on the net due to the lack of response. Of course if they know you're there, do a port scan, or aren't phased by a lack of response, it doesn't make a lick of difference as they're still filling the downstream pipe. But I get what you mean, excessive inbound traffic which fill up the buffers on the real bottleneck device will reek havoc on latency. Dave Taht I figure that QoS chain needs to be applied to the pppoe interface not the ge00 interface? I thought so too, but I'm just saying you can't apply the QoS chain directly to a PPPoE session through the GUI as SQM's GUI page only let's you select the interface it's running through (which was ge00 in my case). The more I think about it, I should've probably tried editing the SQM config files and directly point it to the PPPoE interface just to see if it worked or not. I wish I could've messed around with it more, but I no longer have a modem to play with. But you're probably right. > > > I'm > > aware it might break some websites that use MTU path discovery, but I > > figured using MSS clamping in Cero would solve any problems that might > > incur. That's my reasoning for it, anyway. > > I would hope that the real xdsl-router handles either the MSS clamping for us or better yet properly > handles the IPv6 path mtu discovery (and at least in may case that works well) > > Best Regards > Sebastian > > > > > Thanks for the input. > > Richard > > > >> Best Regards > >> Sebastian > >> > >>> > >>> I'd like to know anything at all before I decide to go looking for another > >>> dedicated modem, or if I should even bother to go looking in the first > > place. > >>> > >>> Hope this helps! > >>> —Regards, Richard > >>> > >>> _______________________________________________ > >>> Cerowrt-devel mailing list > >>> Cerowrt-devel lists.bufferbloat.net > >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel > >> > >> > > > > > > > > > > _______________________________________________ > > Cerowrt-devel mailing list > > Cerowrt-devel lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/cerowrt-devel > >