Delivery-Date: Thu, 13 Aug 2015 06:23:57 -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_SIGNED,
	RCVD_IN_DNSWL_MED,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY
	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 96BD61E03B6;
	Thu, 13 Aug 2015 06:23:55 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 4B4E93688F;
	Thu, 13 Aug 2015 10:23:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 526E136829
 for <tor-talk@lists.torproject.org>; Thu, 13 Aug 2015 10:23:46 +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 VeTPBysflYtC for <tor-talk@lists.torproject.org>;
 Thu, 13 Aug 2015 10:23:46 +0000 (UTC)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 2149B367C5
 for <tor-talk@lists.torproject.org>; Thu, 13 Aug 2015 10:23:46 +0000 (UTC)
Received: from piha.riseup.net (unknown [10.0.1.162])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
 by mx1.riseup.net (Postfix) with ESMTPS id ECC58C28F6
 for <tor-talk@lists.torproject.org>; Thu, 13 Aug 2015 03:23:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1439461423; bh=VZ3SWnpSW32ubW4Jp7+eWhDZSqOFKob/e2YgSsSKBaY=;
 h=Subject:To:References:From:Date:In-Reply-To:From;
 b=tRlhdjCF7dJ9pvGags6x93oUtEcchZulIJGQZH5vjTfgXlt3LEUtBDPWCkc9Clp2p
 yWZD8wrzV3TJPBttzyvMEDxkx9T6lArh+fHHODviiz0y6rI7P5RWqzpDhSthKEZUUy
 kYcK/D25GgRT6QeQaUJibjVnd724SgkIZROi+bm4=
Received: from [127.0.0.1] (localhost [127.0.0.1])
 (Authenticated sender: thomaswhite) with ESMTPSA id 385B414140A
To: tor-talk@lists.torproject.org
References: <CAD2Ti29ayQJ73Ph6_AyT3iBcAs7n_8z2=O6n8-73gEhM5LFsaA@mail.gmail.com>
 <20150813073054.GW7945@moria.seul.org>
From: Thomas White <thomaswhite@riseup.net>
X-Enigmail-Draft-Status: N1110
Message-ID: <55CC7025.1020804@riseup.net>
Date: Thu, 13 Aug 2015 11:23:33 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <20150813073054.GW7945@moria.seul.org>
X-Virus-Scanned: clamav-milter 0.98.7 at mx1.riseup.net
X-Virus-Status: Clean
Subject: Re: [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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Totally agree on the fact. Most of the load is also placed onto exits
and I can certainly testify no matter how much bandwidth or CPU power
I gave the tor process as an exit with quite liberal exit policies, it
really ate it up and rarely had below 90% usage, let alone 50%.

Adding multicore would improve the speed of the network because it
means each relay can handle more load, thus is less likely to
bottleneck on CPU factors which is probably at exits, which I'd also
guess is where most of the latency resides. That would probably be a
good research point to add to the page of research options - to find
where the network choke points are and ways to reduce them.

Anyway this is another reason I am all in favour of hidden service
usage for tasks like updating the Tor browser over hidden services to
reduce exit node traffic and perhaps increase security with the end to
end encryption (yes yes I know the package signing key is checked on
clearnet download, I am just making a point for use).

Furthermore, we have other factors weighing in on the usage capacity
such as underweighted/measured relays, and I imagine there are lots of
non-guard or exit relays out there seeing only fractional volumes of
traffic too.

I think increasing the cryptographic strength of the network will also
increase cpu load, placing a higher degree of load on a CPU per packet
than before. If we are to upgrade any of the crypto behind Tor, I
think multicore should definitely be considered alongside it for
integration since at least on my exits, the CPU was always the
bottleneck and not the network.

T


On 13/08/2015 08:30, Roger Dingledine wrote:
> (Ugh -- please don't cross-post across lists. I'm going to pick
> the list that had the previous thread on it.)
> 
> On Thu, Aug 13, 2015 at 03:03:10AM -0400, grarpamp wrote:
>> 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.
> 
> Careful! I think this is a really bad conclusion. There is no
> practical way for the Tor network to use all of its capacity, and
> we shouldn't expect it to. Normal networks start to fall apart when
> they reach around 20-30% of total capacity. The Tor network is
> still way overloaded -- just not as overloaded as before.
> 
> First, operating at 100% capacity would imply that we somehow line 
> up every relay in every circuit to never have any spare capacity.
> In practice, each circuit will have some relay that is smallest /
> most congested at the time. The goal for performance is to have
> that smallest relay be not too bad.
> 
> Second, a network operating "at" capacity pretty much guarantees 
> congestion at most relays. In an ideal world, every relay would
> have spare capacity for every circuit. Or to put it another way,
> whenever a relay runs out of bandwidth (e.g. it hits its rate
> limit), then that adds a delay to all the circuits that are still
> hoping to get traffic through it. Or to turn it around once more:
> we want to minimize the number of cases where relays are operating
> at capacity. Excess capacity is necessary for good performance.
> 
> For a historical perspective, you might enjoy the "Why Tor is
> slow" document and video: 
> https://blog.torproject.org/blog/why-tor-is-slow (Some of the
> issues have been fixed since then, and some of them have not.)
> 
> --Roger
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVzHAjAAoJEIC+hZxcLl/k9rMQAIiUBJrhOvmKoNLLA6Jo6Ta0
ZjssIi/QFP/+2KjqCLi3DlHX1rlhxfC2LQAAciWh2AVL1ceFt6ToOx+PF9RuM3Ox
PjoIYWeH+Fi32pjl8C3v2gSjQyzW498PdY4bupjOP+q/lmtcdCD2nLzIatw75Lvj
cLs446tPT4Htb8CoTiktZE+npCeeOj35k0Ufo8BjZ+ZlJBIR3zuUfK92/ud6zbPG
XLCpu7WUorWJ5Xfjk5dKzSHwQpm0KgCkVsq3caa4LPHNCSKqXsTxxtyACDZ29qp1
/VUG95ykPwiGmMpovG+rjhVPyq7yi9MmlKDLCNlYyRlaNVQtl9AiplZXCTSFJ5Og
/RECqqhDsWGFW1sWkkY0PraFX+B3SPXLMWGbH8pAz32CRZoVMYEPWOcOFfZxqik4
UBpHpPLVFP5HUZghIAKfNkw+tSGcGo9K+4trjL8QYbmfEcGLOn1gCoqGLQMesc0U
xK/EgCiZCsyawAyP8ElCkbXs5KVjvNzaS+rXYYJW2GHzl39Z1sTV5nNX99KDEhI/
dpFrRQGT+EdYwJwzxSPVCSAzWXITGRXGvf7lg6yINMGKK+Vy1kkSwxWDVqe1RyTY
1bMknVEL10dySQeNOWokTpLTaYJP3D4x3Y3M86uCR9VZGCa+v6OxAZe1LTWltnWr
x1pEXBIzS1gUyHjpx+cC
=VafV
-----END PGP SIGNATURE-----
-- 
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

