15:00:09 #startmeeting metrics team 15:00:09 Meeting started Thu Apr 9 15:00:09 2020 UTC. The chair is karsten. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:09 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:00:27 irl: okay. :) 15:00:34 please add topics to the agenda. 15:00:38 https://pad.riseup.net/p/tor-metricsteam-2020.1-keep 15:02:05 alright, shall we start? 15:02:12 ok 15:02:24 OnionPerf alerts (karsten) 15:02:32 damn they are annoying 15:02:38 I noticed frequent alerts coming in. 15:02:42 is everything okay? 15:02:52 good news: new thing with better timeouts and doing retries before it alerts is what i've been working on 15:03:03 also will be checking load, disk space, and swap usage 15:03:12 should be deployed tonight/tomorrow 15:03:17 nice! 15:03:24 question answered then. 15:03:27 thanks! 15:03:37 sorry i've just ignored the barrage of emails, i figured it was better to do the long term fix instead of spending time on short term silence 15:03:53 that's fine. I was just worried that it's broken. 15:03:58 I can ignore emails just fine. :) 15:04:11 they should be a lot more meaningful next week 15:04:12 okay, next topic? 15:04:14 ok 15:04:17 sounds great! 15:04:22 User number estimate updates (karsten) 15:04:37 just saying that I'm going to deploy these fixes soon. 15:04:43 #18167 and #18203. 15:05:05 I wrote on the ticket that I'd wait for a week, but now that you commented, I don't see why I should wait longer. 15:05:16 thanks for taking a look, by the way! 15:05:19 sounds great 15:05:47 okay, moving on? 15:05:52 ok\ 15:06:05 Small Update on tor metre (dennis) 15:06:27 Sorry was just looking at those ticks. super interesting stuff! 15:06:36 Will try to find time to read them more thoroughly later 15:06:49 (As these counts came up in Mozilla context last Summer) 15:07:01 With regard to Tor Metre, just a small update from me. 15:07:49 Work on this has been going pretty well. Recent topic has been recording the state of the Tor Browser instance in an agnostic and compressible way. 15:08:20 Seeing some strange divergences between long running Tor Browser 'sessions' where they seem to fall into a performance tarpit. 15:08:33 Unclear whether it is a bug in the current framework or a bug in Tor 15:09:17 Have now got a solution where after each page load we take a compressed diff of the state files and save it as part of the result. So we can 'play back' Tor's state. 15:09:41 (Provided we kill Tor Browser between web browsing sessions) 15:10:04 However, last 10 days work has been a bit stalled because I have been re-tasked with some of this COVID Contact Tracing stuff 15:10:29 So progress is now a little slower, but still moving forwards 15:10:53 regarding that performance tarpit: you're looking at a single tor browser session over time, and that starts fast, gets slow, and then gets fast again? 15:11:00 That's all from me, just wanted to update you where the project was and that it was still live. 15:11:11 and the session would be over a couple hours or so? 15:11:13 Sometimes it just gets slow and gets stuck like that 15:11:35 In this case, it persists between days. We stop the VM and bring it back later and its still slow. 15:11:44 slow guard maybe? 15:12:16 That is my assumption as well, but we aren't at the threshold where guard rotation should happen 15:12:37 And often the guards in the state file are up 15:12:53 up, but maybe overloaded. 15:13:20 Anyway - need to do it scientifically, as we don't want to just say "we see this odd thing and figure it must be X". So having these diffs and logging some more stuff will help 15:13:46 But that's all from me, just wanted to let you know things were still progressing 15:13:49 does the state file contain everything you need? 15:14:03 is it being updated before you do the diff? 15:14:21 but yes, worth investigating scientifically. 15:14:31 sounds fun! 15:14:38 If we ask Tor Browser to quit, we figure it should have everything to recover the state for the next session and as it persists, it must be in that state somewhere 15:14:46 ok. 15:14:52 I do have a question about https://consensus-health.torproject.org/g 15:15:11 without g at the end, yes? 15:15:20 I wasn't aware this existed but stumbling into it from an IRC link I think. Is it discoverable from the metrics pages? 15:15:24 ah yes sorry 15:15:49 https://metrics.torproject.org/services.html 15:15:52 from that page, yes. 15:16:22 I was wondering if it would make sense to give its own tab? 15:16:23 could it be made even more visible? yes. :) 15:16:38 Ah thanks, yep I missed it 15:16:45 i would argue that consensus health isn't really a tor metrics thing 15:17:09 I would argue that the consensus contain useful metrics about Tor 15:17:25 And there are certainly metrics about variances in consensus votes which might be of interest 15:17:29 yeah but it's not using collector, uses it's own parser implementation, own schedule etc 15:17:51 is it linked from www.tp.o? 15:18:10 or what's the state of the dev portal? 15:18:21 it was linked from tpo before the website redo 15:18:26 I don't know myself - I just saw it on IRC 15:19:26 dennis_jackson: i don't mean to say that consensus health isn't useful, just that it's completely isolated from the rest of tor metrics and isn't maintained by tor metrics 15:19:43 there is an argument to be made that having diverse tools helps resilience 15:20:31 but i'd like to see tor metrics performing similar checks as consensus health and logging how often they occur in a queryable time-series db in the future, instead of just an html archive and mailing list 15:21:13 Okay, I understand that perspective. I think there's a good argument for bringing it in house. Right now we have the current sbws vs torperf issue. This will no doubt happen again. 15:21:49 I think it would be fantastic if Tor Metrics was providing those measurements in a robust way. But as you say, obviously more work and there is value in multiple sources 15:21:49 in fact, consensus health started as being a metrics thing. 15:22:41 we should link to it from the metrics website, so that people find it. 15:22:55 we do, but if there's a way to make that link more visible, we should try that. 15:23:31 there's also the data portal project under way which will make metrics things easier to find. 15:24:12 another alternative would be to link it from the tor dev portal, when that exists. 15:24:30 we would definitely link consensus health in the data portal 15:24:47 i don't know where the network health stuff will go, but it should also go there 15:24:52 community? 15:24:56 That sounds great :) 15:25:18 maybe community, yes. 15:26:53 who would know this? or which component would this ticket get filed to? 15:27:18 dennis_jackson: and would you want to file this ticket? 15:27:29 #tor-www irc maybe 15:27:36 someone there would know 15:28:30 Happy to help but unsure of the context for who to talk to and what the desired outcome is 15:28:44 Is this for the data portal? dev portal? something else? 15:29:36 the data and dev portals do not exist yet. the community portal does. 15:30:06 or maybe it's still okay if we leave the link on the metrics website for now. 15:30:18 until the other portals exist. that's a long process. :) 15:30:23 Ah :) 15:31:10 alright. out of topics? 15:31:19 That's all from me :) 15:31:29 thanks for the update! 15:31:42 np, thanks for the input and for pointing me to the right page on Tor Metrics 15:32:28 irl: anything else from you? 15:32:33 nope 15:32:55 cool! thanks, everyone! talk to you next week! 15:33:01 #endmeeting