From freebsd-listen at fabiankeil.de  Fri Jul  3 13:03:52 2009
From: freebsd-listen at fabiankeil.de (Fabian Keil)
Date: Fri, 3 Jul 2009 15:03:52 +0200
Subject: [or-cvs] r19895: {website} updated vidalia 0.1.14 available 
 (website/trunk/vidalia/en)
In-Reply-To: <20090702004856.675861408454@moria.seul.org>
References: <20090702004856.675861408454@moria.seul.org>
Message-ID: <20090703150352.37d630fe@fabiankeil.de>

phobos at seul.org wrote:

> Author: phobos
> Date: 2009-07-01 20:48:56 -0400 (Wed, 01 Jul 2009)
> New Revision: 19895
> 
> Modified:
>    website/trunk/vidalia/en/index.wml
> Log:
> updated vidalia 0.1.14 available
> 
> 
> Modified: website/trunk/vidalia/en/index.wml
> ===================================================================
> --- website/trunk/vidalia/en/index.wml	2009-07-01 21:34:36 UTC (rev 19894)
> +++ website/trunk/vidalia/en/index.wml	2009-07-02 00:48:56 UTC (rev 19895)
> @@ -38,18 +38,18 @@

> -<!--
>    <li>
> -     <a href="dist/vidalia-0.1.12-ppc.dmg">Mac OS X PPC-only</a>
> -    (<a href="dist/vidalia-0.1.12-ppc.dmg.asc">sig</a>)
> +     <a href="dist/vidalia-0.1.13-ppc.dmg">Mac OS X PPC-only</a>
> +    (<a href="dist/vidalia-0.1.13-ppc.dmg.asc">sig</a>)
>    </li>
> +<--

The '!' got lost.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20090703/43e007a6/attachment.pgp>

From prithula.dhungel at gmail.com  Mon Jul  6 02:25:30 2009
From: prithula.dhungel at gmail.com (Prithula Dhungel)
Date: Sun, 5 Jul 2009 22:25:30 -0400
Subject: OR interaction with directory server
Message-ID: <d5acd4030907051925j7f3d883ck9c859c290484c50c@mail.gmail.com>

Hi all,
  Could anyone guide me as to how long does it take for the information
about a new OR (say R1) to be received by an OP (say x), if the OP x wants
to use the OR R1 specifically to make a circuit? I observe a certain amount
of delay in that. Is it because the directory servers need to reach a
consensus for the new OR?

Also, if R1's onion key changes, how long before it will be known to x
(given that x knows about R1 already).

Thanks for the help,
--
Prithula Dhungel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20090705/553af77a/attachment.htm>

From karsten.loesing at gmx.net  Mon Jul 20 23:58:03 2009
From: karsten.loesing at gmx.net (Karsten Loesing)
Date: Tue, 21 Jul 2009 01:58:03 +0200
Subject: Please help with measuring network statistics on your relay
Message-ID: <4A65048B.1090204@gmx.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello everyone,

two months ago, I wrote a blog post describing plans to extend network
measurements:

https://blog.torproject.org/blog/performance-measurements-and-blockingresistance-analysis-tor-network

In brief, this plan includes that: entry guards count the number of
clients per country per day; relays determine statistics on the number
of cells waiting in their local queues; exit nodes count the number of
bytes and streams per exit port per day. All these statistics are
aggregated, so that none of the network data can be used to de-anonymize
users. These aggregations include counting users by country, counting
events per day, and rounding up to a multiple of 4 or 8. We need these
network data to make Tor faster and/or more useful for circumvention.

As of today, the necessary code changes to gather these statistics are
ready, including improved statistics for directory requests that have
been in the code before. For now, statistics are only written to local
files and not to extra-info documents. But before changing the
extra-info document format, I want to be sure that the gathered network
data are useful.

The only missing piece is a dozen or more people who configure their
nodes to gather these statistics for two weeks or longer. During and at
the end of this time I'll need the new files ending in -stats that
contain the gathered statistics. Stable and fast nodes are preferred.
For the exit port statistics we'll need some exit nodes permitting
exiting to _all_ ports. It doesn't matter for the statistics if a node
does not permit exiting or doesn't have the Guard flag. If there are no
results to report, the affected -stats file is omitted.

If you want to help out with gathering these statistics on your node (or
just want to know how statistics are measured), please do the following:

