From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by huchra.bufferbloat.net (Postfix) with ESMTP id 21EB3208AB4; Mon, 26 Nov 2012 10:12:14 -0800 (PST) Received: from obiwan.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id AF2F22016D; Mon, 26 Nov 2012 13:13:58 -0500 (EST) Received: by obiwan.sandelman.ca (Postfix, from userid 179) id 9D3F963A8E; Mon, 26 Nov 2012 13:11:47 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [127.0.0.1]) by obiwan.sandelman.ca (Postfix) with ESMTP id 73C8F63A8C; Mon, 26 Nov 2012 13:11:47 -0500 (EST) From: Michael Richardson To: dpreed@reed.com In-Reply-To: <1353947863.437620265@apps.rackspace.com> References: <20121125232034.GF24680@merlins.org> <31933.1353939756@obiwan.sandelman.ca> <1353942251.571510886@apps.rackspace.com> <13866.1353944313@obiwan.sandelman.ca> <1353947863.437620265@apps.rackspace.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@obiwan.sandelman.ca Cc: cerowrt-users@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] [Cerowrt-users] QOS settings vs speedboost and random bandwidth 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: Mon, 26 Nov 2012 18:12:15 -0000 >>>>> "dpreed" == dpreed writes: dpreed> But I've thought about coding it again for cerowrt. Where dpreed> to modularly slot it in seems to be worth thinking about. dpreed> Perhaps in two key pieces: an iptables/xfilter module and a dpreed> routing/traffic control module - with some direct dpreed> interaction between the two using some appropriate dpreed> intermodule bus/link/coordination link. So an uplink bitrate value with an easy to reach sysctl that userspace can toggle? It would be an enhancement to existing tc/qos code. dpreed> I'd be happy to think about defining the pieces, but I dpreed> really don't have time to code it, given all the other stuff dpreed> I've done. I wonder if by putting it in these modules, one dpreed> can use existing kernel APIs. How precise timing do you think we need? As I understand what you are saying, by periodically sending a few ICMP messages (does it help if they are back to back?) and looking when they are returned, one can calculate the uplink bandwidth? Or are you saying that we are measuring the point in uplink usage where the latency begins to peak? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition.