[tor-bugs] #8683 [Tor]: moria1 isn't voting for Fast flag when it should

[Tor Bug Tracker & Wiki]

#8683: moria1 isn't voting for Fast flag when it should
----------------------+-----------------------------------------------------
 Reporter:  arma      |          Owner:                    
     Type:  defect    |         Status:  new               
 Priority:  blocker   |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor       |        Version:                    
 Keywords:  tor-auth  |         Parent:                    
   Points:            |   Actualpoints:                    
----------------------+-----------------------------------------------------

Comment(by nickm):

 Replying to [comment:7 arma]:
 > Replying to [comment:5 nickm]:
 > > I have some more or less untested stuff in branch bug8683_ideas.
 Needs review and consideration.
 >
 > Looks like we're changing the meaning of fast_bandwidth to be in
 kilobytes rather than bytes?

 We already did that as part of #8273; we just didn't do it consistently.

 I think the alternative is worse, but I could be wrong.

 > Unexpected side effects:
 >
 > - The FastFlagMinThreshold consensus param will cause current clients to
 freak out if you set it to 4 but the clients think 4096 is the minimum.

 Not really; were' changing the minimum to 4, after all, and I think
 clients don't even look at that value.  The worst that will happen is that
 authorities that don't upgrade will give a warning.  But authorities
 should upgrade.  Or we could say that these thresholds are in bytes, and
 divide them by 1000.   That's cool too.

 > - It changes dirserv_get_flag_thresholds_line(), so Karsten's scripts to
 track thresholds will all need to check what version generated the line
 and handle it there.

 For that, adding the appropriate multiplies sounds like the right thing to
 do.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8683#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online