- - Run "git clone git://git.torproject.org/git/tor/".
- - Check that you have commit b71bbdc69a56 or later in your branch.
- - Run "./autogen.sh && ./configure --enable-dirreq-stats
- --enable-entry-stats --enable-buffer-stats --enable-exit-stats && make".
- - Possibly run "make install", or use the executable in src/or/tor.
- - Add four config options to your torrc: "DirReqStatistics 1",
"EntryStatistics 1", "CellStatistics 1", "ExitPortStatistics 1"; if you
only want to gather some of the statistics, only set those config
options to 1.
- - Add another config option to your torrc, saying where Tor can find
your GeoIP database; if you cloned the tor repository to ~/tor/, the
config option would be: "GeoIPFile ~/tor/src/config/geoip".
- - Start your node and look out for notice-level logs saying that your
node is gathering statistics.
- - Wait for 24 hours for the directory to write files called
dirreq-stats, entry-stats, cell-stats, and exit-stats to its data
directory; these files are extended every 24 hours.
- - Make the content of these -stats files available to me once after 24
hours, after 1 week, and after 2 weeks; I plan to make all files public
together with their analysis by mid-August.
- - Let me know about some basic bandwidth information of your node:
fingerprint, configured BandwidthRate, BandwidthBurst, and
MaxAdvertisedBandwidth if used; also let me know if you are okay with
being mentioned with your real name in PDFs based on these data.

Be aware that this code might contain bugs that break your node! You
should be comfortable running bleeding-edge software versions.

Here is a brief description what kind of data the four -stats files will
contain (examples show fewer data and shorter measurement intervals):

1. Directory request statistics
(dirreq-stats file, --enable-dirreq-stats, DirReqStatistics 1)

written 2009-07-19 18:12:08
started-at 2009-07-19 17:41:54
ns-ips ca=8,de=8,hk=8,ir=8,my=8,ro=8,us=8
ns-v2-ips au=8,ca=8,cn=8,de=8,es=8,gb=8,il=8,it=8,kw=8,ru=8,se=8,us=8
requests-start 2009-07-19 17:41:54
n-ns-reqs ca=8,de=8,hk=8,ir=8,my=8,ro=8,us=8
n-v2-ns-reqs au=8,ca=8,cn=8,de=8,es=8,gb=8,il=8,it=8,kw=8,ru=8,se=8,us=8
n-ns-resp
ok=16,not-enough-sigs=0,unavailable=0,not-found=0,not-modified=0,busy=0
n-v2-ns-resp ok=32,unavailable=0,not-found=8,not-modified=0,busy=0
v2-ns-share 0.05%
v3-ns-share 0.05%
ns-direct-dl complete=0,timeout=0,running=0
ns-v2-direct-dl
complete=28,timeout=0,running=0,min=5744,d1=15039,d2=60333,q1=76680,d3=79327,d4=101335,md=120688,d6=137291,d7=180365,q3=198729,d8=209279,d9=272368,max=3198322541
ns-tunneled-dl complete=12,timeout=0,running=0
ns-v2-tunneled-dl complete=0,timeout=0,running=0

The dirreq-stats file counts the number of directory requests coming
from clients asking for network statuses. The ns-ips and ns-v2-ips lines
list the number of unique IPs per country for v3 and v2 statuses,
n-ns-reqs and n-v2-ns-reqs the number of requests per country. n-ns-resp
and n-v2-ns-resp list the number of response codes, or rather reasons
for sending them. v2-ns-share and v3-ns-share are estimates of the share
of requests that a directory should see. ns-direct-dl and
ns-v2-direct-dl list the number of complete downloads, timeouts, and
still running downloads for direct requests. ns-tunneled-dl and
ns-v2-tunneled-dl show the same numbers for tunneled requests. When
there are more than 16 complete downloads in the latter four lines,
statistics are given about the client bandwidths in B/s, including
minimum/maximum, deciles, quartiles, and median.

2. Cell statistics
(buffer-stats file, --enable-buffer-stats, CellStatistics 1)

written 2009-07-19 18:11:55 (1800 s)
processed-cells 350,133,131,130,128,123,110,61,12,2
queued-cells 1.61,0.15,0.11,0.31,0.06,0.38,0.12,0.00,0.00,0.00
time-in-queue 3392,585,638,1562,348,1294,145,24,6,117
number-of-circuits-per-share 45

