Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #11327

Closed (moved)
Open
Opened Mar 26, 2014 by Roger Dingledine@arma

Dir auths should choose Fast and Guard flags by consensus weight if they don't measure

In #8435 (moved) we made directory-authorities-that-run-bwauths stop voting Fast or Guard for relays they hadn't measured yet.

But as I pointed out in https://trac.torproject.org/projects/tor/ticket/8435#comment:13, since only a minority of dir auths run bwauths, the majority of dir auths are still voting Fast and Guard based on descriptor bandwidths.

So while the title of ticket #8435 (moved) says "Ignore advertised bandwidths for flags once we have enough measured bandwidths", the ChangeLog entry is more accurate:

    - Directory authorities that have more than a threshold number
      of relays with measured bandwidths now treat relays with unmeasured
      bandwidths as having bandwidth 0. Resolves ticket 8435.

We should at some point actually do the original goal, which is to give Fast to the 7/8s of relays whose consensus weights are highest, and Guard to the 1/2 of relays whose consensus weights are highest and who match the other guard constraints.

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#11327