[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #20403 [Metrics]: Make it easier for relay operators to find their observed bandwidth
#20403: Make it easier for relay operators to find their observed bandwidth
-------------------------+---------------------
Reporter: teor | Owner:
Type: enhancement | Status: new
Priority: Medium | Milestone:
Component: Metrics | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------+---------------------
Comment (by teor):
Replying to [comment:1 tom]:
> So depictor (consensus-health) uses stem to get its info, so it's really
easy for me to include any information here:
https://stem.torproject.org/api/descriptor/router_status_entry.html It's
really difficult to get anything else - downloading descriptors for the
network would take a _lot_ of time, just downloading the votes and
consesnsuses takes 10+ minutes.
I think I might be asking for the "bandwidth (int) -- bandwidth claimed by
the relay (in kb/s)", but I am not sure how it is sourced.
> I'm a little confused by the terms you're using. When you say "observed
bandwidth" do you mean the relay's 'advertised bandwidth' a relay operator
puts in the config, the unit-less values the bwauths calculate and vote
on, or a third thing I'm not recalling? (And if it is the third thing,
where does that get exposed: Consensus, MicroConsensus, Descriptor,
Microdescriptor, or ExtraInfo?)
By "observed bandwdith" I mean the "bandwdith-observed" figure from the
descriptor "bandwdith" line:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n418
I'd like it more easily available because it's one of the two figures that
an operator doesn't set themselves - the other is the measured bandwidth.
And used in conjunction with the advertised bandwidth to calculate the
bandwidth in the consensus "w" line:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2268
(That figure is useful, but more confusing, because it's sometimes the
advertised bandwidth, and sometimes the observed bandwidth.)
> And then the same question for "consensus weight".
Whatever Atlas uses for consensus weight in the relay details page.
I assume it's measured bandwidth from the consensus w line, but I'm not
sure.
If it is, it's already there in the consensus column of the relay flags
table.
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2274
> Looking closer at the stem documentation, I might have done things wrong
in #20372 actually. Adding Damian to confirm the below is correct:
>
> - On a vote .measured is the bwauth's vote for the relay's (unitless)
bandwidth value
> - On a consensus .measured is the average* of the bwauths votes for the
relay's (unitless) bandwidth value
> - On a vote or consensus .bandwidth is the _relay's_ advertised
bandwidth (and is what teor wants available)
Not quite, I think it's the minimum of advertised and observed, which
confuses a lot of operators, because sometimes it's controlled by the
torrc, and other times by their relay's self-reported performance:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n418
> *not really average but let's pretend it is for simplicity
(low-median)
> (Currently, the value on each Authority is the .measured but the value
on the consensus is .bandwidth - which would be wrong as the consensus
would be reporting the self-reported advertised bandwidth...)
That's strange, because all the figures in the table appear to be a low-
median (consensus .measured) to me.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20403#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