The buffer-stats file contains some statistics about the time that cells
spend in circuit queues. processed-cells are the mean number of total
processed cells per circuit, with circuits divided by 10 classes from
loudest to quietest circuits. queued-cells describe the mean number of
queued cells over time per circuit class. time-in-queue is the mean time
in milliseconds that a cell spends in a queue.
number-of-circuits-per-share is the number of circuits per circuit class.

3. Entry statistics
(entry-stats file, --enable-entry-stats, EntryStatistics 1)

written 2009-07-19 18:12:08
started-at 2009-07-19 17:41:54
ips
de=72,us=72,fr=24,gb=24,it=24,ru=24,cn=16,ir=16,pl=16,??=8,ae=8,ar=8,at=8,az=8,be=8,bg=8,br=8,ca=8,ch=8,co=8,cz=8,es=8,fi=8,gr=8,hk=8,hu=8,id=8,ie=8,il=8,in=8,jp=8,kr=8,kw=8,mx=8,my=8,nl=8,ph=8,qa=8,ro=8,sa=8,se=8,sk=8,tr=8,ua=8,vn=8,ye=8

The entry-stats file contains the number of connecting clients to an
entry node per country and 24 hours. These numbers are contained in the
ips line.

4. Exit port statistics
(exit-stats file, --enable-exit-stats, ExitPortStatistics 1)

written 2009-07-06 12:32:03 (86400 s)
kibibytes-written
80=784877,443=184575,27619=528,38230=1079,46060=520055,53456=632231,63032=996797,other=13048442
kibibytes-read
80=19296747,443=394341,27619=505020,38230=1029286,46060=67253,53456=112665,63032=64583,other=11429424
streams-opened
80=792612,443=43324,27619=4,38230=4,46060=4,53456=4,63032=4,other=244212

The exit-stats file contains the number of KiB and opened streams per
exit port per 24 hours. The lines show tuples of the exit port number
and the number of KiB or opened streams.


If you have any questions regarding these measurements, or find a bug in
the measurement code, please let me know, here or off-list!

Thanks!
- --Karsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkplBIkACgkQ0M+WPffBEmXvOwCfQnH3F2cZpoPgXrMHS9cVFo3t
rH8AoKrU3CYaLCugJ3Sk8DV9LnKSGzZ7
=obKt
-----END PGP SIGNATURE-----


From karsten.loesing at gmx.net  Tue Jul 21 21:30:13 2009
From: karsten.loesing at gmx.net (Karsten Loesing)
Date: Tue, 21 Jul 2009 23:30:13 +0200
Subject: Proposal: Including Network Statistics in Extra-Info Documents
Message-ID: <4A663365.5020706@gmx.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Filename: XXX-statistics-extra-info-docs.txt
Title: Including Network Statistics in Extra-Info Documents
Author: Karsten Loesing
Created: 21-Jul-2009
Target: 0.2.2
Status: Open

Change history:

  21-Jul-2009  Initial proposal for or-dev


Overview:

  The Tor network has grown to almost two thousand relays and millions
  of casual users over the past few years. With growth has come
  increasing performance problems and attempts by some countries to
  block access to the Tor network. In order to address these problems,
  we need to learn more about the Tor network. This proposal suggests to
  measure additional statistics and include them in extra-info documents
  to help us understand the Tor network better.


Introduction:

  As of May 2009, relays, bridges, and directories gather the following
  data for statistical purposes:

  - Relays and bridges count the number of bytes that they have pushed
    in 15-minute intervals over the past 24 hours. Relays and bridges
    include these data in extra-info documents that they send to the
    directory authorities whenever they publish their server descriptor.

  - Bridges further include a rough number of clients per country that
    they have seen in the past 48 hours in their extra-info documents.

  - Directories can be configured to count the number of clients they
    see per country in the past 24 hours and to write them to a local
    file.

  Since then we extended the network statistics in Tor. These statistics
  include:

  - Directories now gather more precise statistics about connecting
    clients. Fixes include measuring in intervals of exactly 24 hours,
    counting unsuccessful requests, measuring download times, etc. The
    directories append their statistics to a local file every 24 hours.

  - Entry guards count the number of clients per country per day like
    bridges do and write them to a local file every 24 hours.

  - Relays measure statistics of the number of cells in their circuit
    queues and how much time these cells spend waiting there. Relays
    write these statistics to a local file every 24 hours.

  - Exit nodes count the number of read and written bytes on exit
    connections per port as well as the number of opened exit streams
    per port in 24-hour intervals. Exit nodes write their statistics to
    a local file.

  The following four sections contain descriptions for adding these
  statistics to the relays' extra-info documents.


