[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #7177 [Torflow]: Understand how accurate the bandwidth authority estimates are
#7177: Understand how accurate the bandwidth authority estimates are
----------------------+-----------------------------------------------------
Reporter: karsten | Owner: aagbsn
Type: project | Status: new
Priority: normal | Milestone:
Component: Torflow | Version:
Keywords: SponsorZ | Parent:
Points: | Actualpoints:
----------------------+-----------------------------------------------------
Changes (by aagbsn):
* cc: gamambel (added)
Comment:
Replying to [ticket:7177 karsten]:
> (Re-using text from Roger and Mike for this ticket description.)
>
> It would be good to have a better understanding of how accurate the
bandwidth authority estimates are. Why do some really fast relays get
huge weights, and other really fast relays don't? Does it have to do with
location of the measurers? What exactly is the trade-off between having
fast nodes all nearby each other (and nearby the bandwidth authorities) in
the network, and having nodes in geographically dispersed places?
Can we come up with a list of "really fast relays" that don't have huge
weights? I've seen an exit operator complain that his/her exit in the same
datacenter as another exit does not see similar performance [1]. I'd guess
that this means it's probably a difference in the exit configuration
rather than geographic location, and since the faster relay was operated
by torservers.net I pointed the operator at their wiki which contains more
details about the server configuration (e.g., tcp stack tuning)[2]. Maybe
we can simulate circuits of varying latency and see how these tunables
affect results?
[1] https://lists.torproject.org/pipermail/tor-
relays/2012-October/001689.html
[2]
https://www.torservers.net/wiki/setup/server#high_bandwidth_tweaks_100_mbps
>
> We probably should figure out a way for the bandwidth authorities to
utilize per-node as well as ambient circuit failure (#7023, #7037).
>
> There's a bunch of related stuff for TCP socket exhaustion, too. All of
it probably involves some fairly diligent monitoring of results and
experimentation though.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7177#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs