circuit construction timeout values

[Scott Bennett]

 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.

Apr 27 16:16:08.917 [info] circuit_build_times_set_timeout(): Set circuit build 
timeout to 68s (67721.267133ms, Xm: 6025, a: 0.665199) based on 5000 circuit 
times

The next message of this form is

Apr 27 16:16:08.917 [info] circuit_build_times_set_timeout(): Set circuit build 
timeout to 68s (67721.267133ms, Xm: 6025, a: 0.665199) based on 5000 circuit 
times

That one is followed by

Apr 27 16:26:14.040 [info] circuit_build_times_set_timeout(): Set circuit build 
timeout to 93s (93292.661928ms, Xm: 2525, a: 0.445889) based on 5000 circuit 
times

Messages showing similar timeouts (i.e., 93-94 s) continue for quite some time.
Then the following sequence occurs.

Apr 27 18:15:53.967 [info] circuit_build_times_set_timeout(): Set circuit build 
timeout to 94s (93616.547344ms, Xm: 2525, a: 0.445462) based on 5000 circuit 
times
Apr 27 18:15:59.672 [info] circuit_build_times_set_timeout(): Set circuit build 
timeout to 65s (64619.917420ms, Xm: 9075, a: 0.819887) based on 5000 circuit 
times

 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!


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at cs.niu.edu  *
**
* A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army.   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/

Re: Tor 0.2.2.13-alpha is out

[Kobe, Fan YANG]

unsubscribe

On Thu, Apr 29, 2010 at 3:13 AM, Roger Dingledine a...@mit.edu wrote:

 Tor 0.2.2.13-alpha addresses the recent connection and memory overload
 problems we've been seeing on relays, especially relays with their DirPort
 open. If your relay has been crashing, or you turned it off because it
 used too many resources, give this release a try.

 https://www.torproject.org/download.html.en

 Changes in version 0.2.2.13-alpha - 2010-04-24
  o Major bugfixes:
- Teach relays to defend themselves from connection overload. Relays
  now close idle circuits early if it looks like they were intended
  for directory fetches. Relays are also more aggressive about closing
  TLS connections that have no circuits on them. Such circuits are
  unlikely to be re-used, and tens of thousands of them were piling
  up at the fast relays, causing the relays to run out of sockets
  and memory. Bugfix on 0.2.0.22-rc (where clients started tunneling
  their directory fetches over TLS).

  o Minor features:
- Finally get rid of the deprecated and now harmful notion of clique
  mode, where directory authorities maintain TLS connections to
  every other relay.
- Directory authorities now do an immediate reachability check as soon
  as they hear about a new relay. This change should slightly reduce
  the time between setting up a relay and getting listed as running
  in the consensus. It should also improve the time between setting
  up a bridge and seeing use by bridge users.
- Directory authorities no longer launch a TLS connection to every
  relay as they startup. Now that we have 2k+ descriptors cached,
  the resulting network hiccup is becoming a burden. Besides,
  authorities already avoid voting about Running for the first half
  hour of their uptime.


 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)

 iD8DBQFL2IjP61qJaiiYi/URAqi/AKCR8P/SHKmTfucFliYX0Pb21VwkKACgxTA2
 onjodL4byTlt8G+VO54f92A=
 =RVsB
 -END PGP SIGNATURE-




-- 
Kobe Young

unsubscribe

[Kobe, Fan YANG]

-- 
Kobe Young