From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 2C1BE21F35C for ; Wed, 18 Nov 2015 03:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1447847872; bh=NvGTfUca7cnhfsvBdcU8YsHFPVFdFEH1KGb4hdp8bNI=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=f4I8yu7pXM8f+iG77ISp83uNx8iUd7hmiSn1M4hdfdxLNpmJ0Y0eZB4Y3q2+REDyO JgzrrVA3DrCWUdwubelYLkl4lEKBT70wsnbKQuKpNAlTp3NhScoyAw6qvgJX3aR6Eb IxLmaX1ygSzzm3h+Jw/9E9n2OCezmsJBnbmzy3G4= Sender: toke@toke.dk Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id B155AC402E2; Wed, 18 Nov 2015 12:57:51 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Kevin Darbyshire-Bryant References: <564C5E56.3060700@darbyshire-bryant.me.uk> Date: Wed, 18 Nov 2015 12:57:51 +0100 In-Reply-To: <564C5E56.3060700@darbyshire-bryant.me.uk> (Kevin Darbyshire-Bryant's message of "Wed, 18 Nov 2015 11:17:42 +0000") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87oaera5a8.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Cc: cake@lists.bufferbloat.net, Jesper Dangaard Brouer Subject: Re: [Cake] Announce - possible new feature - DSCP cleaning X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 11:58:18 -0000 Kevin Darbyshire-Bryant writes: > The jury hasn't even been assembled, let alone sat as to whether these > (potentially) increasing targets/intervals on 'slow' links is a good > thing(tm) or not. I think I was leaning towards 'no' last time around on this. >> memory used: 612600b of 15140Kb # not huge on parsing this >> capacity estimate: 724522Kbit # not huge on parsing this > > That's a function of the sprint_size(), sprint_time(), sprint_rate() > (and matching get_*() ) helpers provided by tc. Similar 'playing with' > units can be seen in the threshold values for each tin. A 'classic' > example demonstrating both A) and unit playing: I think we should prioritise human readability in tc output. If we want to have a mode that is easy to parse, make it a separate one (was looking for a 'machine-readable' switch to tc, but there doesn't seem to be one). Would it be viable to get a patch into iproute that makes it sprout csv or json, do you think? Besides, as far as being a pain to parse, the 'tin table' is way worse, as far as I'm concerned. -Toke