Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:16:36Zhttps://gitlab.torproject.org/legacy/trac/-/issues/24061Collect Baseline Measurements for Different Android Performance Metrics2020-06-13T15:16:36ZAlexander Færøyahf@torproject.orgCollect Baseline Measurements for Different Android Performance MetricsAs part of our Sponsor 8 efforts, one of our goals is to enhance CPU, memory, and battery utilization on Android.
To do so we should collect an initial set of "baseline" measurements such that we can draw conclusions on whether our opti...As part of our Sponsor 8 efforts, one of our goals is to enhance CPU, memory, and battery utilization on Android.
To do so we should collect an initial set of "baseline" measurements such that we can draw conclusions on whether our optimisation approaches work or not.
This is the master ticket for this project and the child tickets will contain more concrete approaches to collecting these measurements.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24062CPU profiling of Tor on Android device2020-06-13T15:16:37ZAlexander Færøyahf@torproject.orgCPU profiling of Tor on Android deviceUsing Android's simpleperf (or other tools) to collect CPU measurements in a reproducible manner on a set of Android devices.
It is important that we ensure that we can reproduce the results quickly and not require a test to run over mu...Using Android's simpleperf (or other tools) to collect CPU measurements in a reproducible manner on a set of Android devices.
It is important that we ensure that we can reproduce the results quickly and not require a test to run over multiple days/nights - this was a big problem with the sponsor 4 measurements where we used Chutney over a longer period of time.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24065Decide on initial optimisation strategy for Android performance work2020-06-13T15:16:38ZAlexander Færøyahf@torproject.orgDecide on initial optimisation strategy for Android performance workBased on the results from the initial set of measurements, we should figure out where we should start doing optimization work.
This is the master ticket for this: concrete optimisation plans should be added as child tickets with the s8-...Based on the results from the initial set of measurements, we should figure out where we should start doing optimization work.
This is the master ticket for this: concrete optimisation plans should be added as child tickets with the s8-perf and/or the s8-battery keyword and s8-YYYYMM keyword for when we expect to finish working on the optimisation.Tor: 0.3.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24605Log main loop iteration count as part of the heartbeat messages2020-06-13T15:18:49ZAlexander Færøyahf@torproject.orgLog main loop iteration count as part of the heartbeat messagesWe should log information about the main loop iteration count as part of the heartbeat messages to gain a better understanding on why we are waking up and to be able to compare our progress with waking up less.
We should only enable thi...We should log information about the main loop iteration count as part of the heartbeat messages to gain a better understanding on why we are waking up and to be able to compare our progress with waking up less.
We should only enable this when the user configures their Tor to log and collect this information.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25762Make periodic events array with flags including when they are enabled/disabled2020-06-13T15:24:20ZDavid Gouletdgoulet@torproject.orgMake periodic events array with flags including when they are enabled/disabledThis is part of #25500 bigger ticket.
The goal here is to put the periodic events (not the per-second callbacks) into an array of objects where an object has flags and enable/disable switch.
So far, the flags would indicate conditions ...This is part of #25500 bigger ticket.
The goal here is to put the periodic events (not the per-second callbacks) into an array of objects where an object has flags and enable/disable switch.
So far, the flags would indicate conditions on when to run the callbacks. One of them would be "do not run if disable network is on".
The object also needs to tell for which "tor entity" the callbacks applies. For instance, a certain callback would only apply to Client. Or a callback is only for Dirauth.
Probably more (or less) things will be added to the object as we start implementing.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24374Reduce monotime_coarse_absolute_msec() usage2020-06-13T15:18:52ZAlexander Færøyahf@torproject.orgReduce monotime_coarse_absolute_msec() usage`monotime_coarse_absolute_msec()` is making a lot of calls to the compiler generated function `__udivdi3` to the point where it pops up in our profiling on Android.
We should reduce this usage and ensure the high amount of calls to `__u...`monotime_coarse_absolute_msec()` is making a lot of calls to the compiler generated function `__udivdi3` to the point where it pops up in our profiling on Android.
We should reduce this usage and ensure the high amount of calls to `__udivdi3` goes away.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/23354Remove deterministic download schedule code and configs2020-06-13T15:16:59ZteorRemove deterministic download schedule code and configsUnder exponential backoff, download schedules contain the ~~maximum time we will wait, even if the random amount is larger.~~ initial time we will wait, and everything else is random exponential from that point onwards.
~~But in most ca...Under exponential backoff, download schedules contain the ~~maximum time we will wait, even if the random amount is larger.~~ initial time we will wait, and everything else is random exponential from that point onwards.
~~But in most cases, the random amount is much smaller than the maximum, so we could replace the item with the actual maximum, or delete it from the schedule altogether. (On the public network, the maximum is 4x the last entry, on test networks, it's 3x.)~~
So once we're sure that we will never revert to deterministic schedules, we should make each schedule into a single initial value, and remove the deterministic code.
We should make these changes based on the schedules in #23347.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/24151rip out everything related to DL_SCHED_DETERMINISTIC2020-06-13T15:16:58ZTaylor Yurip out everything related to DL_SCHED_DETERMINISTICIt looks like the only code that uses DL_SCHED_DETERMINISTIC is testing code. We should rip out all code related to it. This will make it easier to refactor in the future and reduce the binary size by eliminating dead code.It looks like the only code that uses DL_SCHED_DETERMINISTIC is testing code. We should rip out all code related to it. This will make it easier to refactor in the future and reduce the binary size by eliminating dead code.Tor: 0.3.3.x-final