15:58:55 #startmeeting network-health 07/10/2023 15:58:55 Meeting started Mon Jul 10 15:58:55 2023 UTC. The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:58:55 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:59:00 hello everyone! 15:59:22 hey there everyone, hope i'm not late 16:00:04 not at all 16:00:16 https://pad.riseup.net/p/tor-nethealthteam-2023-keep is our pad 16:00:20 o/ 16:00:23 hiro: ggus: ^ 16:00:35 i have one item i want to mention here at least 16:00:41 btw GeKo i wanted feedbacks on what i can add to the application or how you want the current application to behave 16:00:49 and about that expensive call 16:00:57 i will have it fixed using a hashset approach 16:01:03 sorry for that 16:01:05 yeah 16:01:10 no worries 16:01:15 we can talk about that in a minute 16:01:39 let me just get the "process" question sorted out 16:01:41 :) 16:01:47 Sure :) 16:02:03 so, i'll be out for about 4 weeks from next monday on doing vacations 16:02:13 nice 16:02:22 we need to figure out what we should do with our weekly syncs here 16:02:29 during that time 16:03:04 I'd be happy to do sync w people, but that also depends if others will be out as well 16:03:15 it seems keeping those running while i am away could be useful 16:03:33 in particular as it allows coordinating our gsoc work i think 16:03:50 ok I can call the meetings then 16:03:54 hiro: would you be up for faciliting these syncs until im back? 16:04:01 okay, nice 16:04:02 thanks 16:04:33 my last vacation day is 08/15 and i plan to catch up that week while i am at camp 16:04:50 and i can take over the usual tasks again on 08/22 16:04:56 hiro: would that work? 16:05:08 yep sounds good 16:05:21 awesome, thanks 16:05:38 actually last vacation day is 08/14 and i am back 08/21 16:06:27 that was easy :) 16:06:41 okay any updates worth discussing here? 16:06:55 i guess we can start with gsoc 16:07:05 matt is traveling this week 16:07:16 RishadBaniya[m]: 2023-07-10T15:43:23Z INFO master::master::tor_network] Finished filtering in 1614.019235026s 16:07:20 is where i am stuck now 16:07:23 hiro: ack 16:07:36 RishadBaniya[m]: so, the filtering took almost half an hour 16:07:41 which is...long 16:07:41 woah! 16:07:42 was that on debug mode 16:07:49 its too long 16:07:56 for release mode 16:08:00 cargo run --bin master 16:08:07 that's on debug mode 16:08:08 is what i've been running 16:08:09 yeah 16:08:19 on release it gets done in 1 min 16:08:26 cargo run --release --bin master 16:08:37 sorry for not mentioning that debug takes way long 16:08:49 in the WiKi 16:09:22 no worries 16:09:27 even around 1 minute of time is too much overhead here, i realized where i messed up, i'm fixing it ASAP 16:09:45 let me see how fast this is in release mode 16:09:53 okay 16:09:58 Sure :) 16:10:05 it's worth adding that in the ticket 16:10:14 that is what went wrong and what the proposed fix is 16:10:17 so we have some context 16:10:46 Sure i'll raise an issue and add contexts 16:10:48 right now 16:10:52 RishadBaniya[m]: i've looked over https://gitlab.torproject.org/rishadbaniya/erpc/-/wikis/home 16:10:53 after the meeting 16:10:58 thanks for the write-up 16:11:18 i'd like us to focus on scenario (i) right now 16:11:22 and get that one right 16:11:30 there is no need to back out code or anything 16:11:49 just make (ii) and (iii) as experimental for now? 16:12:10 those are interesting optimizations but we should not focus on them for now as they make things only more complex 16:12:32 oh, the master/slave terminology made me cringe 16:12:35 Sure :) 16:12:43 we should replace that with something like parent/child or so 16:12:51 i can file a ticket for that later 16:13:24 Sure :), it does sound cringe 16:13:27 parent child seems nice 16:14:35 i do think some instructions to run just scenario (i) in the README file are good 16:14:52 i saw you moved those into the wiki 16:15:05 while i think the wiki is fine for detailed information 16:15:14 I had trouble adding images, so i had moved 16:15:20 to WiKi 16:15:26 yeah 16:15:32 it's fine to have that part in the wiki 16:15:53 but something like `cargo run --release --bin master` 16:16:08 noted! i will add that 16:16:10 should be in the README as well 16:16:42 i guess essentially everything in https://gitlab.torproject.org/rishadbaniya/erpc/-/wikis/home#running-master-worker could be mentioned there 16:17:24 I'll add it properly in the README after the meet 16:17:30 thanks 16:17:36 okay, now we have: 2023-07-10T16:16:52Z INFO master::master::tor_network] Finished filtering in 100.408107542s 16:17:41 much better :) 16:18:05 now i am stuck there. is there supposed to be further output about what's going on? 16:18:23 actually it's now producing 16:18:25 2 hop circuits 16:18:26 in the database 16:18:28 file 16:18:44 is there some more output i could get on the terminal to see what's going on? 16:18:48 i had no idea what to log now, in the master worker only mode, because if i were to log all circuit creation attempts 16:18:55 log would be huge! 16:19:21 well. you could create an option for a log file 16:19:45 which would log circuit creation attemps and what there results are 16:20:12 i will add that too 16:20:12 together with some information like: scheduling X circtuis 16:20:16 *circuits 16:20:22 currently the sqlite3 database has the data saved 16:20:25 i'll also add the table name and other information in the WiKi 16:20:28 or donex out of y circuits 16:20:29 sure, that would be better 16:20:47 i will have that added and juga had also mentioned to add 16:20:54 arguments for path to config file 16:21:01 some way for follow what's going on without investigating the database 16:21:01 i'll also add a log file argument 16:21:07 great 16:21:18 i think that's my feedback for now 16:21:26 thanks for the feedback, now i know what i should fix 16:21:26 i'll add more tomorrow and will file some tickets 16:22:00 btw after fixing these issues, should i start working on extracting circuit informations through onionperf tool 16:22:31 is that the next step i should move on with the application 16:22:40 if things are working well, we could think about that 16:22:56 let me test what you have right now a bit more 16:23:07 and let's file some issues following from that 16:23:16 Sure :) 16:23:23 and once we are happy with the current state we can consider the onionperf part 16:23:29 does that make sense? 16:23:37 yeah i got you 16:24:00 so, the debug output part is highest prio right now 16:24:15 so we can see what is going on and figure out whether something more needs fixing 16:24:33 no worries about the size of the logging file 16:24:48 i will set the scheduling X circuits 16:24:50 in the debug 16:25:04 you could make that approach smarter by having some things in INFO mode and some in DEBUG mode 16:25:25 ideally, with the INFO mode allowing to see what is going on without taking too much space 16:25:25 sure i'll will consider that as well 16:25:42 and all the nitty-gritty details for bug hunting behind DEBUG 16:26:01 and then one can consider on how large a log file one wants to have :) 16:26:15 that seems nice 16:26:20 so the log level decides 16:26:20 great 16:26:22 the size eventually 16:26:24 yeah 16:26:32 i love this approach 16:26:48 good, good :) 16:26:55 RishadBaniya[m]: anything else you need from us? 16:27:20 i guess that's everything for now, i will ping you if i have any query 16:27:47 i think we can revalidate the filtering approach you have, which takes some time 16:28:16 i am in particular interesting in understanding exactly how a new consensus fits into that picture 16:28:24 *interested 16:28:36 i'll look closer at that this week as well 16:28:37 should i document 16:28:39 that in the WiKi? 16:28:43 i can do that too 16:28:43 yes, please 16:28:55 sure, i'll have it documented 16:28:57 that's actually a crucial part of the tool 16:29:19 and one of the main tasks imo: to figure out a good strategy here, balancing different goals 16:29:39 yeah, about that as of right now 16:29:44 i've decided the most generic 16:30:06 only by considering 16:30:15 if two relay can create circuits 16:30:26 it still lacks repeated testing of same circuit 16:30:37 i.e same relay combination but i'll have that design ready too 16:31:06 i'm yet to utilize the flags here, now that the entire framework for the application has been laid, adding things on top of it is a bit easier 16:31:14 documenting what is missing in that context and what you plan in the wiki is important as well 16:31:22 okay 16:31:50 oh, another important thing: last week was the bi-weekly update due to our mailing lists 16:31:52 Sure :) i'll make sure to document crucial parts, please do provide me feedbacks on things that i should document 16:31:56 please do that this week 16:32:11 i have it ready, few changes to be made 16:32:17 i'll mail 16:32:21 it tommorrow 16:32:22 and update the timeline as well with what you did last week 16:32:33 Sure :) 16:32:37 (the accomplished part is missing) 16:32:44 oookay 16:32:56 do we have anything else for today? 16:33:18 i guess that's it from my side... 16:33:26 hiro: our usual sync time this week works? 16:33:39 yep 16:33:51 for the s112 parts: note we have our monthly sync tomorrow 1600utc at our bbb room 16:33:56 nice 16:34:07 hiro: you good otherwise? 16:34:29 yep all good 16:35:07 okay, let's finish this sync then. thanks eveyone 16:35:10 #endmeeting