Onionperf issueshttps://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues2024-01-25T14:25:04Zhttps://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40072op-de8a-conflux is not producing any clear net measurements it seems2024-01-25T14:25:04ZGeorg Koppenop-de8a-conflux is not producing any clear net measurements it seemsWhile still in the .csv file `op-de8a-conflux` does not produce any clear net measurements it seems according to the attached .csv file ([torperf-2023-11-01-2023-12-21-public-5mb.csv](/uploads/c4f34a39811c58d3c15cb2843d1c94bf/torperf-202...While still in the .csv file `op-de8a-conflux` does not produce any clear net measurements it seems according to the attached .csv file ([torperf-2023-11-01-2023-12-21-public-5mb.csv](/uploads/c4f34a39811c58d3c15cb2843d1c94bf/torperf-2023-11-01-2023-12-21-public-5mb.csv)) for the 5MB downloads. Onion service measurements seem to be fine, though.HiroHirohttps://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40067Deprecation warnings in onionperf2024-01-16T14:25:26ZHiroDeprecation warnings in onionperfOnionperf needs a rewrite of how we are handling some of the data for analysis and visualization, some of the python libraries used have changed and we should check that things keep running before our code gets deprecated.Onionperf needs a rewrite of how we are handling some of the data for analysis and visualization, some of the python libraries used have changed and we should check that things keep running before our code gets deprecated.https://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40058Create Onionperf release template2023-03-03T08:35:33ZGeorg KoppenCreate Onionperf release templateWe had some back and forth during the last release (1.1) which indicates that we could benefit from some release template/check list. That list could contain (among other things) steps like:
1. Bump versions in all places (TODO: spell th...We had some back and forth during the last release (1.1) which indicates that we could benefit from some release template/check list. That list could contain (among other things) steps like:
1. Bump versions in all places (TODO: spell that one out) on `dev`
2. Add changelog entries
3. merge `dev` into `master`
4. tag a release, sign it, and push the taghttps://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40051Use pandas.concat() instead of frame.append() where needed2023-07-06T15:42:34ZGeorg KoppenUse pandas.concat() instead of frame.append() where neededWhen running the visualization step I got:
```
/home/gk/venv/lib/python3.9/site-packages/OnionPerf-0.9-py3.9.egg/onionperf/visualization.py:55: FutureWarning: The frame.append method is deprecated and will be removed from pandas in a fut...When running the visualization step I got:
```
/home/gk/venv/lib/python3.9/site-packages/OnionPerf-0.9-py3.9.egg/onionperf/visualization.py:55: FutureWarning: The frame.append method is deprecated and will be removed from pandas in a future version. Use pandas.concat instead.
main_df = main_df[ind].append(df[ind2])
```
We should check the whole onionperf code base for that issue and fix it (and maybe requiring a min `pandas` version, not sure; it seems the deprecation started with `pandas` 1.4.0).https://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40042Onionperf disk full alerts should have different thresholds.2022-03-21T15:43:23ZHiroOnionperf disk full alerts should have different thresholds.We have an alert on the onionperfs for when the disk is full for more than 80% but we should have different alerts for different thresholds.We have an alert on the onionperfs for when the disk is full for more than 80% but we should have different alerts for different thresholds.https://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40034More consistent string formatting2023-01-23T15:02:46ZAna CusturaMore consistent string formattingWe are using a mix of f-strings and regular python `format` throughout the codebase. For consistency, we should stick with one of them.We are using a mix of f-strings and regular python `format` throughout the codebase. For consistency, we should stick with one of them.https://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40033Develop and deploy tgen model resembling web browsing2023-01-23T15:02:41ZAna CusturaDevelop and deploy tgen model resembling web browsingThe current bulk transfer model, which does not use guards, is not very representative of a typical user workload.
We previously discussed developing a new tgen model to mimic loading a web page - and now we can also deploy guard-enabled...The current bulk transfer model, which does not use guards, is not very representative of a typical user workload.
We previously discussed developing a new tgen model to mimic loading a web page - and now we can also deploy guard-enabled instances.https://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40032Maintain daily country information for Onionperf guards2022-03-21T15:43:21ZAna CusturaMaintain daily country information for Onionperf guardsCurrently guard country information is looked up in Onionoo at analysis time, as we have no historical IP geolocation database.
This is fine when the measurements and the analysis are perfomed together, but re-analysing the data at a lat...Currently guard country information is looked up in Onionoo at analysis time, as we have no historical IP geolocation database.
This is fine when the measurements and the analysis are perfomed together, but re-analysing the data at a later date would result in the country information being very out of date.
A solution would be to produce another file at analysis time, containing the fingerprint to country mapping that can be re-used for future analyses.https://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40031Onionperf loses all state at midnight2022-10-31T19:47:40ZAna CusturaOnionperf loses all state at midnightWe have some experiments that keep or discard measurements based on the CBT state (whether the CBT is computed or not at the time of measurement). This is parsed from the logs at analysis time.
However, the logs are rotated at midnight....We have some experiments that keep or discard measurements based on the CBT state (whether the CBT is computed or not at the time of measurement). This is parsed from the logs at analysis time.
However, the logs are rotated at midnight. This means that if the CBT state changed in the logs for the previous day, this is not carried over - and measurements are discarded when they should not be. I've worked around this issue by making sure the instances which use guard rotation are started just after midnight, but a more robust idea is to keep some sort of state file for any values parsed from the logs that are used to filter measurements.https://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40022Update onionperf webserver and letsencrypt ansible roles2023-01-17T13:27:00ZAna CusturaUpdate onionperf webserver and letsencrypt ansible rolesThese ansible roles are needed on top of the onionperf playbook to run a webserver with certificates. The roles already exist, and just need finshing off and testing.These ansible roles are needed on top of the onionperf playbook to run a webserver with certificates. The roles already exist, and just need finshing off and testing.Sponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive placesAna CusturaAna Custurahttps://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40021Allow visualisations to have custom axis limits2022-03-21T15:43:22ZAna CusturaAllow visualisations to have custom axis limitsWhile OP can allow plotting multiple datasets along the same axis, sometimes the resulting graphs still need custom axis limits to be useful.
This can be implemented for the cumulative fraction graphs using a command line parameter.While OP can allow plotting multiple datasets along the same axis, sometimes the resulting graphs still need custom axis limits to be useful.
This can be implemented for the cumulative fraction graphs using a command line parameter.Sponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive placeshttps://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40011Confirm that port forwarding works correctly2023-01-23T14:49:58ZKarsten LoesingConfirm that port forwarding works correctlyWe ran into a configuration error with op-hk5 where we didn't set up port forwarding properly, and it took us two weeks to figure that out. @asn experienced a similar problem with not setting up port forwarding correctly. Let's see if we...We ran into a configuration error with op-hk5 where we didn't set up port forwarding properly, and it took us two weeks to figure that out. @asn experienced a similar problem with not setting up port forwarding correctly. Let's see if we can make this a little more usable.
How about OnionPerf performs a self test by connecting with its TGen client to its own TGen server directly? This could happen just once at startup, and only if listen port and connect port are different. Or does that not work, because port forwarding works differently for connecting from localhost as compared to connecting from an exit node? Are there alternatives?https://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/40007Develop at least one new OnionPerf model: An OnionPerf model defines the patt...2020-08-18T18:46:53ZGabagaba@torproject.orgDevelop at least one new OnionPerf model: An OnionPerf model defines the pattern of traffic that is generated by the instances for conducting a measurementFor example, a bulk download model can be used to measure time to first byte and time to last byte simulating the download of a large file. In contrast, a ping/echo service model would be used to learn the round-trip time from a client s...For example, a bulk download model can be used to measure time to first byte and time to last byte simulating the download of a large file. In contrast, a ping/echo service model would be used to learn the round-trip time from a client sending a ping to receiving a pong back from a server, which more closely models a real-time chat application. These models allow us to evaluate distinct circumstances and collect distinct metrics, all of which are currently unavailable with the existing OnionPerf model. We will evaluate new OnionPerf models that will allow us to measure different network workloads and deploy at least one instance of these permanently. Deploying a new OnionPerf model allows us to gain new insight into the Tor network by taking measurements that are currently unavailable.
(It was ticket #33324 that closed because it can not be included in the onionperf project in 2020).https://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/34231Document and maybe improve how we're mapping TGen transfers to Tor streams/ci...2023-01-23T14:48:54ZKarsten LoesingDocument and maybe improve how we're mapping TGen transfers to Tor streams/circuitsOnionPerf uses TGen to make transfers using a local Tor client. OnionPerf also uses Stem to connect to the Tor client's control port and register for control events.
This ticket is about documenting how we can map TGen transfers to Tor ...OnionPerf uses TGen to make transfers using a local Tor client. OnionPerf also uses Stem to connect to the Tor client's control port and register for control events.
This ticket is about documenting how we can map TGen transfers to Tor streams and circuits. OnionPerf did this to produce the .tpf output format (which we just killed in legacy/trac#34141). But we'll also need this functionality to implement legacy/trac#34218 or legacy/trac#33260.
Here's what we're doing in [metrics-lib](https://gitweb.torproject.org/metrics-lib.git/tree/src/main/java/org/torproject/descriptor/onionperf/OnionPerfAnalysisConverter.java#n121) right now to map transfers and streams:
- Index Tor circuits by their circuit ID.
- Index Tor streams by their source port; if there are two or more streams with the same source port, remember them all.
- Go through TGen transfers one by one. For each, extract the local source port.
- Go through Tor streams with the same source port and check if transfer end and stream end happened within 150 seconds.
- If there's a match, look up the corresponding circuit by circuit ID.
Note that OnionPerf took a simpler approach for producing .tpf files by remembering just one stream by source port and not applying that 150 seconds heuristic. The result was that some mappings were wrong. The approach taken by metrics-lib leads to a few missing mappings (probably as many as OnionPerf had), and apparently no wrong mappings.
Is there a way to have an exact mapping that doesn't require a heuristic? And is there a way to do it without having to wait for transfer and stream to end?Ana CusturaAna Custurahttps://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/34213Replace TorCtlParser with OnionTrace's control log parser2023-01-23T14:48:47ZKarsten LoesingReplace TorCtlParser with OnionTrace's control log parserSimilar to our plan to use TGen's analysis.py instead of OnionPerf's in legacy/trac#33974, the idea would be to avoid keeping our own copy of a Tor control even log parser in OnionPerf.
This work should start with an analysis how much w...Similar to our plan to use TGen's analysis.py instead of OnionPerf's in legacy/trac#33974, the idea would be to avoid keeping our own copy of a Tor control even log parser in OnionPerf.
This work should start with an analysis how much work this is going to save in the long run, and whether that justifies adding another dependency.
Feel free to adjust estimated points before starting to work on this if 2.0 doesn't make any sense.https://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 Metrics