[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #25687 [Core Tor/Tor]: over-report of observed / self-measure bandwidth on fast hardware -- important to torflow / peerflow
#25687: over-report of observed / self-measure bandwidth on fast hardware --
important to torflow / peerflow
-------------------------------------------------+-------------------------
Reporter: starlight | Owner: (none)
Type: defect | Status: new
Priority: Medium | Milestone: Tor:
| unspecified
Component: Core Tor/Tor | Version: Tor:
| 0.2.6.10
Severity: Normal | Resolution:
Keywords: tor-bwauth, needs-research, needs- | Actual Points:
proposal? |
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Changes (by teor):
* keywords: tor-bwauth => tor-bwauth, needs-research, needs-proposal?
Comment:
Replying to [comment:11 juga]:
> Replying to [comment:10 starlight]:
> > The concern of this ticket is with regard to the observed value
published by the daemon rather than the Torflow calculated vote resulting
from it.
> …
> > of the measured bandwidth for a relay to the average of all measured
bandwidths in a manner short on nuance. Wrote about possible ways to
address that here:
> >
> > https://github.com/torproject/sbws/issues/182#issuecomment-410745893
>
> sorry, i found that comment hard to read
I found it hard to read, too.
If we can't understand what you want, it's hard to know what we can do to
improve tor.
In tickets or comments, short, specific suggestions are most helpful.
For substantial changes, please follow the proposal process:
https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt
For substantial analysis, let's work on questions to ask researchers or
metrics.
Many short questions are best, rather than large blocks of text.
> FWIW, we're continuing that ticket in multiple others. Follow the links
of https://trac.torproject.org/projects/tor/ticket/27107
In particular, see #27739 for our draft policy for resolving differences
between sbws and torflow for sbws 1.0:
> If a sbws deployment is within X% of an existing bandwidth authority,
sbws is ok. (The total consensus weights of the existing bandwidth
authorities are within 50% of each other, see #25459.)
In later releases, we may modify sbws to achieve better network load-
balancing.
We talked about choosing an ideal distribution, but that might not be the
best idea.
Instead, see Mike Perry's email:
> as you make
choices about how to load balance, please have a specific goal as to
what target load balancing equilibrium point you're actually going for.
> we should definitely watch the change
in our average and quartile variance performance metrics when we first
switch to sbws.
https://lists.torproject.org/pipermail/tor-dev/2018-August/013419.html
We'll have a better idea how to achieve this goal after more network
measurements and research.
> > Have considered opening a Trac ticket encompassing the ideas, but am
waiting for an opportune moment at a point where serious comparison work
is evident.
Perhaps a proposal and a ticket would be best?
> on what you would like to have a serious comparison?
I'm not sure what sort of comparisons we'll be doing. Mike's email has
some options.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25687#comment:12>
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