Delivery-Date: Thu, 13 Aug 2015 03:31:08 -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.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	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 8691A1E0FF1;
	Thu, 13 Aug 2015 03:31:06 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id A1A0936717;
	Thu, 13 Aug 2015 07:31:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 8653C3669C
 for <tor-talk@lists.torproject.org>; Thu, 13 Aug 2015 07:30:57 +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 duPNo3cn2m7v for <tor-talk@lists.torproject.org>;
 Thu, 13 Aug 2015 07:30:57 +0000 (UTC)
Received: from khazad-dum.seul.org (khazad-dum.csail.mit.edu [128.31.0.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "moria.seul.org", Issuer "moria.seul.org" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 6559E359EB
 for <tor-talk@lists.torproject.org>; Thu, 13 Aug 2015 07:30:57 +0000 (UTC)
Received: by khazad-dum.seul.org (Postfix, from userid 501)
 id C930B1E0FF1; Thu, 13 Aug 2015 03:30:54 -0400 (EDT)
Date: Thu, 13 Aug 2015 03:30:54 -0400
From: Roger Dingledine <arma@mit.edu>
To: tor-talk@lists.torproject.org
Message-ID: <20150813073054.GW7945@moria.seul.org>
References: <CAD2Ti29ayQJ73Ph6_AyT3iBcAs7n_8z2=O6n8-73gEhM5LFsaA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAD2Ti29ayQJ73Ph6_AyT3iBcAs7n_8z2=O6n8-73gEhM5LFsaA@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
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>

(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

-- 
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

