17:00:04 <ahf> #startmeeting network team meeting, 26th of april 2021
17:00:04 <MeetBot> Meeting started Mon Apr 26 17:00:04 2021 UTC.  The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:04 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:00:05 <nickm> hihi
17:00:06 <ahf> hello hello
17:00:28 <ahf> i *just* got in from the outside, so haven't updated my pad yet. our pad is at https://pad.riseup.net/p/tor-netteam-2021.1-keep
17:01:10 <asn> o/
17:01:15 <ahf> how are people doing on roadmappy things?
17:01:16 <ahf> o/
17:01:25 <gaba> o/
17:01:43 <asn> all good here
17:02:53 <ahf> very nice
17:02:54 <ahf> ok
17:02:55 <acute> o/
17:03:14 <GeKo> hello
17:03:24 <ahf> how is our situation with the 0.4.5 and 0.4.6 release tracking we are doing?
17:03:26 <ahf> o/
17:04:48 <ahf> man tor#40355 is wild :o
17:05:16 <nickm> ahf: the c99 part was solveable, but the printf situation is a beast there and I don't get how to fix it _safely_
17:05:34 <ahf> yes, it is the printf part that i am glaring at with wide open eyes
17:06:40 <nickm> We need somebody to take on tor#40373
17:07:16 <asn> ill take it
17:07:24 <ahf> cool
17:07:29 <asn> i will be at a conference tomorrow and the day after tho
17:07:41 <asn> if i cant do it tomorrow/day after i will do it on thursday
17:08:32 <ahf> ack!
17:08:55 <ahf> ok, i don't see anything else for us to discuss, nothing in bold and no added entries
17:09:00 <ahf> so maybe it's s61 time already?
17:09:05 <asn> kk
17:09:19 <ahf> mikeperry: you wanna go?
17:09:23 <mikeperry> sure
17:09:31 <mikeperry> main thing is the report is due
17:10:05 <mikeperry> gaba figured out why the perf metrics seemed to go up (issue with previous report's numbers, not this one), so I think that issue is solved. thanks, gaba
17:10:27 <ahf> cool!
17:10:54 <GeKo> aha, good to know
17:11:14 <gaba> they still go up but no soooo much
17:11:23 <mikeperry> gaba: for updates on the report itself, should we try to update the nextcloud from now on? I think geko had permission issues
17:11:24 <ahf> ... what was it? :o
17:11:29 <gaba> yes please
17:11:36 <gaba> i went to check and i see that all of you can edit it
17:11:42 <gaba> i did the changes that geko sent via email
17:11:50 <GeKo> thanks
17:11:50 <gaba> ahf: wrong number for previous Q...
17:11:52 <GeKo> and sounds good
17:12:00 <ahf> gaba: ah!
17:12:05 <mikeperry> gaba,Geko: yeah there is the minor mystery as to why kicking out bad exits seemed to correlate with bad perf for a few days, even tho it was not that much bandwidth lost
17:12:08 <GeKo> (re: nextcloud direct editing)
17:12:36 <gaba> we should really confirm that this is the case (kicking out bad exits correlation with bad perf)
17:13:14 <mikeperry> the variance in performance got much worse right after the end-of-march ejection, and I think also in feb for a bit
17:14:20 <mikeperry> this is only correlation, tho, and it doesn't make a lot of sense that it would happen, given the total network exit used or advertised bytes didn't change much
17:14:27 <GeKo> but the bw those relays had, in march was not much
17:14:33 <GeKo> yes
17:14:53 <GeKo> i mean it were bigger relays
17:15:16 <GeKo> but not so much ones that i'd expect them going away would be noticable
17:15:47 <mikeperry> it could have something to do with the location of those relays vs the ones that remained, compared to the onionperf instance location
17:16:07 <GeKo> hrm
17:16:07 <mikeperry> with fixed-size windows, throughput is a direct function of latency
17:16:15 <mikeperry> and latency is a function of location
17:16:39 <mikeperry> linear functions, in both cases
17:17:07 <mikeperry> proportional is the word I was looking for :)
17:17:28 <GeKo> do we have fine-grained enough data for onionperf to be able to figure that out?
17:17:45 <GeKo> like which measurements were slower exactly?
17:17:50 <GeKo> and which circuits they used
17:17:53 <GeKo> etc.
17:18:07 <GeKo> i am not too familiar with that part of our work
17:18:17 <mikeperry> I think so.. I think it can be pulled from collector, but I also don't know details
17:19:08 <GeKo> okay. well, if we think it's worthwhile then we can file a ticket
17:19:09 <acute> onionperf does collect info about the circuit and path for every measurement
17:19:22 <GeKo> and i could try finding some time digging into that
17:19:33 <GeKo> acute: okay, that's good to hear. thanks
17:19:45 <acute> happy to help here
17:20:11 <GeKo> this sounds like a deep hole, but, hey :)
17:20:23 <ahf> follow the rabbit
17:20:37 <GeKo> right :)
17:21:13 <mikeperry> this is another one of those things where if it happened *after* we had congestion control in place, I would be much more concerned. right now, it seems a deep hole to confirm a suspicion that something we know is broken is broken or not.. but if you have time, sure
17:21:53 <acute> if you open a ticket, let me know what data you need :)
17:22:10 <gaba> we may find something else so i think it is worth it to look at
17:23:15 <mikeperry> a lot of things are worth looking at, is the problem. but if there's time to look at everything, go ahead
17:23:22 <GeKo> okay. i'll think a bit more about it
17:23:35 <GeKo> it's a matter of prioritization :)
17:25:23 <ahf> .. do we have more?
17:25:40 <GeKo> i am fine
17:25:44 <asn> same here
17:26:06 <mikeperry> yeah that should cover it
17:26:19 <ahf> let's call it then
17:26:27 <ahf> thanks all o/ see you on the other irc channels
17:26:29 <ahf> #endmeeting