14:59:46 #startmeeting metrics team 14:59:46 Meeting started Thu Apr 6 14:59:46 2017 UTC. The chair is karsten. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:59:46 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:59:57 https://pad.riseup.net/p/3M7VyrTVgjlF <- agenda 15:00:09 Sebastian: ready to start with your topics? 15:00:19 ok 15:00:26 - a couple of topics that came up during AMS (Sebastian) 15:00:28 great! 15:00:38 - it'd be great if we had a feature where we can see which dirauth dictated the median for a given relay wrt bandwidth weight (perhaps also with #relays over time) 15:00:43 hi! 15:00:48 hi hiro! 15:00:55 people seemed confused about that topic. What's the confusion? 15:01:03 what kind of feature? 15:01:12 one graph now? 15:01:20 something on tor metrics? 15:01:21 I'm thinking in consensus-health 15:01:27 ah! 15:01:27 where we list the relays 15:01:51 it could be cool if there were an indication which dirauth(s) is/are the median 15:01:53 that would be something for tjr, right? 15:01:57 I don't know 15:02:03 is tjr not part of the metrics team? 15:02:13 not a regular attendee of these meetings, no. 15:02:41 number of relays might be something for metrics 15:02:42 over time 15:03:04 But I have highlights! 15:03:07 And sometimes I'm at my desk! 15:03:11 hehe 15:03:17 hi! 15:03:54 regarding the number of relays thing, I wonder if such a graph would be too specific for the average tor metrics visitor. 15:04:08 but how about this: we can make one graph now and then see how interesting that would be. 15:04:10 I think this is something I can get onto consensus health in a weak form fairly easily; and in a strong form over the next week...ish? Don't slave me to that 15:04:23 maybe. Do we have a better place for stuff that's important for dirauths but boring for the average metrics page visitor? 15:04:23 Can you open a ticket and assign it to me just in case? 15:04:38 tjr: sure 15:04:39 Sebastian: consensus-health? 15:05:01 consensus-health doesn't do history 15:05:14 it would be cool to analyze historical data for this 15:05:18 https://consensus-health.torproject.org/graphs.html 15:05:36 so, doing a historical analysis once is easy. 15:05:47 finding a place and keeping it updated is harder. 15:06:02 Besides the graphs, we also save 2 (or 3?) weeks of detailed pages. 15:06:30 My plan was to get the authority who described the bw highlighted today (hopefully) and make a graph showing stack of bwauth 'soon' 15:07:25 so, should we do a one-off analysis of the past years? would that be useful? 15:07:54 unless you were planning to import years of data, tjr? 15:08:07 I was not :) 15:08:22 Sebastian: ^ would that be potentially useful? 15:08:56 Sebastian: and if so, can you create a ticket for this? 15:09:12 yeah 15:09:15 that'd be useful 15:09:25 ideally we'd have a way to redo the analysis on demand 15:09:31 that's easy, too. 15:09:33 but having it for the past year would already tell us a lot 15:09:42 will create tickets 15:09:46 okay. please put this all in the ticket. 15:09:48 ok, I think I took up a lot of meeting time already 15:10:05 well, let's go through the other two quickly then. 15:10:10 - webstats takeover and using them for graphs (mail from isa iirc) 15:10:24 I think we already put this on our Q2 list. 15:10:28 yes. 15:10:30 I don't really have anything to say for that, I keep maintaining it but the sooner you do it the better :) 15:10:36 right. 15:10:42 we'll hurry 15:10:48 as much as we can :-) 15:11:01 - bwauth feeding servers monitoring 15:11:11 the thinking last week was that tor's nagios could do this. 15:11:26 This is very interesting to me. 15:11:37 hiro: ^ 15:11:38 I was thinking it's like torperf or something 15:11:55 where we just try to reach the bwauths from non-tor and see if they're very slow. 15:11:58 yep I think nagios could do that 15:12:05 ok 15:12:11 I have three checks I perform on my bwauth: one to detect a low number of relays, one to detect if a scanner hasn't completed recently, and one to detect if the relay percentaged measured is too low. 15:12:11 can nagios warn if the server is slow? 15:12:16 but we should see first 15:12:19 Are those the types of things we were thinking about? 15:12:31 tjr: no this is for the feeding server 15:12:38 there are a number of checks... I do not know nagios very well to be honest 15:12:41 Oh where the files are hosted? 15:12:44 Okay 15:12:49 yeah 15:12:56 maybe nagios is a bit overkill though if all we want to know is if the server is slow or not 15:13:01 I'm thinking the other checks are very important too, but separate 15:13:15 hiro: ideally I'd want a notification if it turned out to be slow. 15:13:17 we could do a ping check or something of the like 15:13:20 Like Damian's script 15:13:23 yeah 15:13:25 that downloads consensus from driauths 15:13:26 dirauths* 15:13:39 maybe it could download from the feeding server too. 15:13:41 sounds plausible, too. 15:13:58 nagios can run shell scripts; so that should work. 15:14:02 Please let me know if/when this happens, as I use Linus' server which should be added (and wouldn't be if I didn't mention it. 15:14:13 (FWIW if anyone other bwauth wants me to run the checks against their's I can, we can arrange it outside of this meeting.) 15:14:42 if we could define what we want from nagios I could find this out and try to see how we can do it? 15:15:02 so would be good for me to know if we should run a set of scripts or implement a number of checks... 15:16:00 sounds like a ticket for further discussion. :) 15:16:03 I'm thinking this might not be a good fit for nagios 15:16:09 rather I'll talkt to atagar 15:16:12 in which case it would be a DocTor ticket. 15:16:12 and then open the tickets 15:16:19 sounds good! 15:16:38 alright, moving on to the next topic? 15:16:56 3, 2, 1... - Onionperf deployment (hiro) 15:17:00 yep 15:17:10 so today we had a major update from Rob 15:17:15 yay! 15:17:21 and we should start to see new measurements from tomorrow 15:17:29 is there any way to get measurements today? 15:17:37 as a sample on the ticket? 15:17:42 or, attachment? 15:17:43 I can check the logs and generate some yes 15:18:05 cool! 15:18:17 and we'll have to delete older data again, right? 15:18:31 yep if we do not want that we will have to 15:18:47 well, 50% is timeouts. 15:18:54 we could filter that, but ugh. 15:19:06 yeah it is not a big deal do delete data 15:19:08 it's surprisingly difficult to add new data sources.. 15:19:18 yes! 15:19:33 thanks for your help there! :) 15:19:49 okay, anything else on the onionperf topic for today? 15:20:10 i think there isn't much else.. rob is discussing some changes but that won't probably affect us that much 15:20:24 yep. 15:20:44 okay, 15:20:46 - In-memory stats (karsten) 15:20:48 when the twistd server will be remove I will just serve the xml w the nginx directly 15:20:55 yep moving on :) sorry about it 15:21:02 sounds good! 15:21:18 alright, in-memory stats. 15:21:37 simulation? 15:21:40 it's likewise surprisingly difficult to find time to focus on this simulation.. 15:21:50 but I found two bugs in the simulation code. 15:21:51 yes, 15:22:02 that's good. 15:22:02 one related to binning negative values. 15:22:13 and one related to de-binning reported values more than once. 15:22:33 but this is still work in progress. 15:22:43 Can I help? 15:22:53 Timewise. 15:23:22 maybe let me keep this for tomorrow and the weekend and then hand over or discuss what I have on monday. 15:23:31 fine. 15:23:38 It's not too urgent. 15:23:58 unless we find out that our current plan for adding noise does not work out. 15:24:11 in which case we'd need to find an alternative really quickly. 15:24:21 I think it'll work. 15:24:36 I hope so! 15:24:50 okay, nothing else on the simulation topic. quite related... 15:24:53 - tech report (iwakeh): restructuring and adding the AMS results 15:25:02 yes, the theory behind 15:25:12 also work in progress 15:25:18 but I found a good way 15:25:26 for re-reading reviewing 15:25:39 I'm going to use latexdiff, which will 15:25:49 make changes nicely visible. 15:26:06 okay, curious to see that. :) 15:26:27 yes, it is even helpful for me. 15:26:35 while writing. 15:26:54 that's all from my side. 15:26:58 what's your timeline? 15:27:17 next monday for the next doc. 15:27:31 neat! 15:27:38 with latexdiff 15:27:59 alright, moving on? 15:28:03 sure. 15:28:07 - Berlin meeting https://pad.riseup.net/p/SFYYn1aEpkPm (karsten) 15:28:14 postpone? 15:28:17 so, I wonder if we should postpone this meeting. 15:28:33 we can, sure. 15:28:48 There are many other tasks right now. 15:28:49 the thing is, I won't have much time to prepare it, if it happens in three weeks from now. 15:29:11 I'll be busy next week, be on vacation the week after, and then there's the meeting. 15:29:11 yes, we should get the things done 15:29:18 we're currently working on. 15:29:30 I mean, we should have this meeting in Q2. 15:29:37 +1 15:29:38 Sure. 15:29:42 for handing over operations things, for example. 15:29:55 true. 15:29:56 +1 15:30:26 May is the middle of q2. 15:30:40 yep. 15:30:58 mid-May? 15:31:26 calendar week 15nish 15:31:27 I think I can spend more thoughts on planning this meeting in two weeks from now. 15:31:35 ah, 2.5 weeks. 15:31:43 calendar week 20nish 15:32:10 * karsten doesn't have calendar weeks. ;) 15:32:37 May 17, Wed 15:32:46 May 18, Thursday 15:32:58 I can put the day list on the meeting pad. 15:33:03 for doodling. 15:33:07 yep good idea 15:33:12 yes, please do! 15:33:35 Will do right after this meeting. 15:33:49 thanks! 15:33:53 moving on? 15:34:10 - press request (karsten) 15:34:12 sure, suddenly those topics were added ;-) 15:34:16 tada! 15:34:20 cool, 15:34:27 which new outlet? 15:34:32 which news outlet? 15:34:33 so, somehow a press request landed on my feet, 15:34:38 and I'm trying to shake that off. 15:34:47 but it sticks? 15:34:48 would somebody else want to take it? 15:34:57 no, I just didn't find a direction where to shake it. 15:35:03 what is it? 15:35:10 "it depends" :P 15:35:13 Don't we have a communication person? 15:35:24 "... story about the increase in the use of privacy tools since the U.S. election ..." 15:35:31 iwakeh: +1 15:35:42 the communication person somehow managed to drop it on my feet. 15:35:45 why did it end up in Germany? 15:36:08 oh, just because it had to end somewhere in the metrics team. 15:36:19 it's from a U.S. news thing. 15:36:26 ah 15:36:31 ah,too 15:36:38 but what's the story there? they need someone to read the graphs for them? 15:36:46 hehe 15:36:48 pretty much. 15:36:52 :) 15:36:53 uhm. 15:37:14 so, my current plan is to let it sit in my inbox and see if it's still alive in a few days. 15:37:20 I could imagine doing something smarter. 15:37:36 (maybe off-channel) 15:37:44 there are all those nice graphs on metrics.tp.o .... 15:38:08 heh. I think I have a template for such responses somewhere... 15:38:17 good :-) 15:38:20 - new data source (karsten) 15:38:36 that's a new request from a research group. 15:38:47 which comes with a paper. 15:38:55 well, interesting 15:39:01 +1 15:39:01 and a suggestion to incorporate something into Tor Metrics. 15:39:17 what is it? 15:39:32 could I read this paper? :) 15:39:46 should I fwd this message to you two? 15:39:51 fine. 15:39:57 yeap 15:40:03 okay! 15:40:18 alright, I ran out of topics. 15:40:28 anything else for today? 15:40:34 we covered a lot. 15:40:42 yep! 15:41:00 okay, let's talk more next week. thanks, everyone! 15:41:12 "see" you next week 15:41:19 bye bye! 15:41:22 indeed. bye! 15:41:25 #endmeeting