16:01:49 #startmeeting network-health 10/17/2022 16:01:49 Meeting started Mon Oct 17 16:01:49 2022 UTC. The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:49 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:02:01 sorry, i am late due to another meeting 16:02:11 o/, np 16:02:18 \o 16:02:41 http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor-nethealthteam-2021.1-keep is the pad we have 16:03:23 it seems i am the only one with having something to sync about? 16:03:34 i need ggus for that who will arrive a bit later 16:03:46 so we could talk about other stuff first 16:03:58 anything that comes to mind? 16:04:23 not from my side 16:04:58 I am groot 16:05:11 nice 16:05:17 hiro: i could need some help with https://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40052 16:05:36 it might not be urgent to reprocess all the stuff 16:06:02 but having this fixed so the upcoming days' data don't have the problem anymore would be neat 16:06:12 ah ok I'll add that to this week stuff 16:06:18 assuming it is really just a matter of upgrading the onionperf instances 16:06:23 thanks 16:06:23 yeah 16:06:31 it's just a matter of running the ansible script 16:06:38 great 16:06:54 but the reprocessing might take a bit longer because we have to read the log again and "republish" the archives 16:07:18 it's fine 16:07:19 I might do also a release to make sure that what we ahve in develop is also in master 16:07:45 yeah, sounds good 16:08:26 juga: if there is anything to fix for the s61 o2 report section then you have like 2 days left for that :) 16:08:59 otherwise i am done with the s61 reporting parts i was working on 16:09:26 and O4 is officially done, so we are on time for that one \o/ 16:10:05 do we have anything to talk about wrt s112? 16:10:23 it seems the descriptorparser stuff is moving along 16:10:34 which is probably the only stuff currently being worked on 16:10:36 GeKo: thx for the remainder, will have a look 16:10:47 and then the relay ops meeting will be on sat this week 16:11:00 yeah so actually I would like to know what you both think about https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/4 16:11:08 I am trying to figure out a compression policy for the DB 16:11:36 and I have noticed sometimes relays come online and publish their previously measured bandwidth data 16:11:58 and as a result the DB will try to write over a chunk of data that has been compressed 16:12:18 * juga looks #4 16:12:41 interesting 16:13:11 I was wondering - if you know - if the node is publish an information that had already been published and can therefore be ignored 16:13:39 or if we should count that and make a strategy to do so 16:14:05 well, relays publish all sorts of information that has been published before already 16:14:12 like first_seen dates and such 16:14:37 so, i guess the hard part would be figuring out where to ignore thing 16:14:42 s 16:14:57 now what we are doing is making sure we aren't counting stuff for the same interval 16:15:18 could you give an example here? 16:15:27 yeah hold on 16:18:12 one example is when we compress history in onionoo 16:18:13 https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/blob/master/src/main/java/org/torproject/metrics/onionoo/docs/BandwidthStatus.java#L251 16:20:40 i see 16:22:07 this is for the website https://gitlab.torproject.org/tpo/network-health/metrics/website/-/blob/master/src/main/java/org/torproject/metrics/stats/bwhist/RelayDescriptorDatabaseImporter.java#L298 16:22:56 do we have scenarios where we actually would want to write on compressed chunks? 16:23:53 or could we just drop the updated value in those cases 16:24:07 well every time I parse extra infos I found a few nodes that are publishing a bandidth value in the past 16:24:28 that's what I thought... maybe we can just drop the updated values and do not consider those very relevant 16:24:39 hrm 16:25:02 let's run the test instance for a while trying to trigger as much of those cases 16:25:26 then document them (maybe in the ticket) so we get a handle on the different situation where this can happen? 16:25:27 the number of cases also dependes on the compression policy 16:25:32 sure 16:26:19 and then we can decide how to deal with those cases 16:26:52 from what i read so far it *might* be the case where we just can drop the updated value 16:26:58 but i am not sure 16:27:05 having some data points would help imo 16:28:13 ok sounds good 16:28:38 is it ok if I take the onionperf ticket? https://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40052 16:28:58 yes, thanks! 16:29:22 i can look through the code if it's indeed still a code issue after you upgraded the boxes 16:30:03 oh I think we can update the box both w onionperf and tgen but not tor 16:30:05 and that should do it 16:30:08 but let's see 16:30:13 sure 16:31:28 ok now all groot on my side 16:31:31 okay, i guess that's enough for today's meeting 16:31:39 thanks everyone and have a nice week! 16:31:42 #endmeeting