Thus spake Scott Bennett (benn...@cs.niu.edu): > I've noticed something odd in info-level log messages that show circuit > build timeout values being set. Given that the maximum length of circuit > construction time history of 5000 construction times has already been reached, > it seems weird to see huge jumps in the timeout values from one such message > to the next. Here are two examples. > > So I'm wondering what is going on here. If the timeout being set is > supposed to reflect some sort of smoothed values of a time series of circuit > construction time, where the smoother is 5000 values wide, how can such jumps > occur? I guess I don't understand what algorithm is being used here. Any > clarification would be appreciated. Thanks in advance!
Hi Scott. There are a couple bugs in the algorithm used. One of the problems is that the Xm pareto value needs to be chosen a bit more intelligently to deal with samples coming from multiple guards. The other problem is that "synthetic" timeouts need to be clipped to a lower value. The algorithm is defined at https://gitweb.torproject.org//tor.git?a=blob;f=doc/spec/proposals/151-path-selection-improvements.txt;h=363eebae8423e4c25310dc28b6f2c232cf20e533;hb=HEAD (don't you love our nice, short, easy-to-understand-and-predict gitweb urls? ;) The bug to track this is at: https://trac.torproject.org/projects/tor/ticket/1335 If you could upload the state file from that Tor to that ticket (after stripping out the EntryGuard info), that would give me another datapoint to test against, and to ensure that these are in fact the problems you are seeing. Even 65 is a bit high for a circuit timeout, so I suspect you are actually seeing both issues here. -- Mike Perry Mad Computer Scientist fscked.org evil labs
pgp4b3bBEHPFH.pgp
Description: PGP signature
