[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] [metrics/master] Declare most July tasks done and move the remaining ones to August.
Author: Karsten Loesing <karsten.loesing@xxxxxxx>
Date: Wed, 29 Jul 2009 03:45:56 +0200
Subject: Declare most July tasks done and move the remaining ones to August.
Commit: 483a3f8c63ebb4ab868c370f29177305869f4ba4
---
TODO | 131 +++++++++++++++++++++++++++++++++++++-----------------------------
1 files changed, 74 insertions(+), 57 deletions(-)
diff --git a/TODO b/TODO
index 801c524..ffd586a 100644
--- a/TODO
+++ b/TODO
@@ -11,7 +11,12 @@ Legend:
Tasks for July:
- . Client requests to directories
+ - PETS 2009
+ - Prepare HotPETs talk.
+
+ . Evaluate Roger's reduced circuit window patch
+
+ o Client requests to directories
* o May 31: Change timing so that geoip-stats are written at the end of
* 24-hours periods; get patch into master.
o Ask folks to run with ./configure --enable-geoip-stats
@@ -33,14 +38,11 @@ Tasks for July:
o Add numbers about failed directory requests to the stats.
o Gather statistics about download times and timeouts, so that we can
infer the distribution of available bandwidth at clients.
- o Require DirReqStatistics config option, warn if DirPort is set to 0.
+ o Require DirReqStatistics config option.
o Make unit tests work again.
- - Analyze directory requests by end of July which are running for about
- two months by then.
- - Figure out why estimations are that far off. Where is the flaw in the
- math?
+ o Fix problem with comparing timevals on 32-bit architectures.
- . Cells in circuit queues
+ o Cells in circuit queues
o Consider circuits that were active in the past 15 minutes rather than
only those that were closed recently; otherwise long-running curcits
are not considered adequately.
@@ -56,20 +58,16 @@ Tasks for July:
* o May 31: Prepare buffer-stats patch for inclusion in master.
* o June 30: Decide if buffer statistics should be measured in the future
* in aggregate form.
- . Run on gabelmoo and have some other folks run the patch; analyze
- results for "1.2, new circuit window sizes. make the default package
- window lower" and "2.1, squeeze loud circuits" in performance roadmap.
-* . July 31: Write report on measured cell stats data.
+ o Run on gabelmoo and have some other folks run the patch.
- . Clients connecting to entry nodes
+ o Clients connecting to entry nodes
* o May 31: Implement entry-guard statistics in Tor.
* o June 30: Decide if statistics should be measured in the future in
* aggregate form.
o Get patch into master.
- . Run patch on gabelmoo and a few other places.
-* - July 31: Write report on measured entry stats data.
+ o Run patch on gabelmoo and a few other places.
- . Exiting traffic by port
+ o Exiting traffic by port
o Write outgoing traffic by port to logs.
o Include patch in master.
* o June 30: Decide if statistics should be measured in the future in
@@ -77,9 +75,7 @@ Tasks for July:
o Consider a threshold of bytes per port (possibly as percentage of
overall bytes) for including a port. Otherwise stats are too big for
extra-info documents.
-* . May 31: Run on a few exit nodes.
-* . July 31: Evaluate data together with Steven. Write report on measured
-* exit port data.
+* o May 31: Run on a few exit nodes.
o Measure throughput
o Evaluate torperf run and see if such runs should be performed
@@ -87,40 +83,66 @@ Tasks for July:
o Handle timeouts better by catching INT signals and writing an error
message to stdout.
o Set up second torperf installation somewhere, possibly on moria.
-* - July 31: Write report on measured throughput data.
o Directory archives
o Set up dedicated database server somewhere; goals are better
performance for complex queries and shared access for Steven et al.
- . Configure Mike's bandwidth scanner on gabelmoo
+ o Configure Mike's bandwidth scanner on gabelmoo
+ o Start gathering stats
+
+ o Statistics proposal (include dirreq/entry/buffer/exit statistics in
+ extra-info documents)
+ o Write proposal draft
---------------------------------------------------------------------------
Tasks for August:
- PETS 2009
- - Prepare talk.
* - Aug 5-7: Attend conference, plus 4 days travelling.
- HAR 2009
* - Aug 13-16: Attend conference, plus 2 days travelling.
- . Statistics proposal
- (include dirreq/entry/buffer/exit statistics in extra-info documents)
- o Write proposal draft
+ - Configure Mike's bandwidth scanner on gabelmoo
+ - Include measured bandwidths in votes
+
+ . Statistics proposal (include dirreq/entry/buffer/exit statistics in
+ extra-info documents)
. Implement proposal
+ - After receiving a HUP signal, don't print out that stats will be
+ written in 24 hours from then on.
- Include patch in git master
+ . Exiting traffic by port
+* . July 31: Evaluate data together with Steven. Write report on measured
+* exit port data.
+
- Alternative requirements for flags
- Display actual MTBF/WFU requirements for weakened requirements.
Evaluation has finished. Look at results and include them in report.
* - June 30: Write proposal for weakened requirements for being a Guard;
* see TODO.022.
+ - Client requests to directories
+ - Compare bytes.txt output to dirreq download times
+ - Analyze directory requests by end of July which are running for about
+ two months by then.
+ - Figure out why estimations are that far off. Where is the flaw in the
+ math?
+
+ . Cells in circuit queues
+* . August 31: Write report on measured cell stats data; analyze results
+* for "1.2, new circuit window sizes. make the default package window
+* lower" and "2.1, squeeze loud circuits" in performance roadmap.
+
+ - Clients connecting to entry nodes
+* - July 31: Write report on measured entry stats data.
+
---------------------------------------------------------------------------
-Tasks for September:
+Tasks for September or later:
- Work organization
- Add medium and low priority items from Roger's performance mail to
@@ -169,8 +191,6 @@ Tasks for September:
their cache doesn't survive, maybe old-school Torpark variants or
something. Another explanation are people running relays that aren't
reachable so aren't ignored in the geoip stats. Further investigate.
- - Unskew v2 requests by finding out what fraction of requests results in
- 503 depending on the directory's advertised bandwidth.
- Figure out if there are better GeoIP databases available that focus
more on small countries and that are still affordable.
- Try to estimate the number of concurrent Tor users from active
@@ -216,16 +236,15 @@ Tasks for September:
how they flush them on the socks side.
- Directory archives
-* - June 30: Do guards that have had the guard flag for a long time (weeks
-* or months) have more load than guards that just got their guard flag?
-* Try to find a possible correlation between advertised bandwidth and
-* the time a relay spent in the network with the Guard flag. (see 4.5 in
-* performance roadmap)
+ - Do guards that have had the guard flag for a long time (weeks or
+ months) have more load than guards that just got their guard flag? Try
+ to find a possible correlation between advertised bandwidth and the
+ time a relay spent in the network with the Guard flag. (see 4.5 in
+ performance roadmap)
- Analyze 2004 and 2005 data, too.
- Bridge archives
-* - July 31: Investigate bridge churn to determine how many bridges users
-* need.
+ - Investigate bridge churn to determine how many bridges users need.
- Look through the bridge relay stats and see how much churn there is.
Roger is guessing that the 400-some bridges we have running by end of
June do not indicate that only 400-some people set up bridges. Rather
@@ -238,41 +257,39 @@ Tasks for September:
super-stable bridges report any stats.
- Measure throughput and latency between relays
-* - May 31: Implement opportunistic measuring of cell transfer times and
-* bandwidth between relays.
-* - June 30: Decide if statistics should be measured in the future in
-* aggregate form.
+ - Implement opportunistic measuring of cell transfer times and bandwidth
+ between relays.
+ - Decide if statistics should be measured in the future in aggregate
+ form.
- Measure throughput
-* - June 30: Evaluate speedracer results.
-* - June 30: Passively measure throughput in Tor clients when configured.
+ . Write report on measured throughput data from torperf.
+ - Evaluate speedracer results.
+ - Passively measure throughput in Tor clients when configured.
- Improve usability so that non-developer users in countries like
Tunesia can measure throughput themselves. This can be speedracer,
torperf, or some other tool. Consider implementing as Vidalia plugin
once the plugin infrastructure is in place.
- Measure latencies
-* - June 30: Evaluate circuit-build times in buildtimes data.
-* - June 30: Passively measure circuit-build times in clients when
-* configured.
-* - June 30: Measure latencies by controlling both client and server in
-* simulated Web browsing session (speedracer or torperf).
-* - June 30: Measure latencies as clients would experience them. Run a Tor
-* client somewhere that makes "typical" Tor circuits (i.e. just let Tor
-* choose its own paths, but set UseEntryGuards to 0, and only make
-* requests to port 80 so it builds circuits which exit there), and send
-* pings every so often, and track how long they take. One easy way to
-* ping is to make a request to an IP address that we know is refused by
-* the last hop's exit policy. Say, 127.0.0.1:80. Then measure the time
-* between sending the connect cell, and receiving the end cell. We
-* expect this latency to go down over time, a) because we lower the
-* circuit window, and b) because Tor has on-average-better circuits
-* based on Mike Perry's plans.
+ - Evaluate circuit-build times in buildtimes data.
+ - Passively measure circuit-build times in clients when configured.
+ - Measure latencies as clients would experience them. Run a Tor client
+ somewhere that makes "typical" Tor circuits (i.e. just let Tor choose
+ its own paths, but set UseEntryGuards to 0, and only make requests to
+ port 80 so it builds circuits which exit there), and send pings every
+ so often, and track how long they take. One easy way to ping is to
+ make a request to an IP address that we know is refused by the last
+ hop's exit policy. Say, 127.0.0.1:80. Then measure the time between
+ sending the connect cell, and receiving the end cell. We expect this
+ latency to go down over time, a) because we lower the circuit window,
+ and b) because Tor has on-average-better circuits based on Mike
+ Perry's plans.
- Metrics portal
- Write down architecture for TorStatus extension.
- Implement extensions.
- Load directory archives into MySQL database and optimize database
schema so that evaluations are executed quickly.
-* - August 31: Set up extended TorStatus.
+ - Set up extended TorStatus.
--
1.5.6.5