Directory request statistics:

  The first type of statistics aims at measuring directory requests sent
  by clients to a directory mirror or directory authority. More
  precisely, these statistics aim at requests for v2 and v3 network
  statuses only. These directory requests are sent non-anonymously,
  either via HTTP-like requests to a directory's Dir port or tunneled
  over a 1-hop circuit.

  Measuring directory request statistics is useful for several reasons:
  First, the number of locally seen directory requests can be used to
  estimate the total number of clients in the Tor network. Second, the
  country-wise classification of requests using a GeoIP database can
  help counting the relative and absolute number of users per country.
  Third, the download times can give hints on the available bandwidth
  capacity at clients.

  Directory requests do not give any hints on the contents that clients
  send or receive over the Tor network. Every client requests network
  statuses from the directories, so that there are no anonymity-related
  concerns to gather these statistics. It might be, though, that clients
  wish to hide the fact that they are connecting to the Tor network.
  Therefore, IP addresses are resolved to country codes in memory,
  events are accumulated over 24 hours, and numbers are rounded up to
  multiples of 4 or 8.

   "dirreq-stats-end" YYYY-MM-DD HH:MM:SS (NSEC s) NL
      [At most once.]

      YYYY-MM-DD HH:MM:SS defines the end of the included measurement
      interval of length NSEC seconds (86400 seconds by default).

      A "dirreq-stats-end" line, as well as any other "dirreq-*" line,
      is only added when the relay has opened its Dir port and after 24
      hours of measuring directory requests.

   "dirreq-v2-ips" CC=N,CC=N,... NL
      [At most once.]
   "dirreq-v3-ips" CC=N,CC=N,... NL
      [At most once.]

      List of mappings from two-letter country codes to the number of
      unique IP addresses that have connected from that country to
      request a v2/v3 network status, rounded up to the nearest multiple
      of 8. Only those IP addresses are counted that the directory can
      answer with a 200 OK status code.

   "dirreq-v2-reqs" CC=N,CC=N,... NL
      [At most once.]
   "dirreq-v3-reqs" CC=N,CC=N,... NL
      [At most once.]

      List of mappings from two-letter country codes to the number of
      requests for v2/v3 network statuses from that country, rounded up
      to the nearest multiple of 8. Only those requests are counted that
      the directory can answer with a 200 OK status code.

   "dirreq-v2-share" num% NL
      [At most once.]
   "dirreq-v3-share" num% NL
      [At most once.]

      The share of v2/v3 network status requests that the directory
      expects to receive from clients based on its advertised bandwidth
      compared to the overall network bandwidth capacity. Shares are
      formatted in percent with two decimal places. Shares are
      calculated as means over the whole 24-hour interval.

   "dirreq-v2-resp" status=num,... NL
      [At most once.]
   "dirreq-v3-resp" status=nul,... NL
      [At most once.]

      List of mappings from response statuses to the number of requests
      for v2/v3 network statuses that were answered with that response
      status, rounded up to the nearest multiple of 4. Only response
      statuses with at least 1 response are reported. New response
      statuses can be added at any time. The current list of response
      statuses is as follows:

      "ok": a network status request is answered; this number
         corresponds to the sum of all requests as reported in
         "dirreq-v2-reqs" or "dirreq-v3-reqs", respectively, before
         rounding up.
      "not-enough-sigs: a version 3 network status is not signed by a
         sufficient number of requested authorities.
      "unavailable": a requested network status object is unavailable.
      "not-found": a requested network status is not found.
      "not-modified": a network status has not been modified since the
         If-Modified-Since time that is included in the request.
      "busy": the directory is busy.

   "dirreq-v2-direct-dl" key=val,... NL
      [At most once.]
   "dirreq-v3-direct-dl" key=val,... NL
      [At most once.]
   "dirreq-v2-tunneled-dl" key=val,... NL
      [At most once.]
   "dirreq-v3-tunneled-dl" key=val,... NL
      [At most once.]

      List of statistics about possible failures in the download process
      of v2/v3 network statuses. Requests are either "direct"
      HTTP-encoded requests over the relay's directory port, or
      "tunneled" requests using a BEGIN_DIR cell over the relay's OR
      port. The list of possible statistics can change, and statistics
      can be left out from reporting. The current list of statistics is
      as follows:

      Successful downloads and failures:

      "complete": a client has finished the download successfully.
      "timeout": a download did not finish within 10 minutes after
         starting to send the response.
      "running": a download is still running at the end of the
         measurement period for less than 10 minutes after starting to
         send the response.

      Download times:

      "min", "max": smallest and largest measured bandwidth in B/s.
      "d[1-4,6-9]": 1st to 4th and 6th to 9th decile of measured
         bandwidth in B/s. For a given decile i, i/10 of all downloads
         had a smaller bandwidth than di, and (10-i)/10 of all downloads
         had a larger bandwidth than di.
      "q[1,3]": 1st and 3rd quartile of measured bandwidth in B/s. One
         fourth of all downloads had a smaller bandwidth than q1, one
         fourth of all downloads had a larger bandwidth than q3, and the
         remaining half of all downloads had a bandwidth between q1 and
         q3.
      "md": median of measured bandwidth in B/s. Half of the downloads
         had a smaller bandwidth than md, the other half had a larger
         bandwidth than md.


