The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-01-23T14:49:52Zhttps://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40009Create log file for OnionPerf's own log messages2023-01-23T14:49:52ZKarsten LoesingCreate log file for OnionPerf's own log messagesOnionPerf logs a couple of log message to the console and writes a few other messages to the `torctl.log` file. We should create a new log file for messages coming from OnionPerf itself. This log file should be placed in `onionperf-data/...OnionPerf logs a couple of log message to the console and writes a few other messages to the `torctl.log` file. We should create a new log file for messages coming from OnionPerf itself. This log file should be placed in `onionperf-data/`, so that we can archive it together with the other log files. It should probably be rotated, just like all other log files are. And it should contain the OnionPerf version writing this log file.OnionPerf: Scalability, Performance, Establishing Basline Metricshttps://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/33420Add CBT events to Onionperf result files2023-01-23T14:49:54ZAna CusturaAdd CBT events to Onionperf result filesAs I understand this, the results should record whether the CBT was set at the time of measurement. This could just be a CBT_SET True/False field in the tpf results file. The CBT resets in certain conditions, and this should be reflected...As I understand this, the results should record whether the CBT was set at the time of measurement. This could just be a CBT_SET True/False field in the tpf results file. The CBT resets in certain conditions, and this should be reflected in the results. The events should be parsed from the tor logs.
We should check with Mike if this meets the requirements.
* [ ] Blocked by [tpo/core/tor#40002](https://gitlab.torproject.org/tpo/core/tor/-/issues/40002)OnionPerf: Scalability, Performance, Establishing Basline Metricshttps://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/33392Add new metadata fields to json output2023-01-23T14:48:37ZAna CusturaAdd new metadata fields to json outputAdd new metadata fields for experimental measurements to the onionperf json output.Add new metadata fields for experimental measurements to the onionperf json output.OnionPerf: Scalability, Performance, Establishing Basline Metricshttps://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/33391Add new metadata fields and definitions2023-01-23T14:48:40ZAna CusturaAdd new metadata fields and definitionsDefine the instance metadata fields to help us differentiate experimental measurements.Define the instance metadata fields to help us differentiate experimental measurements.OnionPerf: Scalability, Performance, Establishing Basline Metricshttps://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/33259Store measurements in a local database to reduce plotting time2023-01-23T14:48:44ZKarsten LoesingStore measurements in a local database to reduce plotting timeWe want to add graphs to OnionPerf that compare larger numbers of measurements. We also plan to add more parameters to plot different subsets of measurements. Having a local database for storing measurements and decoupling the parsing st...We want to add graphs to OnionPerf that compare larger numbers of measurements. We also plan to add more parameters to plot different subsets of measurements. Having a local database for storing measurements and decoupling the parsing step from the plotting step might reduce overall plotting time. This will be particularly useful when we include graphs based on Tor descriptors like flags or bandwidth or consensus weight.
Part of this ticket will be to figure out which database to use. Maybe we need to experiment with SQLite to see if it's fast enough for this purpose or whether we need something like PostgreSQL here.OnionPerf: Scalability, Performance, Establishing Basline Metricshttps://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/30798Develop and deploy tgen model resembling ping2023-01-23T14:48:30ZKarsten LoesingDevelop and deploy tgen model resembling pingAt last week's tor-scaling meeting we discussed developing a second tgen model that resembles a ping service and deploying an OnionPerf instance with that model.
The current default tgen model in OnionPerf makes a new download every fiv...At last week's tor-scaling meeting we discussed developing a second tgen model that resembles a ping service and deploying an OnionPerf instance with that model.
The current default tgen model in OnionPerf makes a new download every five minutes. That's a tiny request with a response of 50 KiB or 1 MiB or 5 MiB.
This new model would send a tiny request once per second for, say, five minutes, and receive a tiny response back to each of these requests.
We wouldn't have to write analysis code that produces something like a .tpf file right now but could start with analyzing the raw logs for this experiment and extract some hopefully useful visualizations.
I could deploy this new model on my local machine (if it uses an onion service).
Raising priority to high, because it would be great to ideally get this deployed before All Hands.
Thoughts?OnionPerf: Scalability, Performance, Establishing Basline Metrics