Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2011-05-03T06:37:19Zhttps://gitlab.torproject.org/legacy/trac/-/issues/2958Work with Karsten on TorPerf Experiments2011-05-03T06:37:19ZMike PerryWork with Karsten on TorPerf ExperimentsThis ticket is to catalog my portion of the work with karsten on #2769. I plan to help with a few experiments:
- Determine new guard cutoff: 2pts
- Determine optimal CircWindow: 6pts
- Throttle clients network-wide: 4pts
- Disable EWMA: ...This ticket is to catalog my portion of the work with karsten on #2769. I plan to help with a few experiments:
- Determine new guard cutoff: 2pts
- Determine optimal CircWindow: 6pts
- Throttle clients network-wide: 4pts
- Disable EWMA: 1pt
- Extra luck point: 1ptMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/2868Fix weird torperf results due to bad guard choices2017-12-06T04:45:21ZMike PerryFix weird torperf results due to bad guard choicesEntrycons.py crashed, causing us to get bad results for the cbt experiments. It turns out that we weren't properly waiting for all descriptors to arrive. We need to delay setting guards until we have something like 99% of all descriptors...Entrycons.py crashed, causing us to get bad results for the cbt experiments. It turns out that we weren't properly waiting for all descriptors to arrive. We need to delay setting guards until we have something like 99% of all descriptors in the current consensus.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/2859Transform perf tech report outline into latex draft2011-04-18T13:23:31ZMike PerryTransform perf tech report outline into latex draftThe submission deadline is Apr 25th, so we should have a passable latex draft by the end of this iteration. We also should try to get in a few more experiments, but I will write a new ticket for that.The submission deadline is Apr 25th, so we should have a passable latex draft by the end of this iteration. We also should try to get in a few more experiments, but I will write a new ticket for that.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/2774Write down an outline of the performance tech report2011-04-01T23:24:00ZKarsten LoesingWrite down an outline of the performance tech report#2769 lists the experiments and evaluations that we want to run and put into the performance tech report. At the same time we should start writing the tech report.
This ticket is about writing a rough draft of the report containing the...#2769 lists the experiments and evaluations that we want to run and put into the performance tech report. At the same time we should start writing the tech report.
This ticket is about writing a rough draft of the report containing the motivation, structure, and maybe the expected conclusions. We should use this draft to collect our ideas and early results in a single document.
Turning the draft into something readable will be a new ticket.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/2771Reproduce CircWindow and EWMA experiments w/ new torperfs2012-03-08T19:27:50ZMike PerryReproduce CircWindow and EWMA experiments w/ new torperfsWe should reproduce the circwindow and ewma experiments with the new torperf runs. Or, we should make sure we have good results laying around from when we last tested this.We should reproduce the circwindow and ewma experiments with the new torperf runs. Or, we should make sure we have good results laying around from when we last tested this.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/2770Perform experiments to determine optimal circuit build timeout cutoff2011-04-05T00:54:35ZMike PerryPerform experiments to determine optimal circuit build timeout cutoffWe need to perform a series of experiments to determine the optimal cbtquantile cutoff value that we're comfortable with using on the real network. Something like 50, 60, 70, and 80. We then need to observe the behavior of the torperf cl...We need to perform a series of experiments to determine the optimal cbtquantile cutoff value that we're comfortable with using on the real network. Something like 50, 60, 70, and 80. We then need to observe the behavior of the torperf clients.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/2769Experiments and Data for Tor Performance Tech Report2020-06-13T17:46:49ZMike PerryExperiments and Data for Tor Performance Tech ReportKarsten and I intend to write a tech report covering the use of TorPerf and other metrics to measure tor network performance, and to determine if certain performance tweaks results in improved or degraded performance. This is the parent ...Karsten and I intend to write a tech report covering the use of TorPerf and other metrics to measure tor network performance, and to determine if certain performance tweaks results in improved or degraded performance. This is the parent ticket for this effort.
[[TicketQuery(parent=#2769,format=table,col=owner|priority|summary|points|actualpoints,order=priority)]]Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/2766Enforce using a fresh circuit for a new Torperf run2017-04-28T15:41:33ZKarsten LoesingEnforce using a fresh circuit for a new Torperf runOur current approach to enforce using a fresh circuit for a new Torperf run is that we set `MaxCircuitDirtiness` to something smaller than the interval at which we start new Torperf runs. But whenever we forget to update this setting, T...Our current approach to enforce using a fresh circuit for a new Torperf run is that we set `MaxCircuitDirtiness` to something smaller than the interval at which we start new Torperf runs. But whenever we forget to update this setting, Tor won't really tell us that something's wrong. We only learn that when merging `.data` and `.extradata` files.
We should switch to sending a NEWNYM signal and stop messing with `MaxCircuitDirtiness`. Below is a patch that Mike wrote, but that doesn't really fit in entrycons.py, because not all Torperf runs use that script. Maybe we should apply this patch when we merge the various Python scripts in #2565?
```
commit 6e79ca00fb923d90e63bf10f0e3913ef6641eb5c
Author: Mike Perry <mikeperry-git@fscked.org>
Date: Wed Mar 16 04:46:09 2011 -0700
Fix entrycons.py to send a NEWNYM signal after every stream.
diff --git a/entrycons.py b/entrycons.py
index d1c8f34..41678fd 100755
--- a/entrycons.py
+++ b/entrycons.py
@@ -16,6 +16,11 @@ class EntryTracker(TorCtl.ConsensusTracker):
self.speed = speed
self.set_entries()
+ def stream_status_event(self, event):
+ # Every time a stream closes, send a NEWNYM signal
+ if event.status == "CLOSED" or event.status == "FAILED":
+ self.c.send_signal("NEWNYM")
+
def new_consensus_event(self, n):
TorCtl.ConsensusTracker.new_consensus_event(self, n)
TorUtil.plog("INFO", "New consensus arrived. Rejoice!")
@@ -120,7 +125,7 @@ def main():
conn = TorCtl.connect(HOST, port)
- conn.set_events(["NEWCONSENSUS", "NEWDESC", "NS", "GUARD"])
+ conn.set_events(["STREAM", "NEWCONSENSUS", "NEWDESC", "NS", "GUARD"])
conn.set_option("StrictEntryNodes", "1")
conn.set_option("UseEntryNodes", "1")
```https://gitlab.torproject.org/legacy/trac/-/issues/2690Compare circuit build timeouts to Torperf completion times2012-03-13T15:38:34ZKarsten LoesingCompare circuit build timeouts to Torperf completion timesThis is a follow-up ticket to #2586 which was part of our March 5 Torperf iteration.
I'm leaving priority at normal, because we might better answer this question by playing with the cbtquantile consensus parameter. But we still want to...This is a follow-up ticket to #2586 which was part of our March 5 Torperf iteration.
I'm leaving priority at normal, because we might better answer this question by playing with the cbtquantile consensus parameter. But we still want to answer this question sometime.https://gitlab.torproject.org/legacy/trac/-/issues/2687Write Python version of filter.R to parse Torperf's new .mergedata format2020-06-13T00:17:35ZKarsten LoesingWrite Python version of filter.R to parse Torperf's new .mergedata formatOnce we have completed the improved `consolidate_stats.py` script in #2672, we should update our `filter.R` script to process the new `.mergedata` format instead of `.data` files. We could start with parsing the 20 fields in `.mergedata...Once we have completed the improved `consolidate_stats.py` script in #2672, we should update our `filter.R` script to process the new `.mergedata` format instead of `.data` files. We could start with parsing the 20 fields in `.mergedata` coming from `.data` files. Once we have that under control, we might extend `filter.R` to parse new fields coming from `.extradata` files. See [my comment to #2618](https://trac.torproject.org/projects/tor/ticket/2618#comment:8) for an implementation idea.https://gitlab.torproject.org/legacy/trac/-/issues/2672Fix bugs/issues with consolidate_stats2020-06-13T00:07:00ZMike PerryFix bugs/issues with consolidate_statsQuoting karsten:
I think there's a bug in this script: Whenever we skip a line in a .data file, because that line represents a failure, we might get out of sync with the .extradata file and stop writing any data to .mergedata. You shoul...Quoting karsten:
I think there's a bug in this script: Whenever we skip a line in a .data file, because that line represents a failure, we might get out of sync with the .extradata file and stop writing any data to .mergedata. You should be able to reproduce this bug with the Torperf 50KB run (https://metrics.torproject.org/data/torperf-50kb.data https://metrics.torproject.org/data/torperf-50kb.extradata). The last line in the result has CIRC_ID=4384. If I delete the line in .extradata starting with CIRC_ID=4397, the result has more entries than before. I think the fix is to distinguish between absolute slack of up to 1 second and a time difference of, say, more than 1 minute.
Also, is there a way to include timed out runs in the .mergedata, too? We do include failures, so by including timeouts, we wouldn't have to parse the original files for timeouts/failures anymore. This could be a new ticket, I'd just like to know whether it's possible.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/2565Redesign Python parts in Torperf2020-06-13T01:39:12ZKarsten LoesingRedesign Python parts in TorperfWe're stuffing more and more functionality into Torperf. See #2551 for outputting circuit build times and #2554 for adding hidden service time components.
I think it's time to consider a redesign of the Python parts. Having a Python s...We're stuffing more and more functionality into Torperf. See #2551 for outputting circuit build times and #2554 for adding hidden service time components.
I think it's time to consider a redesign of the Python parts. Having a Python script for writing controller events to disk, a Python script for influencing guard selection, and a cronjob for actually making the requests is already hackish. Adding circuit build times and hidden-service events stretches this even more.
We could have a single Python program that reads from a configuration file what to do, starts Tor, connects to its control port, periodically calls the C program to make requests, and collects all the data we want. This would also make it much easier to set up Torperf.
Sebastian, Mike: Does this make sense?https://gitlab.torproject.org/legacy/trac/-/issues/2554Write script to reconstruct hidden service time components from controller ev...2020-06-13T00:04:27ZRoger DingledineWrite script to reconstruct hidden service time components from controller eventsWhen we get #1944 going, we're going to start wondering what the breakdown of "time before connected cell" is.
Does torperf get its statistics of time breakdown just from the socks port, or does it learn things over the control port too...When we get #1944 going, we're going to start wondering what the breakdown of "time before connected cell" is.
Does torperf get its statistics of time breakdown just from the socks port, or does it learn things over the control port too, or what? We should figure out what time components we want to track, and then figure out how to export them so torperf can track them for posterity.
We may also find that we want to remember the circuits for the other components of the rendezvous, similar to the extension we're considering for #2551.Tor: 0.2.9.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/2543Create graphs of #1919 torperfs2020-06-13T17:49:45ZMike PerryCreate graphs of #1919 torperfsIt would be great if we had some sort of output of the 15 torperf runs that are running somewhere. Right now, afaik, all that data will just go into a hole until someone decides to dig it up.
In my ideal world, we'd have the ability to ...It would be great if we had some sort of output of the 15 torperf runs that are running somewhere. Right now, afaik, all that data will just go into a hole until someone decides to dig it up.
In my ideal world, we'd have the ability to see all the graphs on https://metrics.torproject.org/performance.html for each one of these runs, right there live on the website.
If this is too much work to be done in a reasonable amount of time, I'd settle having just the timing graphs for each of the 15 runs in a directory I can access somewhere.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/1944Set up a Torperf to a hidden service2020-06-13T14:08:46ZRoger DingledineSet up a Torperf to a hidden serviceIt would be great to get an ongoing torperf run that's accessing a hidden service, so we can track performance of those over time also.
The simple part here is setting up a hidden service that's probably not the performance bottleneck, ...It would be great to get an ongoing torperf run that's accessing a hidden service, so we can track performance of those over time also.
The simple part here is setting up a hidden service that's probably not the performance bottleneck, and setting up a torperf install as usual.
The complex part here is that the Tor client will cache the hidden service descriptor, and maybe even the rendezvous circuit (in the case of the every-five-minute 50kb fetch), skewing our results.