#33871: Scale exactly as torflow does? -------------------------------------------------+------------------------- Reporter: juga | Owner: juga Type: defect | Status: | assigned Priority: Medium | Milestone: sbws: | 1.1.x-final Component: Core Tor/sbws | Version: Severity: Normal | Resolution: Keywords: sbws-majority-blocker, sbws-roadmap | Actual Points: Parent ID: #33775 | Points: Reviewer: | Sponsor: -------------------------------------------------+-------------------------
Comment (by mikeperry): Juga: Your analysis in `#1` is correct to my memory, and I agree probably not causing this issue. Re `#2` and `#3`: whats is the sbws torrc? TorFlow sets all the aggressive consensus and descriptor fetching options, so it may have descriptors *not* in the consensus, even. Or descriptors for relays oscillating in the consensus. Torflow *also* uses Tor 0.2.9, which may have different descriptor vs microdescriptor fetching behavior. If you are using microdescriptors, you might also not be getting fresh enough relay data, because those have to be generated by at least one consensus process. I think these are more likely culprits for this specific ticket. Here is the relevant torrc piece, which I think may behave differently with Tor 0.2.9: {{{ FetchUselessDescriptors 1 # Workaround for Tor #24110, tracked in TorFlow #24094 UseMicrodescriptors 0 __LeaveStreamsUnattached 1 # Bad idea? Too much consensus update activity? FetchDirInfoExtraEarly 1 FetchDirInfoEarly 1 }}} -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33871#comment:11> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs