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