Hi Mike, Thanks for a quick reply. Maybe its my warped mind that had me consider that the management of timeouts (sliding the timeout up and down - as it appears in the logs) would affect the distribution of timeouts and therefore the pareto distribution around them. I will admit to experimenting with smaller values of CBT_DEFAULT_QUANTILE_CUTOFF. These lead to 'peaks' in the timeout distribution. The smaller the value, the tighter these 'peaks' seem to be. I assumed from this that as the timeout is moved up and time from the management code, that these islands of circuit build timeouts would appear around the current timeout values. I admit this could be conjecture and speculation, apart from the build timeouts I see in the state file. With kind regards, Cav Edwards Mike Perry wrote: Thus spake Cav (cav@xxxxxxxxxxxxx):I was wondering if the new CircuitBuildTimeout management code in the 0.2.2.14 release renders the pareto distribution code redundant in a sense ? It seems there is now, in that new code, a distorting effect on the normal distribution of circuits that are built ?I'm not 100% sure what you mean here. We are still using the pareto distribution. In fact, we're using it more correctly than before, in that instead of generating "synthetic" values for circuits that time out, we allow circuits to continue to build until the 95th percentile on the pareto curve (but do not use them). Circuits that take an amount of time to build that is beyond the 95th percentile on the curve get counted as "censored" values for a "right-censored" Pareto estimator. This is documented in greater detail in path-spec.txt section 2.4. The end result is that we expect to allow the fastest 80% of circuits to be used for tor traffic. In practice we actually get pretty darn close to this for my experimental setup and on the real network. |