Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • S sbws
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 9
    • Issues 9
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 2
    • Merge requests 2
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Network Health
  • sbws
  • Issues
  • #40115

Closed
Open
Created Jan 10, 2022 by juga@jugaMaintainer

Change log about the consensus weight sum difference

As @sebastian reported by IRC, sbws logs Dec 22 21:41:13 v3bwfile[283101]: <WARNING> (MainThread) It is more than 50%.

That line doesn't make sense without the previous info one The difference between the sum of the last consensus weight [...].

We should either explain the warning line what's the 50% about or lower the log level of that line to info.

Lowering the log level to info will generate less email notifications when configuring them as in #40110 (closed).

A different issue is whether it is acceptable that gabelmoo's consensus weight sum is more than the 50% of the consensus. We added the warning in #28216 (closed) while working on #27339 (closed).

It looks like gabelmoo's had always greatest consensus weight sum (see for instance the total consensus weight graph back in 2018 when the log was created: https://metrics.torproject.org/totalcw.png?start=2018-10-01&end=2018-10-31), what it probably due gabelmoo's location (Germany). What i'm not sure is whether it was as much as the 50% before because relays were getting stuck in bandwidth partitions with torflow or we just didn't notice cause torflow wasn't logging that.

@sebastian reported that this warning is gone the 02 Jan 2022, so i'd suggest that we keep the warning for now, explaining what the 50% is about and open a different issue to track how often the 50% difference is reached and whether that's a sbws bug.

What do you think, @gk?

Assignee
Assign to
Time tracking