Entry guard statistics:

  Entry guard statistics include the number of clients per country and
  per day that are connecting directly to an entry guard.

  Entry guard statistics are important to learn more about the
  distribution of clients to countries. In the future, this knowledge
  can be useful to detect if there are or start to be any restrictions
  for clients connecting from specific countries.

  The information which client connects to a given entry guard is very
  sensitive. This information must not be combined with the information
  what contents are leaving the network at the exit nodes. Therefore,
  entry guard statistics need to be aggregated to prevent them from
  becoming useful for de-anonymization. Aggregation includes resolving
  IP addresses to country codes, counting events over 24-hour intervals,
  and rounding up numbers to the next multiple of 8.

   "entry-stats-end" YYYY-MM-DD HH:MM:SS (NSEC s) NL
      [At most once.]

      YYYY-MM-DD HH:MM:SS defines the end of the included measurement
      interval of length NSEC seconds (86400 seconds by default).

      An "entry-stats-end" line, as well as any other "entry-*"
      line, is first added after the relay has been running for at least
      24 hours.

   "entry-ips" CC=N,CC=N,... NL
      [At most once.]

      List of mappings from two-letter country codes to the number of
      unique IP addresses that have connected from that country to the
      relay and which are no known other relays, rounded up to the
      nearest multiple of 8.


Cell statistics:

  The third type of statistics have to do with the time that cells spend
  in circuit queues. In order to gather these statistics, the relay
  memorizes when it puts a given cell in a circuit queue and when this
  cell is flushed. The relay further notes the life time of the circuit.
  These data are sufficient to determine the mean number of cells in a
  queue over time and the mean time that cells spend in a queue.

  Cell statistics are necessary to learn more about possible reasons for
  the poor network performance of the Tor network, especially high
  latencies. The same statistics are also useful to determine the
  effects of design changes by comparing today's data with future data.

  There are basically no privacy concerns from measuring cell
  statistics, regardless of a node being an entry, middle, or exit node.

   "cell-stats-end" YYYY-MM-DD HH:MM:SS (NSEC s) NL
      [At most once.]

      YYYY-MM-DD HH:MM:SS defines the end of the included measurement
      interval of length NSEC seconds (86400 seconds by default).

      A "cell-stats-end" line, as well as any other "cell-*" line,
      is first added after the relay has been running for at least 24
      hours.

   "cell-processed-cells" num,...,num NL
      [At most once.]

      Mean number of processed cells per circuit, subdivided into
      deciles of circuits by the number of cells they have processed in
      descending order from loudest to quietest circuits.

   "cell-queued-cells" num,...,num NL
      [At most once.]

      Mean number of cells contained in queues by circuit decile. These
      means are calculated by 1) determining the mean number of cells in
      a single circuit between its creation and its termination and 2)
      calculating the mean for all circuits in a given decile as
      determined in "cell-processed-cells". Numbers have a precision of
      two decimal places.

   "cell-time-in-queue" num,...,num NL
      [At most once.]

      Mean time cells spend in circuit queues in milliseconds. Times are
      calculated by 1) determining the mean time cells spend in the
      queue of a single circuit and 2) calculating the mean for all
      circuits in a given decile as determined in
      "cell-processed-cells".

   "cell-circuits-per-decile" num NL
      [At most once.]

      Mean number of circuits that are included in any of the deciles,
      rounded up to the next integer.


