Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T18:12:31Zhttps://gitlab.torproject.org/legacy/trac/-/issues/1841Implement node churn and uptime statistics2020-06-13T18:12:31ZTracImplement node churn and uptime statisticsI spent some time this summer designing a schema to support tracking of relay uptime and churn statistics. The relay churn statistic should be split up by platform, version, and guard/exit status for a more fine-tuned insight into the ne...I spent some time this summer designing a schema to support tracking of relay uptime and churn statistics. The relay churn statistic should be split up by platform, version, and guard/exit status for a more fine-tuned insight into the network. The uptime statistic should be split into guard/exit status and version, as it only sees individual platforms. Also, the data the query returns currently is good for a time graph (similar to Karsten's [Windows relay uptime](https://trac.torproject.org/projects/tor/ticket/1721) graph), but it could be portrayed as a box-plot distribution.
Relay churn is calculated from the unique routers from one week/month/year that appear in the following week/month/year, and is relatively straightforward to calculate. However, this query could use some optimization because it takes a very long time to group individual routers by the times they appear.
Relay uptime is more difficult to calculate with a database query because "uptime sessions" need to be calculated in order to get a correct average. This is near impossible to do with a database query, and must be done programatically (with cursors in pl/pgsql or elsewhere).
**Trac**:
**Username**: kjbbbKarsten LoesingKarsten Loesing