Skip to content
Snippets Groups Projects

Simplify adjustment of consensus speed in testing tor networks

    • Closed (moved) Issue created by teor @teor

    In order to adjust the consensus speed in a tor network, we need to configure at least 12 torrc options across authorities, relays, and clients. These options have complex timing interrelationships.

    rl1987 suggested that we add a single "make it faster by X times" parameter that modifies all of these at once.

    If I were using chutney, I would prefer a parameter that changes the length of the consensus cycle to a specified number of seconds. (What does 0.1x mean? And reaching the minimums would require fractions like 0.0028.) But the basic idea is still the same.

    I believe the options we would need to modify are:

    = Option = = Minimum = = Testing = = Default = = Suggested = = Constraints =
    V3AuthVotingInterval 10 (after #13718 (moved)) 300 3600 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default Must be strictly more than twice (V3AuthVoteDelay + V3AuthDistDelay)
    TestingV3AuthInitialVotingInterval 5 (after #13718 (moved)) 150 (after #13718 (moved)) 1800 V3AuthVotingInterval/2 Must be strictly more than (TestingV3AuthInitialVoteDelay + TestingV3AuthInitialDistDelay) (after #13718 (moved), otherwise twice that)
    V3AuthVoteDelay 2 20 300 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default V3AuthVotingInterval See Above
    TestingV3AuthInitialVoteDelay 2 20 300 V3AuthVoteDelay See Above
    V3AuthDistDelay 2 20 300 V3AuthVoteDelay See Above
    TestingV3AuthInitialDistDelay 2 20 300 V3AuthDistDelay See Above
    TestingClientMaxIntervalWithoutRequest 1 5 600 Quadratic Scaling Between Minimum and Default based on (TestingOverallConsensusInterval^2)/(Default^2) None
    TestingServerDownloadSchedule 0 0, 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 0, 60, 60, 120, 300, 900, 2147483647 0, V3AuthVotingInterval/4 None
    TestingClientDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 2147483647 TestingServerDownloadSchedule None
    TestingBridgeDownloadSchedule 0 60, 30, 30, 60 3600, 900, 900, 3600 TestingServerDownloadSchedule None
    TestingServerConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 1800, 1800, 1800, 1800, 3600, 7200 TestingServerDownloadSchedule None
    TestingClientConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 3600, 3600, 3600, 10800, 21600, 43200 TestingServerConsensusDownloadSchedule None

    If we yield the default times when TestingOverallConsensusInterval 3600, then some typical values would be:

    = Option = = Minimum = = Testing = = Turbo (2x) = = Default =
    TestingOverallConsensusInterval 10 300 1800 3600
    Scaled V3AuthVotingInterval 10 ((300-10) * (3600-10) / (3600-10)) + 10 = 300 ((1800-10) * (3600-10) / (3600-10)) + 10 = 1800 ((3600-10) * (3600-10) / (3600-10)) + 10 = 3600
    Comparable V3AuthVotingInterval 10 300 N/A 3600
    Scaled V3AuthVoteDelay 2 ((300-2) * (300-10) / (3600-10)) + 2 = 26 ((300-2) * (1800-10) / (3600-10)) + 2 = 150 ((300-2) * (3600-10) / (3600-10)) + 2 = 300
    Comparable V3AuthVoteDelay 2 20 N/A 300
    Scaled TestingClientMaxIntervalWithoutRequest 1 ((600-1) * (300-10)^2 / (3600-10)^2) + 1 = 5 ((600-1) * (1800-10)^2 / (3600-10)^2) + 1 = 150 ((600-1) * (3600-10)^2 / (3600-10)^2) + 1 = 600
    Comparable TestingClientMaxIntervalWithoutRequest 1 5 N/A 600

    These look good, although we'd also need to make sure that any scaling didn't drop the values below the absolute minimums. This should probably be clipped automatically, so TestingOverallConsensusInterval 0 makes sense as "go as fast as you can".

    <rl1987> my idea: what about having a configurable parameter that makes consensus happen faster by, say, 100 times?
<teor> rl1987: you mean, V3AuthVotingInterval, TestingV3AuthInitialVotingInterval, TestingV3AuthInitialVoteDelay, V3AuthVoteDelay, TestingV3AuthInitialDistDelay, V3AuthDistDelay, TestingServerDownloadSchedule
<teor> Unfortunately, the behaviour is a little too complex to just say, "make it very very fast"
<teor> I've basically reduced those parameters to their minimums, and patched tor when that didn't work as I thought it should
<rl1987> I meant "make it faster by X times"
<rl1987> if the entire lifecycle takes 6 hours, maybe we can have a parameter that forces it to take 6 hours / X
<rl1987> not sure how feasible is that.
<teor> Hmm, I think we'd be dividing too many things by that number
<rl1987> would it cause any trouble, if they were getting proportionally smaller?
<teor> Hmm, there's some things that have minimum times, and I've already set them to that to get it to work in under a minute
<teor> Perhaps we could scale up between that and the default hour-long interval
<teor> i.e. the minimum consensus time is 10 seconds, the default is 3600 seconds, let's have a parameter that scales up proportionally
<teor> or, the minimum voting and distribution delays are 2 seconds, the defaults are 300 seconds, ...
<teor> I'm not sure how to handle TestingServerDownloadSchedule and TestingClientDownloadSchedule
<teor> They look like: TestingServerDownloadSchedule 10, 2, 2, 5
<teor> Perhaps we define that as: <consensus interval>, <vote interval>, <dist interval>, <consensus interval>/2
<teor> Sure. I will log a lorax on your last suggestion
<rl1987> nice.
<rl1987> not sure if the idea is very useful, though.
<rl1987> but I would like it to be considered.
<teor> Sure is a lot nicer than having to set 6-8 separate parameters
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • teor changed milestone to %Tor: unspecified

      changed milestone to %Tor: unspecified

    • teor added chutney component::core tor/tor lorax milestone::Tor: unspecified priority::medium robustness severity::normal status::new testing tor-relay type::defect version::tor unspecified labels

      added chutney component::core tor/tor lorax milestone::Tor: unspecified priority::medium robustness severity::normal status::new testing tor-relay type::defect version::tor unspecified labels

    • T
      teor @teor ·
      Author

      Fix table header formatting

      Trac:
      Description: In order to adjust the consensus speed in a tor network, we need to configure at least 8 torrc options across authorities, relays, and clients. These options have complex timing interrelationships.

      rl1987 suggested that we add a single "make it faster by X times" parameter that modifies all of these at once.

      If I were using chutney, I would prefer a parameter that changes the length of the consensus cycle to a specified number of seconds. (What does 0.1x mean? And reaching the minimums would require fractions like 0.0028.) But the basic idea is still the same.

      I believe the options we would need to modify are:

      = Option Minimum Testing Default Suggested Constraints =
      V3AuthVotingInterval 10 (after #13718 (moved)) 300 3600 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default Must be strictly more than twice (V3AuthVoteDelay + V3AuthDistDelay)
      TestingV3AuthInitialVotingInterval 5 (after #13718 (moved)) 150 (after #13718 (moved)) 1800 V3AuthVotingInterval/2 Must be strictly more than (TestingV3AuthInitialVoteDelay + TestingV3AuthInitialDistDelay) (after #13718 (moved), otherwise twice that)
      V3AuthVoteDelay 2 20 300 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default V3AuthVotingInterval See Above
      TestingV3AuthInitialVoteDelay 2 20 300 V3AuthVoteDelay See Above
      V3AuthDistDelay 2 20 300 V3AuthVoteDelay See Above
      TestingV3AuthInitialDistDelay 2 20 300 V3AuthDistDelay See Above
      TestingServerDownloadSchedule 0 0, 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 0, 60, 60, 120, 300, 900, 2147483647 TestingV3AuthInitialVotingInterval, 1, 1, TestingV3AuthInitialVoteDelay, TestingV3AuthInitialDistDelay, V3AuthVotingInterval/2 None
      TestingClientDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 2147483647 TestingServerDownloadSchedule None
      TestingBridgeDownloadSchedule 0 60, 30, 30, 60 3600, 900, 900, 3600 TestingServerDownloadSchedule None
      TestingServerConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 1800, 1800, 1800, 1800, 3600, 7200 0, 0, TestingV3AuthInitialVotingInterval, V3AuthVotingInterval/2 None
      TestingClientConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 3600, 3600, 3600, 10800, 21600, 43200 TestingServerConsensusDownloadSchedule None

      If we yield the default times when TestingOverallConsensusInterval 3600, then some typical values would be:

      = Option Minimum Testing Turbo (2x) Default =
      TestingOverallConsensusInterval 10 300 1800 3600
      Scaled V3AuthVotingInterval 10 ((300-10) * (3600-10) / (3600-10)) + 10 = 300 ((1800-10) * (3600-10) / (3600-10)) + 10 = 1800 ((3600-10) * (3600-10) / (3600-10)) + 10 = 3600
      Comparable V3AuthVotingInterval 10 300 N/A 3600
      Scaled V3AuthVoteDelay 2 ((300-2) * (300-10) / (3600-10)) + 2 = 26 ((300-2) * (1800-10) / (3600-10)) + 2 = 150 ((300-2) * (3600-10) / (3600-10)) + 2 = 300
      Comparable V3AuthVoteDelay 2 20 N/A 300

      These look good, although we'd also need to make sure that any scaling didn't drop the values below the absolute minimums. This should probably be clipped automatically, so TestingOverallConsensusInterval 0 makes sense as "go as fast as you can".

      <rl1987> my idea: what about having a configurable parameter that makes consensus happen faster by, say, 100 times?
<teor> rl1987: you mean, V3AuthVotingInterval, TestingV3AuthInitialVotingInterval, TestingV3AuthInitialVoteDelay, V3AuthVoteDelay, TestingV3AuthInitialDistDelay, V3AuthDistDelay, TestingServerDownloadSchedule
<teor> Unfortunately, the behaviour is a little too complex to just say, "make it very very fast"
<teor> I've basically reduced those parameters to their minimums, and patched tor when that didn't work as I thought it should
<rl1987> I meant "make it faster by X times"
<rl1987> if the entire lifecycle takes 6 hours, maybe we can have a parameter that forces it to take 6 hours / X
<rl1987> not sure how feasible is that.
<teor> Hmm, I think we'd be dividing too many things by that number
<rl1987> would it cause any trouble, if they were getting proportionally smaller?
<teor> Hmm, there's some things that have minimum times, and I've already set them to that to get it to work in under a minute
<teor> Perhaps we could scale up between that and the default hour-long interval
<teor> i.e. the minimum consensus time is 10 seconds, the default is 3600 seconds, let's have a parameter that scales up proportionally
<teor> or, the minimum voting and distribution delays are 2 seconds, the defaults are 300 seconds, ...
<teor> I'm not sure how to handle TestingServerDownloadSchedule and TestingClientDownloadSchedule
<teor> They look like: TestingServerDownloadSchedule 10, 2, 2, 5
<teor> Perhaps we define that as: <consensus interval>, <vote interval>, <dist interval>, <consensus interval>/2
<teor> Sure. I will log a lorax on your last suggestion
<rl1987> nice.
<rl1987> not sure if the idea is very useful, though.
<rl1987> but I would like it to be considered.
<teor> Sure is a lot nicer than having to set 6-8 separate parameters

      to

      In order to adjust the consensus speed in a tor network, we need to configure at least 8 torrc options across authorities, relays, and clients. These options have complex timing interrelationships.

      rl1987 suggested that we add a single "make it faster by X times" parameter that modifies all of these at once.

      If I were using chutney, I would prefer a parameter that changes the length of the consensus cycle to a specified number of seconds. (What does 0.1x mean? And reaching the minimums would require fractions like 0.0028.) But the basic idea is still the same.

      I believe the options we would need to modify are:

      = Option = = Minimum = = Testing = Default = = Suggested = = Constraints =
      V3AuthVotingInterval 10 (after #13718 (moved)) 300 3600 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default Must be strictly more than twice (V3AuthVoteDelay + V3AuthDistDelay)
      TestingV3AuthInitialVotingInterval 5 (after #13718 (moved)) 150 (after #13718 (moved)) 1800 V3AuthVotingInterval/2 Must be strictly more than (TestingV3AuthInitialVoteDelay + TestingV3AuthInitialDistDelay) (after #13718 (moved), otherwise twice that)
      V3AuthVoteDelay 2 20 300 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default V3AuthVotingInterval See Above
      TestingV3AuthInitialVoteDelay 2 20 300 V3AuthVoteDelay See Above
      V3AuthDistDelay 2 20 300 V3AuthVoteDelay See Above
      TestingV3AuthInitialDistDelay 2 20 300 V3AuthDistDelay See Above
      TestingServerDownloadSchedule 0 0, 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 0, 60, 60, 120, 300, 900, 2147483647 TestingV3AuthInitialVotingInterval, 1, 1, TestingV3AuthInitialVoteDelay, TestingV3AuthInitialDistDelay, V3AuthVotingInterval/2 None
      TestingClientDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 2147483647 TestingServerDownloadSchedule None
      TestingBridgeDownloadSchedule 0 60, 30, 30, 60 3600, 900, 900, 3600 TestingServerDownloadSchedule None
      TestingServerConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 1800, 1800, 1800, 1800, 3600, 7200 0, 0, TestingV3AuthInitialVotingInterval, V3AuthVotingInterval/2 None
      TestingClientConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 3600, 3600, 3600, 10800, 21600, 43200 TestingServerConsensusDownloadSchedule None

      If we yield the default times when TestingOverallConsensusInterval 3600, then some typical values would be:

      = Option = = Minimum = = Testing = = Turbo (2x) = = Default =
      TestingOverallConsensusInterval 10 300 1800 3600
      Scaled V3AuthVotingInterval 10 ((300-10) * (3600-10) / (3600-10)) + 10 = 300 ((1800-10) * (3600-10) / (3600-10)) + 10 = 1800 ((3600-10) * (3600-10) / (3600-10)) + 10 = 3600
      Comparable V3AuthVotingInterval 10 300 N/A 3600
      Scaled V3AuthVoteDelay 2 ((300-2) * (300-10) / (3600-10)) + 2 = 26 ((300-2) * (1800-10) / (3600-10)) + 2 = 150 ((300-2) * (3600-10) / (3600-10)) + 2 = 300
      Comparable V3AuthVoteDelay 2 20 N/A 300

      These look good, although we'd also need to make sure that any scaling didn't drop the values below the absolute minimums. This should probably be clipped automatically, so TestingOverallConsensusInterval 0 makes sense as "go as fast as you can".

      <rl1987> my idea: what about having a configurable parameter that makes consensus happen faster by, say, 100 times?
<teor> rl1987: you mean, V3AuthVotingInterval, TestingV3AuthInitialVotingInterval, TestingV3AuthInitialVoteDelay, V3AuthVoteDelay, TestingV3AuthInitialDistDelay, V3AuthDistDelay, TestingServerDownloadSchedule
<teor> Unfortunately, the behaviour is a little too complex to just say, "make it very very fast"
<teor> I've basically reduced those parameters to their minimums, and patched tor when that didn't work as I thought it should
<rl1987> I meant "make it faster by X times"
<rl1987> if the entire lifecycle takes 6 hours, maybe we can have a parameter that forces it to take 6 hours / X
<rl1987> not sure how feasible is that.
<teor> Hmm, I think we'd be dividing too many things by that number
<rl1987> would it cause any trouble, if they were getting proportionally smaller?
<teor> Hmm, there's some things that have minimum times, and I've already set them to that to get it to work in under a minute
<teor> Perhaps we could scale up between that and the default hour-long interval
<teor> i.e. the minimum consensus time is 10 seconds, the default is 3600 seconds, let's have a parameter that scales up proportionally
<teor> or, the minimum voting and distribution delays are 2 seconds, the defaults are 300 seconds, ...
<teor> I'm not sure how to handle TestingServerDownloadSchedule and TestingClientDownloadSchedule
<teor> They look like: TestingServerDownloadSchedule 10, 2, 2, 5
<teor> Perhaps we define that as: <consensus interval>, <vote interval>, <dist interval>, <consensus interval>/2
<teor> Sure. I will log a lorax on your last suggestion
<rl1987> nice.
<rl1987> not sure if the idea is very useful, though.
<rl1987> but I would like it to be considered.
<teor> Sure is a lot nicer than having to set 6-8 separate parameters
    • T
      teor @teor ·
      Author

      Well, that's hard to get right, as it doesn't look much different in the preview.

      Trac:
      Description: In order to adjust the consensus speed in a tor network, we need to configure at least 8 torrc options across authorities, relays, and clients. These options have complex timing interrelationships.

      rl1987 suggested that we add a single "make it faster by X times" parameter that modifies all of these at once.

      If I were using chutney, I would prefer a parameter that changes the length of the consensus cycle to a specified number of seconds. (What does 0.1x mean? And reaching the minimums would require fractions like 0.0028.) But the basic idea is still the same.

      I believe the options we would need to modify are:

      = Option = = Minimum = = Testing = Default = = Suggested = = Constraints =
      V3AuthVotingInterval 10 (after #13718 (moved)) 300 3600 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default Must be strictly more than twice (V3AuthVoteDelay + V3AuthDistDelay)
      TestingV3AuthInitialVotingInterval 5 (after #13718 (moved)) 150 (after #13718 (moved)) 1800 V3AuthVotingInterval/2 Must be strictly more than (TestingV3AuthInitialVoteDelay + TestingV3AuthInitialDistDelay) (after #13718 (moved), otherwise twice that)
      V3AuthVoteDelay 2 20 300 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default V3AuthVotingInterval See Above
      TestingV3AuthInitialVoteDelay 2 20 300 V3AuthVoteDelay See Above
      V3AuthDistDelay 2 20 300 V3AuthVoteDelay See Above
      TestingV3AuthInitialDistDelay 2 20 300 V3AuthDistDelay See Above
      TestingServerDownloadSchedule 0 0, 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 0, 60, 60, 120, 300, 900, 2147483647 TestingV3AuthInitialVotingInterval, 1, 1, TestingV3AuthInitialVoteDelay, TestingV3AuthInitialDistDelay, V3AuthVotingInterval/2 None
      TestingClientDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 2147483647 TestingServerDownloadSchedule None
      TestingBridgeDownloadSchedule 0 60, 30, 30, 60 3600, 900, 900, 3600 TestingServerDownloadSchedule None
      TestingServerConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 1800, 1800, 1800, 1800, 3600, 7200 0, 0, TestingV3AuthInitialVotingInterval, V3AuthVotingInterval/2 None
      TestingClientConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 3600, 3600, 3600, 10800, 21600, 43200 TestingServerConsensusDownloadSchedule None

      If we yield the default times when TestingOverallConsensusInterval 3600, then some typical values would be:

      = Option = = Minimum = = Testing = = Turbo (2x) = = Default =
      TestingOverallConsensusInterval 10 300 1800 3600
      Scaled V3AuthVotingInterval 10 ((300-10) * (3600-10) / (3600-10)) + 10 = 300 ((1800-10) * (3600-10) / (3600-10)) + 10 = 1800 ((3600-10) * (3600-10) / (3600-10)) + 10 = 3600
      Comparable V3AuthVotingInterval 10 300 N/A 3600
      Scaled V3AuthVoteDelay 2 ((300-2) * (300-10) / (3600-10)) + 2 = 26 ((300-2) * (1800-10) / (3600-10)) + 2 = 150 ((300-2) * (3600-10) / (3600-10)) + 2 = 300
      Comparable V3AuthVoteDelay 2 20 N/A 300

      These look good, although we'd also need to make sure that any scaling didn't drop the values below the absolute minimums. This should probably be clipped automatically, so TestingOverallConsensusInterval 0 makes sense as "go as fast as you can".

      <rl1987> my idea: what about having a configurable parameter that makes consensus happen faster by, say, 100 times?
<teor> rl1987: you mean, V3AuthVotingInterval, TestingV3AuthInitialVotingInterval, TestingV3AuthInitialVoteDelay, V3AuthVoteDelay, TestingV3AuthInitialDistDelay, V3AuthDistDelay, TestingServerDownloadSchedule
<teor> Unfortunately, the behaviour is a little too complex to just say, "make it very very fast"
<teor> I've basically reduced those parameters to their minimums, and patched tor when that didn't work as I thought it should
<rl1987> I meant "make it faster by X times"
<rl1987> if the entire lifecycle takes 6 hours, maybe we can have a parameter that forces it to take 6 hours / X
<rl1987> not sure how feasible is that.
<teor> Hmm, I think we'd be dividing too many things by that number
<rl1987> would it cause any trouble, if they were getting proportionally smaller?
<teor> Hmm, there's some things that have minimum times, and I've already set them to that to get it to work in under a minute
<teor> Perhaps we could scale up between that and the default hour-long interval
<teor> i.e. the minimum consensus time is 10 seconds, the default is 3600 seconds, let's have a parameter that scales up proportionally
<teor> or, the minimum voting and distribution delays are 2 seconds, the defaults are 300 seconds, ...
<teor> I'm not sure how to handle TestingServerDownloadSchedule and TestingClientDownloadSchedule
<teor> They look like: TestingServerDownloadSchedule 10, 2, 2, 5
<teor> Perhaps we define that as: <consensus interval>, <vote interval>, <dist interval>, <consensus interval>/2
<teor> Sure. I will log a lorax on your last suggestion
<rl1987> nice.
<rl1987> not sure if the idea is very useful, though.
<rl1987> but I would like it to be considered.
<teor> Sure is a lot nicer than having to set 6-8 separate parameters

      to

      In order to adjust the consensus speed in a tor network, we need to configure at least 8 torrc options across authorities, relays, and clients. These options have complex timing interrelationships.

      rl1987 suggested that we add a single "make it faster by X times" parameter that modifies all of these at once.

      If I were using chutney, I would prefer a parameter that changes the length of the consensus cycle to a specified number of seconds. (What does 0.1x mean? And reaching the minimums would require fractions like 0.0028.) But the basic idea is still the same.

      I believe the options we would need to modify are:

      = Option = = Minimum = = Testing = = Default = = Suggested = = Constraints =
      V3AuthVotingInterval 10 (after #13718 (moved)) 300 3600 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default Must be strictly more than twice (V3AuthVoteDelay + V3AuthDistDelay)
      TestingV3AuthInitialVotingInterval 5 (after #13718 (moved)) 150 (after #13718 (moved)) 1800 V3AuthVotingInterval/2 Must be strictly more than (TestingV3AuthInitialVoteDelay + TestingV3AuthInitialDistDelay) (after #13718 (moved), otherwise twice that)
      V3AuthVoteDelay 2 20 300 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default V3AuthVotingInterval See Above
      TestingV3AuthInitialVoteDelay 2 20 300 V3AuthVoteDelay See Above
      V3AuthDistDelay 2 20 300 V3AuthVoteDelay See Above
      TestingV3AuthInitialDistDelay 2 20 300 V3AuthDistDelay See Above
      TestingServerDownloadSchedule 0 0, 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 0, 60, 60, 120, 300, 900, 2147483647 TestingV3AuthInitialVotingInterval, 1, 1, TestingV3AuthInitialVoteDelay, TestingV3AuthInitialDistDelay, V3AuthVotingInterval/2 None
      TestingClientDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 2147483647 TestingServerDownloadSchedule None
      TestingBridgeDownloadSchedule 0 60, 30, 30, 60 3600, 900, 900, 3600 TestingServerDownloadSchedule None
      TestingServerConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 1800, 1800, 1800, 1800, 3600, 7200 0, 0, TestingV3AuthInitialVotingInterval, V3AuthVotingInterval/2 None
      TestingClientConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 3600, 3600, 3600, 10800, 21600, 43200 TestingServerConsensusDownloadSchedule None

      If we yield the default times when TestingOverallConsensusInterval 3600, then some typical values would be:

      = Option = = Minimum = = Testing = = Turbo (2x) = = Default =
      TestingOverallConsensusInterval 10 300 1800 3600
      Scaled V3AuthVotingInterval 10 ((300-10) * (3600-10) / (3600-10)) + 10 = 300 ((1800-10) * (3600-10) / (3600-10)) + 10 = 1800 ((3600-10) * (3600-10) / (3600-10)) + 10 = 3600
      Comparable V3AuthVotingInterval 10 300 N/A 3600
      Scaled V3AuthVoteDelay 2 ((300-2) * (300-10) / (3600-10)) + 2 = 26 ((300-2) * (1800-10) / (3600-10)) + 2 = 150 ((300-2) * (3600-10) / (3600-10)) + 2 = 300
      Comparable V3AuthVoteDelay 2 20 N/A 300

      These look good, although we'd also need to make sure that any scaling didn't drop the values below the absolute minimums. This should probably be clipped automatically, so TestingOverallConsensusInterval 0 makes sense as "go as fast as you can".

      <rl1987> my idea: what about having a configurable parameter that makes consensus happen faster by, say, 100 times?
<teor> rl1987: you mean, V3AuthVotingInterval, TestingV3AuthInitialVotingInterval, TestingV3AuthInitialVoteDelay, V3AuthVoteDelay, TestingV3AuthInitialDistDelay, V3AuthDistDelay, TestingServerDownloadSchedule
<teor> Unfortunately, the behaviour is a little too complex to just say, "make it very very fast"
<teor> I've basically reduced those parameters to their minimums, and patched tor when that didn't work as I thought it should
<rl1987> I meant "make it faster by X times"
<rl1987> if the entire lifecycle takes 6 hours, maybe we can have a parameter that forces it to take 6 hours / X
<rl1987> not sure how feasible is that.
<teor> Hmm, I think we'd be dividing too many things by that number
<rl1987> would it cause any trouble, if they were getting proportionally smaller?
<teor> Hmm, there's some things that have minimum times, and I've already set them to that to get it to work in under a minute
<teor> Perhaps we could scale up between that and the default hour-long interval
<teor> i.e. the minimum consensus time is 10 seconds, the default is 3600 seconds, let's have a parameter that scales up proportionally
<teor> or, the minimum voting and distribution delays are 2 seconds, the defaults are 300 seconds, ...
<teor> I'm not sure how to handle TestingServerDownloadSchedule and TestingClientDownloadSchedule
<teor> They look like: TestingServerDownloadSchedule 10, 2, 2, 5
<teor> Perhaps we define that as: <consensus interval>, <vote interval>, <dist interval>, <consensus interval>/2
<teor> Sure. I will log a lorax on your last suggestion
<rl1987> nice.
<rl1987> not sure if the idea is very useful, though.
<rl1987> but I would like it to be considered.
<teor> Sure is a lot nicer than having to set 6-8 separate parameters
    • T
      teor @teor ·
      Author

      This would be a great contribution to fixing #13823 (moved) in a single option.

      The changes in #13929 (moved) and #13963 (moved) means we don't need to configure anything special for authority reachability testing and client/relay consensus caching, respectively.

    • T
      teor @teor ·
      Author

      Simplify TestingServerDownloadSchedule and TestingServerConsensusDownloadSchedule and dependencies. 0, V3AuthVotingInterval/2 seems to work fine, so why overcomplicate things?

      Trac:
      Description: In order to adjust the consensus speed in a tor network, we need to configure at least 8 torrc options across authorities, relays, and clients. These options have complex timing interrelationships.

      rl1987 suggested that we add a single "make it faster by X times" parameter that modifies all of these at once.

      If I were using chutney, I would prefer a parameter that changes the length of the consensus cycle to a specified number of seconds. (What does 0.1x mean? And reaching the minimums would require fractions like 0.0028.) But the basic idea is still the same.

      I believe the options we would need to modify are:

      = Option = = Minimum = = Testing = = Default = = Suggested = = Constraints =
      V3AuthVotingInterval 10 (after #13718 (moved)) 300 3600 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default Must be strictly more than twice (V3AuthVoteDelay + V3AuthDistDelay)
      TestingV3AuthInitialVotingInterval 5 (after #13718 (moved)) 150 (after #13718 (moved)) 1800 V3AuthVotingInterval/2 Must be strictly more than (TestingV3AuthInitialVoteDelay + TestingV3AuthInitialDistDelay) (after #13718 (moved), otherwise twice that)
      V3AuthVoteDelay 2 20 300 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default V3AuthVotingInterval See Above
      TestingV3AuthInitialVoteDelay 2 20 300 V3AuthVoteDelay See Above
      V3AuthDistDelay 2 20 300 V3AuthVoteDelay See Above
      TestingV3AuthInitialDistDelay 2 20 300 V3AuthDistDelay See Above
      TestingServerDownloadSchedule 0 0, 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 0, 60, 60, 120, 300, 900, 2147483647 TestingV3AuthInitialVotingInterval, 1, 1, TestingV3AuthInitialVoteDelay, TestingV3AuthInitialDistDelay, V3AuthVotingInterval/2 None
      TestingClientDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 2147483647 TestingServerDownloadSchedule None
      TestingBridgeDownloadSchedule 0 60, 30, 30, 60 3600, 900, 900, 3600 TestingServerDownloadSchedule None
      TestingServerConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 1800, 1800, 1800, 1800, 3600, 7200 0, 0, TestingV3AuthInitialVotingInterval, V3AuthVotingInterval/2 None
      TestingClientConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 3600, 3600, 3600, 10800, 21600, 43200 TestingServerConsensusDownloadSchedule None

      If we yield the default times when TestingOverallConsensusInterval 3600, then some typical values would be:

      = Option = = Minimum = = Testing = = Turbo (2x) = = Default =
      TestingOverallConsensusInterval 10 300 1800 3600
      Scaled V3AuthVotingInterval 10 ((300-10) * (3600-10) / (3600-10)) + 10 = 300 ((1800-10) * (3600-10) / (3600-10)) + 10 = 1800 ((3600-10) * (3600-10) / (3600-10)) + 10 = 3600
      Comparable V3AuthVotingInterval 10 300 N/A 3600
      Scaled V3AuthVoteDelay 2 ((300-2) * (300-10) / (3600-10)) + 2 = 26 ((300-2) * (1800-10) / (3600-10)) + 2 = 150 ((300-2) * (3600-10) / (3600-10)) + 2 = 300
      Comparable V3AuthVoteDelay 2 20 N/A 300

      These look good, although we'd also need to make sure that any scaling didn't drop the values below the absolute minimums. This should probably be clipped automatically, so TestingOverallConsensusInterval 0 makes sense as "go as fast as you can".

      <rl1987> my idea: what about having a configurable parameter that makes consensus happen faster by, say, 100 times?
<teor> rl1987: you mean, V3AuthVotingInterval, TestingV3AuthInitialVotingInterval, TestingV3AuthInitialVoteDelay, V3AuthVoteDelay, TestingV3AuthInitialDistDelay, V3AuthDistDelay, TestingServerDownloadSchedule
<teor> Unfortunately, the behaviour is a little too complex to just say, "make it very very fast"
<teor> I've basically reduced those parameters to their minimums, and patched tor when that didn't work as I thought it should
<rl1987> I meant "make it faster by X times"
<rl1987> if the entire lifecycle takes 6 hours, maybe we can have a parameter that forces it to take 6 hours / X
<rl1987> not sure how feasible is that.
<teor> Hmm, I think we'd be dividing too many things by that number
<rl1987> would it cause any trouble, if they were getting proportionally smaller?
<teor> Hmm, there's some things that have minimum times, and I've already set them to that to get it to work in under a minute
<teor> Perhaps we could scale up between that and the default hour-long interval
<teor> i.e. the minimum consensus time is 10 seconds, the default is 3600 seconds, let's have a parameter that scales up proportionally
<teor> or, the minimum voting and distribution delays are 2 seconds, the defaults are 300 seconds, ...
<teor> I'm not sure how to handle TestingServerDownloadSchedule and TestingClientDownloadSchedule
<teor> They look like: TestingServerDownloadSchedule 10, 2, 2, 5
<teor> Perhaps we define that as: <consensus interval>, <vote interval>, <dist interval>, <consensus interval>/2
<teor> Sure. I will log a lorax on your last suggestion
<rl1987> nice.
<rl1987> not sure if the idea is very useful, though.
<rl1987> but I would like it to be considered.
<teor> Sure is a lot nicer than having to set 6-8 separate parameters

      to

      In order to adjust the consensus speed in a tor network, we need to configure at least 8 torrc options across authorities, relays, and clients. These options have complex timing interrelationships.

      rl1987 suggested that we add a single "make it faster by X times" parameter that modifies all of these at once.

      If I were using chutney, I would prefer a parameter that changes the length of the consensus cycle to a specified number of seconds. (What does 0.1x mean? And reaching the minimums would require fractions like 0.0028.) But the basic idea is still the same.

      I believe the options we would need to modify are:

      = Option = = Minimum = = Testing = = Default = = Suggested = = Constraints =
      V3AuthVotingInterval 10 (after #13718 (moved)) 300 3600 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default Must be strictly more than twice (V3AuthVoteDelay + V3AuthDistDelay)
      TestingV3AuthInitialVotingInterval 5 (after #13718 (moved)) 150 (after #13718 (moved)) 1800 V3AuthVotingInterval/2 Must be strictly more than (TestingV3AuthInitialVoteDelay + TestingV3AuthInitialDistDelay) (after #13718 (moved), otherwise twice that)
      V3AuthVoteDelay 2 20 300 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default V3AuthVotingInterval See Above
      TestingV3AuthInitialVoteDelay 2 20 300 V3AuthVoteDelay See Above
      V3AuthDistDelay 2 20 300 V3AuthVoteDelay See Above
      TestingV3AuthInitialDistDelay 2 20 300 V3AuthDistDelay See Above
      TestingServerDownloadSchedule 0 0, 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 0, 60, 60, 120, 300, 900, 2147483647 0, V3AuthVotingInterval/2 None
      TestingClientDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 2147483647 TestingServerDownloadSchedule None
      TestingBridgeDownloadSchedule 0 60, 30, 30, 60 3600, 900, 900, 3600 TestingServerDownloadSchedule None
      TestingServerConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 1800, 1800, 1800, 1800, 3600, 7200 TestingServerDownloadSchedule None
      TestingClientConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 3600, 3600, 3600, 10800, 21600, 43200 TestingServerConsensusDownloadSchedule None

      If we yield the default times when TestingOverallConsensusInterval 3600, then some typical values would be:

      = Option = = Minimum = = Testing = = Turbo (2x) = = Default =
      TestingOverallConsensusInterval 10 300 1800 3600
      Scaled V3AuthVotingInterval 10 ((300-10) * (3600-10) / (3600-10)) + 10 = 300 ((1800-10) * (3600-10) / (3600-10)) + 10 = 1800 ((3600-10) * (3600-10) / (3600-10)) + 10 = 3600
      Comparable V3AuthVotingInterval 10 300 N/A 3600
      Scaled V3AuthVoteDelay 2 ((300-2) * (300-10) / (3600-10)) + 2 = 26 ((300-2) * (1800-10) / (3600-10)) + 2 = 150 ((300-2) * (3600-10) / (3600-10)) + 2 = 300
      Comparable V3AuthVoteDelay 2 20 N/A 300

      These look good, although we'd also need to make sure that any scaling didn't drop the values below the absolute minimums. This should probably be clipped automatically, so TestingOverallConsensusInterval 0 makes sense as "go as fast as you can".

      <rl1987> my idea: what about having a configurable parameter that makes consensus happen faster by, say, 100 times?
<teor> rl1987: you mean, V3AuthVotingInterval, TestingV3AuthInitialVotingInterval, TestingV3AuthInitialVoteDelay, V3AuthVoteDelay, TestingV3AuthInitialDistDelay, V3AuthDistDelay, TestingServerDownloadSchedule
<teor> Unfortunately, the behaviour is a little too complex to just say, "make it very very fast"
<teor> I've basically reduced those parameters to their minimums, and patched tor when that didn't work as I thought it should
<rl1987> I meant "make it faster by X times"
<rl1987> if the entire lifecycle takes 6 hours, maybe we can have a parameter that forces it to take 6 hours / X
<rl1987> not sure how feasible is that.
<teor> Hmm, I think we'd be dividing too many things by that number
<rl1987> would it cause any trouble, if they were getting proportionally smaller?
<teor> Hmm, there's some things that have minimum times, and I've already set them to that to get it to work in under a minute
<teor> Perhaps we could scale up between that and the default hour-long interval
<teor> i.e. the minimum consensus time is 10 seconds, the default is 3600 seconds, let's have a parameter that scales up proportionally
<teor> or, the minimum voting and distribution delays are 2 seconds, the defaults are 300 seconds, ...
<teor> I'm not sure how to handle TestingServerDownloadSchedule and TestingClientDownloadSchedule
<teor> They look like: TestingServerDownloadSchedule 10, 2, 2, 5
<teor> Perhaps we define that as: <consensus interval>, <vote interval>, <dist interval>, <consensus interval>/2
<teor> Sure. I will log a lorax on your last suggestion
<rl1987> nice.
<rl1987> not sure if the idea is very useful, though.
<rl1987> but I would like it to be considered.
<teor> Sure is a lot nicer than having to set 6-8 separate parameters
    • T
      teor @teor ·
      Author

      This is not required for #13718 (moved), but it might be nice eventually, if we can decide on a canonical set of options that need to change to adjust the consensus speed.

      But we should complete #14034 (moved) first, as it may impact the final set of options.

      Trac:
      Parent: #13718 (moved) to #14034 (moved)

    • T
      teor @teor ·
      Author

      Add TestingClientMaxIntervalWithoutRequest per #14067 (moved) as a quadratically scaled value Reduce Testing*DownloadSchedule to V3AuthVotingInterval/4 per #14067 (moved)

      Trac:
      Description: In order to adjust the consensus speed in a tor network, we need to configure at least 8 torrc options across authorities, relays, and clients. These options have complex timing interrelationships.

      rl1987 suggested that we add a single "make it faster by X times" parameter that modifies all of these at once.

      If I were using chutney, I would prefer a parameter that changes the length of the consensus cycle to a specified number of seconds. (What does 0.1x mean? And reaching the minimums would require fractions like 0.0028.) But the basic idea is still the same.

      I believe the options we would need to modify are:

      = Option = = Minimum = = Testing = = Default = = Suggested = = Constraints =
      V3AuthVotingInterval 10 (after #13718 (moved)) 300 3600 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default Must be strictly more than twice (V3AuthVoteDelay + V3AuthDistDelay)
      TestingV3AuthInitialVotingInterval 5 (after #13718 (moved)) 150 (after #13718 (moved)) 1800 V3AuthVotingInterval/2 Must be strictly more than (TestingV3AuthInitialVoteDelay + TestingV3AuthInitialDistDelay) (after #13718 (moved), otherwise twice that)
      V3AuthVoteDelay 2 20 300 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default V3AuthVotingInterval See Above
      TestingV3AuthInitialVoteDelay 2 20 300 V3AuthVoteDelay See Above
      V3AuthDistDelay 2 20 300 V3AuthVoteDelay See Above
      TestingV3AuthInitialDistDelay 2 20 300 V3AuthDistDelay See Above
      TestingServerDownloadSchedule 0 0, 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 0, 60, 60, 120, 300, 900, 2147483647 0, V3AuthVotingInterval/2 None
      TestingClientDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 2147483647 TestingServerDownloadSchedule None
      TestingBridgeDownloadSchedule 0 60, 30, 30, 60 3600, 900, 900, 3600 TestingServerDownloadSchedule None
      TestingServerConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 1800, 1800, 1800, 1800, 3600, 7200 TestingServerDownloadSchedule None
      TestingClientConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 3600, 3600, 3600, 10800, 21600, 43200 TestingServerConsensusDownloadSchedule None

      If we yield the default times when TestingOverallConsensusInterval 3600, then some typical values would be:

      = Option = = Minimum = = Testing = = Turbo (2x) = = Default =
      TestingOverallConsensusInterval 10 300 1800 3600
      Scaled V3AuthVotingInterval 10 ((300-10) * (3600-10) / (3600-10)) + 10 = 300 ((1800-10) * (3600-10) / (3600-10)) + 10 = 1800 ((3600-10) * (3600-10) / (3600-10)) + 10 = 3600
      Comparable V3AuthVotingInterval 10 300 N/A 3600
      Scaled V3AuthVoteDelay 2 ((300-2) * (300-10) / (3600-10)) + 2 = 26 ((300-2) * (1800-10) / (3600-10)) + 2 = 150 ((300-2) * (3600-10) / (3600-10)) + 2 = 300
      Comparable V3AuthVoteDelay 2 20 N/A 300

      These look good, although we'd also need to make sure that any scaling didn't drop the values below the absolute minimums. This should probably be clipped automatically, so TestingOverallConsensusInterval 0 makes sense as "go as fast as you can".

      <rl1987> my idea: what about having a configurable parameter that makes consensus happen faster by, say, 100 times?
<teor> rl1987: you mean, V3AuthVotingInterval, TestingV3AuthInitialVotingInterval, TestingV3AuthInitialVoteDelay, V3AuthVoteDelay, TestingV3AuthInitialDistDelay, V3AuthDistDelay, TestingServerDownloadSchedule
<teor> Unfortunately, the behaviour is a little too complex to just say, "make it very very fast"
<teor> I've basically reduced those parameters to their minimums, and patched tor when that didn't work as I thought it should
<rl1987> I meant "make it faster by X times"
<rl1987> if the entire lifecycle takes 6 hours, maybe we can have a parameter that forces it to take 6 hours / X
<rl1987> not sure how feasible is that.
<teor> Hmm, I think we'd be dividing too many things by that number
<rl1987> would it cause any trouble, if they were getting proportionally smaller?
<teor> Hmm, there's some things that have minimum times, and I've already set them to that to get it to work in under a minute
<teor> Perhaps we could scale up between that and the default hour-long interval
<teor> i.e. the minimum consensus time is 10 seconds, the default is 3600 seconds, let's have a parameter that scales up proportionally
<teor> or, the minimum voting and distribution delays are 2 seconds, the defaults are 300 seconds, ...
<teor> I'm not sure how to handle TestingServerDownloadSchedule and TestingClientDownloadSchedule
<teor> They look like: TestingServerDownloadSchedule 10, 2, 2, 5
<teor> Perhaps we define that as: <consensus interval>, <vote interval>, <dist interval>, <consensus interval>/2
<teor> Sure. I will log a lorax on your last suggestion
<rl1987> nice.
<rl1987> not sure if the idea is very useful, though.
<rl1987> but I would like it to be considered.
<teor> Sure is a lot nicer than having to set 6-8 separate parameters

      to

      In order to adjust the consensus speed in a tor network, we need to configure at least 8 torrc options across authorities, relays, and clients. These options have complex timing interrelationships.

      rl1987 suggested that we add a single "make it faster by X times" parameter that modifies all of these at once.

      If I were using chutney, I would prefer a parameter that changes the length of the consensus cycle to a specified number of seconds. (What does 0.1x mean? And reaching the minimums would require fractions like 0.0028.) But the basic idea is still the same.

      I believe the options we would need to modify are:

      = Option = = Minimum = = Testing = = Default = = Suggested = = Constraints =
      V3AuthVotingInterval 10 (after #13718 (moved)) 300 3600 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default Must be strictly more than twice (V3AuthVoteDelay + V3AuthDistDelay)
      TestingV3AuthInitialVotingInterval 5 (after #13718 (moved)) 150 (after #13718 (moved)) 1800 V3AuthVotingInterval/2 Must be strictly more than (TestingV3AuthInitialVoteDelay + TestingV3AuthInitialDistDelay) (after #13718 (moved), otherwise twice that)
      V3AuthVoteDelay 2 20 300 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default V3AuthVotingInterval See Above
      TestingV3AuthInitialVoteDelay 2 20 300 V3AuthVoteDelay See Above
      V3AuthDistDelay 2 20 300 V3AuthVoteDelay See Above
      TestingV3AuthInitialDistDelay 2 20 300 V3AuthDistDelay See Above
      TestingClientMaxIntervalWithoutRequest 1 5 600 Quadratic Scaling Between Minimum and Default based on (TestingOverallConsensusInterval^2)/(Default^2) None
      TestingServerDownloadSchedule 0 0, 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 0, 60, 60, 120, 300, 900, 2147483647 0, V3AuthVotingInterval/4 None
      TestingClientDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 2147483647 TestingServerDownloadSchedule None
      TestingBridgeDownloadSchedule 0 60, 30, 30, 60 3600, 900, 900, 3600 TestingServerDownloadSchedule None
      TestingServerConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 1800, 1800, 1800, 1800, 3600, 7200 TestingServerDownloadSchedule None
      TestingClientConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 3600, 3600, 3600, 10800, 21600, 43200 TestingServerConsensusDownloadSchedule None

      If we yield the default times when TestingOverallConsensusInterval 3600, then some typical values would be:

      = Option = = Minimum = = Testing = = Turbo (2x) = = Default =
      TestingOverallConsensusInterval 10 300 1800 3600
      Scaled V3AuthVotingInterval 10 ((300-10) * (3600-10) / (3600-10)) + 10 = 300 ((1800-10) * (3600-10) / (3600-10)) + 10 = 1800 ((3600-10) * (3600-10) / (3600-10)) + 10 = 3600
      Comparable V3AuthVotingInterval 10 300 N/A 3600
      Scaled V3AuthVoteDelay 2 ((300-2) * (300-10) / (3600-10)) + 2 = 26 ((300-2) * (1800-10) / (3600-10)) + 2 = 150 ((300-2) * (3600-10) / (3600-10)) + 2 = 300
      Comparable V3AuthVoteDelay 2 20 N/A 300
      Scaled TestingClientMaxIntervalWithoutRequest 1 ((600-1) * (300-10)^2 / (3600-10)^2) + 1 = 5 ((600-1) * (1800-10)^2 / (3600-10)^2) + 1 = 150 ((600-1) * (3600-10)^2 / (3600-10)^2) + 1 = 600
      Comparable TestingClientMaxIntervalWithoutRequest 1 5 N/A 600

      These look good, although we'd also need to make sure that any scaling didn't drop the values below the absolute minimums. This should probably be clipped automatically, so TestingOverallConsensusInterval 0 makes sense as "go as fast as you can".

      <rl1987> my idea: what about having a configurable parameter that makes consensus happen faster by, say, 100 times?
<teor> rl1987: you mean, V3AuthVotingInterval, TestingV3AuthInitialVotingInterval, TestingV3AuthInitialVoteDelay, V3AuthVoteDelay, TestingV3AuthInitialDistDelay, V3AuthDistDelay, TestingServerDownloadSchedule
<teor> Unfortunately, the behaviour is a little too complex to just say, "make it very very fast"
<teor> I've basically reduced those parameters to their minimums, and patched tor when that didn't work as I thought it should
<rl1987> I meant "make it faster by X times"
<rl1987> if the entire lifecycle takes 6 hours, maybe we can have a parameter that forces it to take 6 hours / X
<rl1987> not sure how feasible is that.
<teor> Hmm, I think we'd be dividing too many things by that number
<rl1987> would it cause any trouble, if they were getting proportionally smaller?
<teor> Hmm, there's some things that have minimum times, and I've already set them to that to get it to work in under a minute
<teor> Perhaps we could scale up between that and the default hour-long interval
<teor> i.e. the minimum consensus time is 10 seconds, the default is 3600 seconds, let's have a parameter that scales up proportionally
<teor> or, the minimum voting and distribution delays are 2 seconds, the defaults are 300 seconds, ...
<teor> I'm not sure how to handle TestingServerDownloadSchedule and TestingClientDownloadSchedule
<teor> They look like: TestingServerDownloadSchedule 10, 2, 2, 5
<teor> Perhaps we define that as: <consensus interval>, <vote interval>, <dist interval>, <consensus interval>/2
<teor> Sure. I will log a lorax on your last suggestion
<rl1987> nice.
<rl1987> not sure if the idea is very useful, though.
<rl1987> but I would like it to be considered.
<teor> Sure is a lot nicer than having to set 6-8 separate parameters
    • T
      teor @teor ·
      Author

      It's actually 12 parameters now

      Trac:
      Description: In order to adjust the consensus speed in a tor network, we need to configure at least 8 torrc options across authorities, relays, and clients. These options have complex timing interrelationships.

      rl1987 suggested that we add a single "make it faster by X times" parameter that modifies all of these at once.

      If I were using chutney, I would prefer a parameter that changes the length of the consensus cycle to a specified number of seconds. (What does 0.1x mean? And reaching the minimums would require fractions like 0.0028.) But the basic idea is still the same.

      I believe the options we would need to modify are:

      = Option = = Minimum = = Testing = = Default = = Suggested = = Constraints =
      V3AuthVotingInterval 10 (after #13718 (moved)) 300 3600 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default Must be strictly more than twice (V3AuthVoteDelay + V3AuthDistDelay)
      TestingV3AuthInitialVotingInterval 5 (after #13718 (moved)) 150 (after #13718 (moved)) 1800 V3AuthVotingInterval/2 Must be strictly more than (TestingV3AuthInitialVoteDelay + TestingV3AuthInitialDistDelay) (after #13718 (moved), otherwise twice that)
      V3AuthVoteDelay 2 20 300 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default V3AuthVotingInterval See Above
      TestingV3AuthInitialVoteDelay 2 20 300 V3AuthVoteDelay See Above
      V3AuthDistDelay 2 20 300 V3AuthVoteDelay See Above
      TestingV3AuthInitialDistDelay 2 20 300 V3AuthDistDelay See Above
      TestingClientMaxIntervalWithoutRequest 1 5 600 Quadratic Scaling Between Minimum and Default based on (TestingOverallConsensusInterval^2)/(Default^2) None
      TestingServerDownloadSchedule 0 0, 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 0, 60, 60, 120, 300, 900, 2147483647 0, V3AuthVotingInterval/4 None
      TestingClientDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 2147483647 TestingServerDownloadSchedule None
      TestingBridgeDownloadSchedule 0 60, 30, 30, 60 3600, 900, 900, 3600 TestingServerDownloadSchedule None
      TestingServerConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 1800, 1800, 1800, 1800, 3600, 7200 TestingServerDownloadSchedule None
      TestingClientConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 3600, 3600, 3600, 10800, 21600, 43200 TestingServerConsensusDownloadSchedule None

      If we yield the default times when TestingOverallConsensusInterval 3600, then some typical values would be:

      = Option = = Minimum = = Testing = = Turbo (2x) = = Default =
      TestingOverallConsensusInterval 10 300 1800 3600
      Scaled V3AuthVotingInterval 10 ((300-10) * (3600-10) / (3600-10)) + 10 = 300 ((1800-10) * (3600-10) / (3600-10)) + 10 = 1800 ((3600-10) * (3600-10) / (3600-10)) + 10 = 3600
      Comparable V3AuthVotingInterval 10 300 N/A 3600
      Scaled V3AuthVoteDelay 2 ((300-2) * (300-10) / (3600-10)) + 2 = 26 ((300-2) * (1800-10) / (3600-10)) + 2 = 150 ((300-2) * (3600-10) / (3600-10)) + 2 = 300
      Comparable V3AuthVoteDelay 2 20 N/A 300
      Scaled TestingClientMaxIntervalWithoutRequest 1 ((600-1) * (300-10)^2 / (3600-10)^2) + 1 = 5 ((600-1) * (1800-10)^2 / (3600-10)^2) + 1 = 150 ((600-1) * (3600-10)^2 / (3600-10)^2) + 1 = 600
      Comparable TestingClientMaxIntervalWithoutRequest 1 5 N/A 600

      These look good, although we'd also need to make sure that any scaling didn't drop the values below the absolute minimums. This should probably be clipped automatically, so TestingOverallConsensusInterval 0 makes sense as "go as fast as you can".

      <rl1987> my idea: what about having a configurable parameter that makes consensus happen faster by, say, 100 times?
<teor> rl1987: you mean, V3AuthVotingInterval, TestingV3AuthInitialVotingInterval, TestingV3AuthInitialVoteDelay, V3AuthVoteDelay, TestingV3AuthInitialDistDelay, V3AuthDistDelay, TestingServerDownloadSchedule
<teor> Unfortunately, the behaviour is a little too complex to just say, "make it very very fast"
<teor> I've basically reduced those parameters to their minimums, and patched tor when that didn't work as I thought it should
<rl1987> I meant "make it faster by X times"
<rl1987> if the entire lifecycle takes 6 hours, maybe we can have a parameter that forces it to take 6 hours / X
<rl1987> not sure how feasible is that.
<teor> Hmm, I think we'd be dividing too many things by that number
<rl1987> would it cause any trouble, if they were getting proportionally smaller?
<teor> Hmm, there's some things that have minimum times, and I've already set them to that to get it to work in under a minute
<teor> Perhaps we could scale up between that and the default hour-long interval
<teor> i.e. the minimum consensus time is 10 seconds, the default is 3600 seconds, let's have a parameter that scales up proportionally
<teor> or, the minimum voting and distribution delays are 2 seconds, the defaults are 300 seconds, ...
<teor> I'm not sure how to handle TestingServerDownloadSchedule and TestingClientDownloadSchedule
<teor> They look like: TestingServerDownloadSchedule 10, 2, 2, 5
<teor> Perhaps we define that as: <consensus interval>, <vote interval>, <dist interval>, <consensus interval>/2
<teor> Sure. I will log a lorax on your last suggestion
<rl1987> nice.
<rl1987> not sure if the idea is very useful, though.
<rl1987> but I would like it to be considered.
<teor> Sure is a lot nicer than having to set 6-8 separate parameters

      to

      In order to adjust the consensus speed in a tor network, we need to configure at least 12 torrc options across authorities, relays, and clients. These options have complex timing interrelationships.

      rl1987 suggested that we add a single "make it faster by X times" parameter that modifies all of these at once.

      If I were using chutney, I would prefer a parameter that changes the length of the consensus cycle to a specified number of seconds. (What does 0.1x mean? And reaching the minimums would require fractions like 0.0028.) But the basic idea is still the same.

      I believe the options we would need to modify are:

      = Option = = Minimum = = Testing = = Default = = Suggested = = Constraints =
      V3AuthVotingInterval 10 (after #13718 (moved)) 300 3600 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default Must be strictly more than twice (V3AuthVoteDelay + V3AuthDistDelay)
      TestingV3AuthInitialVotingInterval 5 (after #13718 (moved)) 150 (after #13718 (moved)) 1800 V3AuthVotingInterval/2 Must be strictly more than (TestingV3AuthInitialVoteDelay + TestingV3AuthInitialDistDelay) (after #13718 (moved), otherwise twice that)
      V3AuthVoteDelay 2 20 300 Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default V3AuthVotingInterval See Above
      TestingV3AuthInitialVoteDelay 2 20 300 V3AuthVoteDelay See Above
      V3AuthDistDelay 2 20 300 V3AuthVoteDelay See Above
      TestingV3AuthInitialDistDelay 2 20 300 V3AuthDistDelay See Above
      TestingClientMaxIntervalWithoutRequest 1 5 600 Quadratic Scaling Between Minimum and Default based on (TestingOverallConsensusInterval^2)/(Default^2) None
      TestingServerDownloadSchedule 0 0, 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 0, 60, 60, 120, 300, 900, 2147483647 0, V3AuthVotingInterval/4 None
      TestingClientDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 2147483647 TestingServerDownloadSchedule None
      TestingBridgeDownloadSchedule 0 60, 30, 30, 60 3600, 900, 900, 3600 TestingServerDownloadSchedule None
      TestingServerConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 1800, 1800, 1800, 1800, 3600, 7200 TestingServerDownloadSchedule None
      TestingClientConsensusDownloadSchedule 0 0, 0, 5, 10, 15, 20, 30, 60 0, 0, 60, 300, 600, 1800, 3600, 3600, 3600, 10800, 21600, 43200 TestingServerConsensusDownloadSchedule None

      If we yield the default times when TestingOverallConsensusInterval 3600, then some typical values would be:

      = Option = = Minimum = = Testing = = Turbo (2x) = = Default =
      TestingOverallConsensusInterval 10 300 1800 3600
      Scaled V3AuthVotingInterval 10 ((300-10) * (3600-10) / (3600-10)) + 10 = 300 ((1800-10) * (3600-10) / (3600-10)) + 10 = 1800 ((3600-10) * (3600-10) / (3600-10)) + 10 = 3600
      Comparable V3AuthVotingInterval 10 300 N/A 3600
      Scaled V3AuthVoteDelay 2 ((300-2) * (300-10) / (3600-10)) + 2 = 26 ((300-2) * (1800-10) / (3600-10)) + 2 = 150 ((300-2) * (3600-10) / (3600-10)) + 2 = 300
      Comparable V3AuthVoteDelay 2 20 N/A 300
      Scaled TestingClientMaxIntervalWithoutRequest 1 ((600-1) * (300-10)^2 / (3600-10)^2) + 1 = 5 ((600-1) * (1800-10)^2 / (3600-10)^2) + 1 = 150 ((600-1) * (3600-10)^2 / (3600-10)^2) + 1 = 600
      Comparable TestingClientMaxIntervalWithoutRequest 1 5 N/A 600

      These look good, although we'd also need to make sure that any scaling didn't drop the values below the absolute minimums. This should probably be clipped automatically, so TestingOverallConsensusInterval 0 makes sense as "go as fast as you can".

      <rl1987> my idea: what about having a configurable parameter that makes consensus happen faster by, say, 100 times?
<teor> rl1987: you mean, V3AuthVotingInterval, TestingV3AuthInitialVotingInterval, TestingV3AuthInitialVoteDelay, V3AuthVoteDelay, TestingV3AuthInitialDistDelay, V3AuthDistDelay, TestingServerDownloadSchedule
<teor> Unfortunately, the behaviour is a little too complex to just say, "make it very very fast"
<teor> I've basically reduced those parameters to their minimums, and patched tor when that didn't work as I thought it should
<rl1987> I meant "make it faster by X times"
<rl1987> if the entire lifecycle takes 6 hours, maybe we can have a parameter that forces it to take 6 hours / X
<rl1987> not sure how feasible is that.
<teor> Hmm, I think we'd be dividing too many things by that number
<rl1987> would it cause any trouble, if they were getting proportionally smaller?
<teor> Hmm, there's some things that have minimum times, and I've already set them to that to get it to work in under a minute
<teor> Perhaps we could scale up between that and the default hour-long interval
<teor> i.e. the minimum consensus time is 10 seconds, the default is 3600 seconds, let's have a parameter that scales up proportionally
<teor> or, the minimum voting and distribution delays are 2 seconds, the defaults are 300 seconds, ...
<teor> I'm not sure how to handle TestingServerDownloadSchedule and TestingClientDownloadSchedule
<teor> They look like: TestingServerDownloadSchedule 10, 2, 2, 5
<teor> Perhaps we define that as: <consensus interval>, <vote interval>, <dist interval>, <consensus interval>/2
<teor> Sure. I will log a lorax on your last suggestion
<rl1987> nice.
<rl1987> not sure if the idea is very useful, though.
<rl1987> but I would like it to be considered.
<teor> Sure is a lot nicer than having to set 6-8 separate parameters
    • T
      teor @teor ·
      Author

      Trac:
      Parent: #14034 (moved) to N/A

    • T
      teor @teor ·
      Author

      This relies on #14034 (moved) being completed, as the options seem to change each time I work on chutney bootstrapping.

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Trac:
      Milestone: N/A to Tor: 0.2.???

    • T
      teor @teor ·
      Author

      See #16386 (moved) for additional options around bandwidth reporting.

    • T
      teor @teor ·
      Author

      Trac:
      Keywords: lorax chutney deleted, lorax chutney SponsorS added

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Bulk-replace SponsorS keyword with SponsorS sponsor field in Tor component.

      Trac:
      Sponsor: N/A to SponsorS
      Keywords: lorax chutney SponsorS deleted, lorax, chutney added

    • Isabela Fernandes
      Isabela Fernandes @isabela ·

      Trac:
      Reviewer: N/A to N/A
      Severity: N/A to Normal
      Sponsor: SponsorS to SponsorS-can

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Remove the SponsorS status from these items, which we already decided to defer from 0.2.9. add the SponsorS-deferred tag instead in case we ever want to remember which ones these were.

      Trac:
      Sponsor: SponsorS-can to N/A
      Keywords: N/A deleted, SponsorS-deferred added

    • T
      teor @teor ·
      Author

      Milestone renamed

      Trac:
      Milestone: Tor: 0.2.??? to Tor: 0.3.???

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

      Trac:
      Milestone: Tor: 0.3.??? to Tor: unspecified
      Keywords: N/A deleted, tor-03-unspecified-201612 added

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Remove an old triaging keyword.

      Trac:
      Keywords: tor-03-unspecified-201612 deleted, N/A added

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Trac:
      Keywords: SponsorS-deferred deleted, robustness, testing, tor-relay added

    • teor mentioned in issue #14034 (moved)

      mentioned in issue #14034 (moved)

    • teor mentioned in issue #16386 (moved)

      mentioned in issue #16386 (moved)

    • Trac moved to tpo/core/tor#13976 (closed)

      moved to tpo/core/tor#13976 (closed)

    Please register or sign in to reply