16:01:27 #startmeeting metrics team 16:01:27 Meeting started Thu Mar 14 16:01:27 2019 UTC. The chair is karsten. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:27 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:01:35 - Sponsor 13 report (irl) 16:01:42 can you give an update how this is going? 16:02:01 was the exonerator/rserve stuff of any use? 16:02:06 report is in progress, it is tiring work, it is about 65% done 16:02:15 the exonerator/rserve stuff was great 16:02:18 can I help? 16:02:33 by doing more braindumps? by reviewing? 16:02:42 by doing code metrics? 16:02:42 i think that right now you cannot help, but you may be able to review sections as they are completed later 16:02:49 okay. 16:03:01 when do you think you'll have something to review for me? 16:03:06 tomorrow evening 16:03:11 sounds good! 16:03:45 sorry that it's tiring work. 16:03:57 there's just so much information to load into my brain all at once 16:04:04 that's what happens when the proposal process becomes very tiring. 16:04:20 i should get tor to buy me a bigger brain 16:04:28 hello 16:04:39 hi acute! 16:04:41 hi acute! 16:04:50 sorry I'm a wee bit late, coming from another appointment 16:04:53 bigger brains sounds great. sign me up, too. 16:05:03 I'll have a question for you later, acute. 16:05:09 heh, that is probably all i can say on the report for now. 16:05:16 okay, cool! 16:05:21 - TorDNSEL spec #29624 (irl) 16:05:27 I assume this answers that, too. 16:05:32 sponsor 13 first. 16:05:49 i have not looked at this since we last discussed it 16:05:54 but did you see my question about keeping tordnsel alive? 16:05:59 makes sense. 16:06:14 i did see that, i think it is harder than just a few quick changes 16:06:31 i think that it is likely that we would have to read changelogs and migration guides 16:06:32 I just wonder how we'll get something running in two weeks. 16:07:09 we just need to get the data into collector, so we can have a complete hack of a solution to do that temporarily 16:07:18 we can keep an eye on it and restart it if it falls over etc. 16:07:41 hmm? 16:08:00 I'm lost. 16:08:15 by the end of this month, the current tordnsel will be killed, right? 16:08:18 at least that's the plan. 16:08:34 oh wait, yes, i guess that also includes check and the dnsel server 16:08:37 not just the scanner 16:08:49 yes, I think that's all part of tordnsel. 16:08:59 it's all very confusing, but I think it does many things. 16:09:09 and we may have a replacement for part of it, which is check. 16:09:12 i don't remember any haskell at all 16:09:31 i only had two lectures on it as part of my undergraduate degree 16:09:52 and that was on computation theory more than applied programming 16:09:57 how is your haskell? 16:10:06 it doesn't exist, but that doesn't stop me yet. 16:10:21 if you want to have a go, i think it is probably worth trying 16:10:32 I was mainly wondering if you have any facts that should stop me from even trying. 16:10:43 arlo did say that it would be a lot of work 16:10:50 ah. hmmm. 16:10:57 I should ask arlo in that case. 16:11:16 okay, moving on. I'll ask him. 16:11:21 ok 16:11:44 - OnionPerf worst-case performance (karsten) 16:12:03 so, I resumed this work after all. 16:12:17 we have 4 questions to answer. 16:12:39 worst case latency, worst case bandwidth, failures/timeouts, total exit capacity. 16:12:46 I made tickets for the first two: 16:12:56 #29772 and #29773. 16:13:16 if you have a moment, please take a look. can be after the next sponsor 13 draft. 16:13:33 ok 16:13:43 I also made two tickets for the failure cases and really slow cases I found earlier: #29743 and #29744. 16:13:48 one question on those: 16:13:55 which tor version does op-ab use? 16:14:03 i am not sure but can find out 16:14:11 is it recent? 16:14:15 or as old as op-nl et al.? 16:14:22 yes, it will have been a current version at the time it was set up 16:14:30 sounds great. can I have the logs? 16:14:37 yes, i can get those tar'd up 16:14:44 that would be great! 16:14:45 i might even be able to just directly expose them on the webserver 16:14:48 or that. 16:15:16 regarding the others, can we update them to recent tor versions? 16:15:26 or is there a reason not to do that? 16:15:49 we can, there's no reason to not do it other than that it takes time 16:15:50 also not more urgent than sponsor 13. 16:15:53 okay. 16:16:02 i want to also stop using our own tor and instead use tor from deb.tpo 16:16:15 works for me. 16:16:26 ideally, the .tpf files would say which version was used. 16:16:36 but, that's the future. 16:16:41 i think we had a ticket for this 16:16:51 probably. :) 16:17:02 acute: I have a question to you: 16:17:11 yes 16:17:26 we were asked whether we can say more about failures and timeouts. 16:17:40 I think so far our model for distinguishing the two is imperfect. 16:18:01 I found a couple cases so far where things went wrong. 16:18:27 I was wondering if you'd be able to help me with classifying these error cases and somehow including an error code of some kind in .tpf files? 16:18:45 assuming you still have time for such a thing. 16:18:50 ok, sure 16:18:57 I have graphs showing these errors, and I have stream IDs. 16:19:06 but I don't really know the onionperf code that well. 16:19:24 so in the json output the errors are differentiated well 16:19:30 ideally, we'd be able to determine from tor controller logs which error case we just observed and include that in the .tpf output. 16:19:39 ah, I didn't look at the json output. 16:19:55 also, side comment about 29744 16:20:00 #29744 16:20:05 can I send you what I found, and we try to match these errors with what's in the json output? 16:20:10 yes? 16:20:37 so the timeouts and stallouts can be easily controlled from the tgen download graph 16:20:55 yep happy to do the matching 16:21:15 controlled how? 16:21:22 okay, cool, will send you what I have. 16:21:23 for 5m files, the stallout and timeout are set to 3600 seconds 16:21:34 you mean to avoid those cases? 16:21:45 I think ideally they shouldn't happen in tor. 16:22:00 if we avoid them in onionperf, they'll still exist in other applications. 16:22:29 got you - the bug is about finding why the transfers time out 16:22:57 they just stall. nothing times out, except for onionperf after those 3600 seconds. 16:23:12 but it seems not very helpful to have a download stall for 3500 seconds and then rush to completion. 16:23:26 maybe there's an easy explanation. in tor. 16:23:46 ok 16:24:01 great! feel free to comment on #29744, too! 16:25:23 alright, moving on! 16:25:24 - NLnet proposal (gaba) 16:25:28 cool, will do - and if you give me a bunch of torperf files I can match them up to OP error codes 16:25:53 great, thank you! 16:26:06 so, we don't have a gaba. 16:26:13 on the first question: everything we do enhances privacy and trust 16:26:18 :) 16:26:23 on the second question: if we can't do it, then it won't happen 16:26:50 how about we meet with gaba early next week? 16:27:08 that would be after the next sponsor 13 draft and still soon enough to do something for the proposal. 16:27:34 I'm a bit worried that we'll run out of march sooner than we'd like to. 16:27:51 monday i can do any time, tuesday i am busy from 1500 16:28:08 let's try monday then. I'll ask gaba. 16:28:12 monday afternoon probably. 16:28:19 morning might be hard for gaba. 16:28:24 friday next week i fly to prague for IETF and return wed 27th 16:29:02 okay. 16:29:21 let's move this to email with gaba. or next monday. 16:29:29 ok cool 16:29:47 15 seconds left! 16:29:50 anything else? :) 16:30:03 nothing more from me 16:30:10 perfect. thanks, irl and acute! 16:30:13 bye! :) 16:30:14 bye! 16:30:21 #endmeeting