CircuitBuildTimeout Management and the Pareto Distribution

[Cav]

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 at gotadsl.co.uk):
>
>   
>> 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.
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20100724/e084fe4b/attachment.htm>