Exit statistics:

  The last type of statistics affects exit nodes counting the number of
  bytes written and read and the number of streams opened per port and
  per 24 hours. Exit port statistics can be measured from looking of
  headers of BEGIN and DATA cells. A BEGIN cell contains the exit port
  that is required for the exit node to open a new exit stream.
  Subsequent DATA cells coming from the client or being sent back to the
  client contain a length field stating how many bytes of application
  data are contained in the cell.

  Exit port statistics are important to measure in order to identify
  possible load-balancing problems with respect to exit policies. Exit
  nodes that permit more ports than others are very likely overloaded
  with traffic for those ports plus traffic for other ports. Improving
  load balancing in the Tor network improves the overall utilization of
  bandwidth capacity.

  Exit traffic is one of the most sensitive parts of network data in the
  Tor network. Even though these statistics do not require looking at
  traffic contents, statistics are aggregated so that they are not
  useful for de-anonymizing users. Only those ports are reported that
  have seen at least 0.1% of exiting or incoming bytes, numbers of bytes
  are rounded up to full kibibytes (KiB), and stream numbers are rounded
  up to the next multiple of 4.

   "exit-stats-end" YYYY-MM-DD HH:MM:SS (NSEC s) NL
      [At most once.]

      YYYY-MM-DD HH:MM:SS defines the end of the included measurement
      interval of length NSEC seconds (86400 seconds by default).

      An "exit-stats-end" line, as well as any other "exit-*" line, is
      first added after the relay has been running for at least 24 hours
      and only if the relay permits exiting (where exiting to a single
      port and IP address is sufficient).

   "exit-kibibytes-written" port=N,port=N,... NL
      [At most once.]
   "exit-kibibytes-read" port=N,port=N,... NL
      [At most once.]

      List of mappings from ports to the number of kibibytes that the
      relay has written to or read from exit connections to that port,
      rounded up to the next full kibibyte.

   "exit-streams-opened" port=N,port=N,... NL
      [At most once.]

      List of mappings from ports to the number of opened exit streams
      to that port, rounded up to the nearest multiple of 4.


Implementation notes:

  Right now, relays that are configured accordingly write similar
  statistics to those described in this proposal to disk every 24 hours.
  With this proposal being implemented, relays include the contents of
  these files in extra-info documents.

  The following steps are necessary to implement this proposal:

  1. The current format of [dirreq|entry|buffer|exit]-stats files needs
     to be adapted to the description in this proposal. This step
     basically means renaming keywords.

  2. The timing of writing the four *-stats files should be unified, so
     that they are written exactly after 24 hours after starting the
     relay. Right now, the measurement intervals for dirreq, entry, and
     exit stats starts with the first observed request, and files are
     written when observing the first request that occurs more than 24
     hours after the beginning of the measurement interval. With this
     proposal, the measurement intervals should all start at the same
     time, and files should be written exactly 24 hours later.

  3. It is advantageous to cache statistics in local files in the data
     directory until they are included in extra-info documents. The
     reason is that the 24-hour measurement interval can be very
     different from the 18-hour publication interval of extra-info
     documents. When a relay crashed after finishing a measurement
     interval, but before publishing the next extra-info document,
     statistics would get lost. Therefore, statistics are written to
     disk when finishing a measurement interval and read from disk when
     generating an extra-info document. As a result, the *-stats files
     need to be overwritten after 24 hours, rather than appending new
     statistics to them. Further, the contents of the *-stats files need
     to be checked in the process of generating extra-info documents.

  4. With the statistics patches being tested, the ./configure options
     should be removed and the statistics code be compiled by default.
     It is still required for relay operators to add configuration
     options (DirReqStatistics, ExitPortStatistics, etc.) to enable
     gathering statistics. However, in the near future, statistics shall
     be enabled gathered by all relays by default, where requiring a
     ./configure option would be a barrier for many relay operators.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpmM2EACgkQ0M+WPffBEmVxvwCePIPo/oWaHqspvidENbuxWXzB
PJkAn2oaYfyy67CK3ui/AmMYt/lUl1JP
=oWQx
-----END PGP SIGNATURE-----