Re: [tor-talk] Multicore, bandwidth, relays, capacity, location

[grarpamp <grarpamp@xxxxxxxxx>]

On Thu, Aug 13, 2015 at 6:23 AM, Thomas White <thomaswhite@xxxxxxxxxx> wrote:
> Totally agree on the fact. Most of the load is also placed onto exits

I'd say that depends as some function on the ratio of number of exits
vs non-exit relays, and the destination ratio of all client traffic between
HS and clearnet. The first ratio is just math on intrinsic design and
current relay counts. The second needs input from the clients (as
their horizons are simplest capture point).

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

I did say "if true". And I get network peaking and headroom.
If there are metrics that show the 90% anecdotes, that's good,
I didn't look beyond metrics first page.
If not, actual provisioned capacity vs usage on relays would seem useful,
even as opt-in submission.

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

Identifying bottlenecks and balance in code is different from, "we're idling
three cores, and hit two IP's, have bw to burn, let's bring those cores in".
That's ok, until you bring them in and again wonder if you can maximize
what you have.

> 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

So exits no longer serve the non-exit relay function?
Or TBB and update HS will construct manual circuits to avoid them?


I'd rather club "no subject"ers than those cross posting as fyi's
or solicitation to ontopics. And gmail dethreads subject change,
shame on google.
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk