Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #8419

Closed (moved)
(moved)
Open
Created Mar 06, 2013 by Mike Perry@mikeperry

Bw Weight Failure Warns

We're getting a few of these:

Mar 06 22:55:01.000 [notice] Computed bandwidth weights for Case 3be (E scarce, Wee=1, Wmd == Wgd) with v10: G=1972445 M=834651 E=962503 D=1236746 T=5006345

Mar 06 22:55:02.000 [warn] Bw Weight Failure for Case 3b: Etotal 1679546.562000 != Mtotal 1660246.975500. G=1968169 M=826231 E=970923 D=1241022 T=5006345. Wgg=0.711500 Wgd=0.214500 Wmg=0.288500 Wme=0.000000 Wmd=0.214500 Wee=1.000000 Wed=0.571000

Notice that the G, M, E, D flag total values all change between when we compute the weights (the notice) and when we spot-check the resulting consensus (the warn). The total bandwidth (the T value) interestingly did not change.. So it's almost like bandwidth just moved from one flag to another somehow, during the consensus process.

Are we changing our opinion on node flags somewhere in between these two calculations? Is that a result of the Fast flag changes, or the unmeasured capping? Are those both already in effect?

For an extra datapoint, this seemed to only start happening when the bw auths failed.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking