Delivery-Date: Thu, 13 Aug 2015 03:03:45 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,T_DKIM_INVALID,T_RP_MATCHES_RCVD
	autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id E46111E0FDD;
	Thu, 13 Aug 2015 03:03:43 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 7AE433644F;
	Thu, 13 Aug 2015 07:03:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 83C5E35588;
 Thu, 13 Aug 2015 07:03:12 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id HZWIT6pFgcoc; Thu, 13 Aug 2015 07:03:12 +0000 (UTC)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com
 [IPv6:2607:f8b0:4001:c05::231])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 6368735586;
 Thu, 13 Aug 2015 07:03:12 +0000 (UTC)
Received: by igfj19 with SMTP id j19so30094941igf.1;
 Thu, 13 Aug 2015 00:03:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:date:message-id:subject:from:to:cc:content-type;
 bh=vQjpt6YcvMa/p6cfJjAqMfOCBGgIR2Tk6uLS95fGSrU=;
 b=yRLtB75xNfQ8A8ZiF4dmvaWffisNlb/WeoDi5UNqqcGr/+rzjk2xMVAEHlcZQKlf9V
 5//Jq21tAu40vX9foH73URIX9BUVZfBDDdxo8jA4FizLptbhxxRvSTXAb1Q5cM6dqmSy
 epqT6t4viJweZLwXHleKifnj3EPRvM5eCGYHvYJu1PqF3u0WteahrYALKVsdvp25Oc5M
 oYLNQ1OsK5DWqeRR7ANFHMTOQIWS5yB5lUN9cr1OLXr8Y3GM54iuZrCfTgZqRKXztBqW
 bczngKwDAI4PDFYsN0isqPKMp8JS+arPK8Snm0tFkmwI9WLtx0N7i52pRANFGFukzo+q
 CiHA==
MIME-Version: 1.0
X-Received: by 10.50.153.75 with SMTP id ve11mr16998014igb.52.1439449390178;
 Thu, 13 Aug 2015 00:03:10 -0700 (PDT)
Received: by 10.36.44.69 with HTTP; Thu, 13 Aug 2015 00:03:10 -0700 (PDT)
Date: Thu, 13 Aug 2015 03:03:10 -0400
Message-ID: <CAD2Ti29ayQJ73Ph6_AyT3iBcAs7n_8z2=O6n8-73gEhM5LFsaA@mail.gmail.com>
From: grarpamp <grarpamp@gmail.com>
To: tor-relays@lists.torproject.org
Cc: tor-talk@lists.torproject.org
Subject: [tor-talk] Multicore, bandwidth, relays, capacity, location
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On Wed, Aug 12, 2015 at 9:16 AM, Thomas White <thomaswhite@riseup.net> wrote:
> For relays, being able to make more use of available bandwidth would
> vastly increase the network speed, furthermore make home clients see
> an improvement in their daily Tor usage. It also benefits hidden
> service people as they can then run their Tor processes on more than
> one core and thus handle higher volumes of traffic.

Tor appears maybe operating at 50% of bandwidth capacity...
https://metrics.torproject.org/bandwidth-flags.html
https://metrics.torproject.org/bandwidth.html
https://metrics.torproject.org/bwhist-flags.html

If that's true, more bandwidth won't have any end user affect.
So for the moment it might be worthwhile to study
reducing node based latency by ensuring relay CPU's
have similar free capacity available for circuit negotiation,
interrupt processing, and other tor functions.

And to consider not dropping more bandwidth weight into
already saturated jurisdictions, but dropping some into the
Southern Arc and Eastern Zones in an effort to avoid Orion's Belt...
https://metrics.torproject.org/uncharted-data-flow.html

[Yes I broke the thread because "no subject" and gmail
are even lamer than I].
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

