Opened 9 years ago

Closed 9 years ago

#1919 closed defect (fixed)

Set up a few new torperfs with fixed sets of entry guards

Reported by: arma Owned by: Sebastian
Priority: Medium Milestone: Deliverable-Sep2010
Component: Metrics/CollecTor Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: #1766 Points:
Reviewer: Sponsor:

Description

In theory, the results of #1918 (annotate torperf fetches by path) should let us simulate the expected performance of Tor users that use various combinations of guard nodes: just grab all the requests that use the guards you're simulating using, and make a torperf graph out of just those requests.

The problem is that the CBT feature will alter Tor's circuit build timeout based on the average build times of all nodes, not just the guards we're pretending we used, so we won't be able to capture the whole picture.

How different will the results be? To get some intuition, we should run several torperf install with cbt enabled and various sets of guards. Then when we have enough annotated torperf runs, we'll be able to compare the simulated results with the actual results, and make some decisions about what went wrong.

So the first question is: what combinations of guards should we try using? Mike, do you have any good guesses here?

Child Tickets

Attachments (2)

plot.R (3.5 KB) - added by karsten 9 years ago.
R code to make an ECDF graph of 3x3 torperf output files
Rplots.pdf (30.0 KB) - added by Sebastian 9 years ago.

Download all attachments as: .zip

Change History (18)

comment:1 Changed 9 years ago by Sebastian

Owner: changed from karsten to Sebastian
Status: newassigned

asn has started work on this, I'll take care of merging it with torperf.

comment:2 Changed 9 years ago by asn

[cc]

Changed 9 years ago by karsten

Attachment: plot.R added

R code to make an ECDF graph of 3x3 torperf output files

comment:3 Changed 9 years ago by karsten

See attached R code to make an ECDF graph of 3x3 torperf output files.

comment:4 Changed 9 years ago by mikeperry

This ticket technically blocks on bug #1974 for the TorCtl script to work 100% correctly. Said script lives at:

https://gitweb.torproject.org/sebastian/torperf.git/blob/bug1919:/entrycons.py

comment:5 Changed 9 years ago by Sebastian

Mike provided an updated TorCtl and the code is now live, running three torperf instances. One picks the three slowest guards, one the three fastest, and the third one picks them randomly like a regular client

comment:6 Changed 9 years ago by Sebastian

Looks like it works indeed, and that a normal client that picks guards randomly is pretty damn close to the case of a client picking the fastest guards (maybe because their weights are so huge that the probability of picking them is huge)

Changed 9 years ago by Sebastian

Attachment: Rplots.pdf added

comment:7 Changed 9 years ago by arma

A research question to ponder at some point: is there some simple way to recognize when you've picked a crummy set of guards, and if you're in the worst, say, 10 percentile then re-pick them?

comment:8 Changed 9 years ago by Sebastian

Resolution: implemented
Status: assignedclosed

Closing this bug for now, as we have torperfs set up that are collecting data and preliminary results are available. The research question should be asked somewhere else :)

comment:9 in reply to:  8 Changed 9 years ago by arma

Replying to Sebastian:

The research question should be asked somewhere else :)

I asked the research question at #1991.

comment:10 Changed 9 years ago by mikeperry

While adding the ratio support that I mentioned on or-dev to this script, I realized that it had a bug that could cause it to replace slow guards with fast ones. I've fixed this in my remote and added 'fastratio' and 'slowratio' modes.

https://gitweb.torproject.org/mikeperry/torperf.git/blob/bug1919fixes:/entrycons.py

comment:11 Changed 9 years ago by Sebastian

Resolution: implemented
Status: closedreopened

bleh. I'll merge it when I merge my branch (karsten: did it look ok?)

comment:12 Changed 9 years ago by arma

Any progress here?

Also, should we be publishing our torperf on metrics.tp.o?

comment:13 in reply to:  12 ; Changed 9 years ago by arma

Replying to arma:

Also, should we be publishing our torperf on metrics.tp.o?

I mean our torperf data. In particular, the paths chosen and measurements obtained.

Seems like (similar to mikeperry's bwauth's data) making that data public would mean other researchers could use it to learn new things.

comment:14 in reply to:  13 Changed 9 years ago by karsten

Replying to arma:

Replying to arma:

Also, should we be publishing our torperf on metrics.tp.o?

I mean our torperf data. In particular, the paths chosen and measurements obtained.

The paths chosen and measurements obtained are now available here.

comment:15 Changed 9 years ago by karsten

New torperfs using the entrycons.py script are deployed, data is available here. Changes to measurement-HOWTO are in branch bug1919_squashed in my public torperf repository. Sebastian, can you please merge my branch into torperf master and close this ticket?

comment:16 Changed 9 years ago by Sebastian

Resolution: fixed
Status: reopenedclosed

yes.

Note: See TracTickets for help on using tickets.