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