commit 56d397f203f4e3a1593817e0e4cb585e516ad3af Author: Mike Perry <mikeperry-git@fscked.org> Date: Sun Oct 23 02:51:11 2011 -0700 Fix some confusion with bandwidth recording events. --- bwauth-spec.txt | 26 ++++++++++++-------------- 1 files changed, 12 insertions(+), 14 deletions(-) diff --git a/bwauth-spec.txt b/bwauth-spec.txt index 9c4dc75..8c638cd 100644 --- a/bwauth-spec.txt +++ b/bwauth-spec.txt @@ -8,7 +8,8 @@ Karsten Loesing - Mike Perry + Mike Perry + Aaron Gibson 0. Preliminaries @@ -155,7 +156,7 @@ - Nodes are selected uniformly among those with the lowest measurement count for the current slice. Otherwise, there is no preference for - relays, e.g., based on bandwidth. + relays. - Relays in the paths must come from different /16 subnets. @@ -202,13 +203,16 @@ Unfinished downloads are aborted after 30 minutes. - For each download, the bandwidth scanners process STREAM_BW events with - a StreamListener (SQLSupport.py). The throughput for each stream is - defined as the ratio of total read bytes over the time delta between the - stream start timestamp and the newest STREAM_BW event received timestamp: + For each download, the bandwidth scanners process STREAM and STREAM_BW events + with a StreamListener (in TorCtl/SQLSupport.py). The throughput for each + stream is defined as the ratio of total read bytes over the time delta between + the STREAM NEW timestamp and the STREAM CLOSED event received timestamp: - (stream read bytes / (event received timestamp - stream start timestamp) + bandwidth = (STREAM_BW bytes / (CLOSED timestamp - NEW timestamp) + We store both read and write bandwidths in the SQL tables, but only use + the read bytes for results. + 1.6. Writing measurement results Once a bandwidth scanner has completed a slice of relays, it writes the @@ -259,7 +263,7 @@ The filt_bw field is computed similarly, but only the streams equal to or greater than the strm_bw are counted in order to filter very slow - streams. + streams due to slow node pairings. The nickname field is entirely informational and may change between measurements. @@ -268,12 +272,6 @@ filtered stream bandwidth, and non-negative stream bandwidth are included in the output file. -# Starting to count slices at 0 whenever we start at the lower end of our -# percentile range seems error-prone. What if the number of slices -# changes while we're only half through with all slices? Isn't there a -# potential from overlooking results? Or do we not care about the slice -# number when aggregating results? -KL - 2. Aggregating scanner results Once per hour (via cron), the bandwidth scanner results are aggregated