02:23:25 Tbh a p2p-based repo sounds potentially dangerous 02:23:26 I like the idea, but I’d be very cautious of it 03:04:51 Not using a p2p-based repo sounds potentially dangerous to me. 06:38:17 Well, and I guess it hasn't been too battle tested? 08:45:57 We could also just use github, periodically wrap source code in a tarxz and send it over torrent. I think it would be the same level of security against takedown 08:46:43 also not thrilled at the idea of using a p2p git that don't support CI and GActions (or equivalent) 13:14:23 Is there a way to benchmark the performance difference with 9181? With basic testing, it doesn't appear to make a difference 14:11:31 https://usercontent.irccloud-cdn.com/file/0x9rBwRw/wallet-rpc-ssl.png 14:12:59 in my wallet-rpc command line I have disabled ssl with "--rpc-ssl disabled" and disable ssl for daemon with "--daemon-ssl disabled", but still ssl is taking 99% of my cpu load. what is going on here? 14:17:57 sgp matrix didn't deliver your messege. (seems matrix has problem). Not detectable easily with basic settings. I am writing this to benhcmark it under stress : https://github.com/0xFFFC0000/benchmark-project 14:18:01 but still needs more work 14:18:32 ok, thanks for the message. I guess we'll hold off then on this patch. 14:18:54 If you want to follow 9181 related recent experiemnts take a look at this: https://github.com/0xFFFC0000/monero/pull/16 In this pr I have removed all the recursive locking from all the APIs in inside Blockchain.cpp, and using a very tiny pointer to pass around the lock. instead of locking / unlocking. 14:20:02 Ok I will take a look, thanks. If this doesn't work, Cake will probably build a custom reader for the database 14:20:16 sgp if you have load that you can test it underload, I appriciate it. since I need to test it under load. but the problem is I've not been able to put it under pressure in any meaningful way. But you are free to run it, it should produce some difference. How much, at this point I am trying to find that. 14:20:43 sgp should work without any issue. let me know if you had any problem. 14:22:31 tanner is horrified by the phrase "recursive locking" haha. He's excited to try this PR in a region 14:23:41 What kind of load do you need to put it under? Usually I can put the monerod RPC at max load when I am rebuilding my blockchain data. 14:23:59 sgp Great. I have another good news too, in this https://github.com/0xFFFC0000/monero/pull/16 we will get rid of locking at all. But too complicated and too many changes at once. needs a lot of testing. 14:24:33 both of those are PR 16. Which is which? 14:25:11 rucknium any rpc <-> daemon interaction worth it. at least it is some measure. I have not been able to get access to computing machines (matrix does not deliver DMs). and in my local machine the numbers are random because of one ssl issue I was asking about few minutes ago. 14:25:21 9181 is the one you should try. 14:25:37 but 16 is one I am working at the moment (experimental). 14:25:44 Cake tried 9181 and it appeared to make no difference 14:26:08 even under intense load? 14:27:20 We're not using exact numbers here because it's difficult to benchmark, but our observations seemed like initially there was a ~20% improvement, but over time it looked like 18.3.3 outperformed by 10-20% 14:28:03 it's possible that the issue is somewhere else, and not with the locks 14:28:35 that's why we ideally would need some test that reproduces this high load behaviour locally 14:29:24 sgp makes sense. thanks for the numbers. if 9181 does not improve things, this is the way forward: https://github.com/0xFFFC0000/monero/pull/16 much simpler design. getting rid of recursive locking. But at this point, I would say we need more experiments. I am fighting with https://github.com/0xFFFC0000/benchmark-project these days. once i have reliable benchmarks on my machine, then everything will be smoother after that 14:29:53 Tanner is going to test that PR 16 and I'll let you know how it goes 14:29:56 xFFFC0000: Ok. When you get access to the Monero Research Computing cluster, you can sync a new blockchain on the main machine with the new PR. Just use different ports so there are no conflicts with the nodes that are already running there. Then I can flood it with RPC calls. I could compile the new PR myself, but I am a little busy. 15:09:03 test 15:09:10 test 15:14:23 Interesting. Why is your pm working but sgp_ message not delivered to matrix. 15:29:34 this is not a PM 15:29:39 15:29:53 Tanner is going to test that PR 16 and I'll let you know how it goes 15:29:40 ? 15:30:42 I am not saying it's not broken xFFFC0000 I just can't see the part it failed https://irc.gammaspectra.live/d0e125cc2e53b240/image.png 15:31:08 "xFFFC0000" has a non-breaking space between the x and F 15:31:11 NBZWS 15:32:30 Aha. The problem is not the bridge. The problem is the recent issue in the matrix itself. Not delivering messages. 15:32:49 Yeah sadly that’s too common client wise 15:34:47 datahoarder I copy-pasted your name and it also has a non-breaking space between first two letters 15:35:03 Unicode character #8203 17:27:49 yes, that's intended sech1 17:27:58 to avoid pings for people on both sides 19:11:19 https://matrix.monero.social/_matrix/media/v1/download/matrix.org/cLHXwGHMLYNMHyAYxiUvZhpU 19:11:19 We at Haven Protocol, a Monero fork, are looking for a CN DEV to help us fix our multi-sig wallet. Contact me for more detals 19:18:03 xBiznotch: enough with the spam 19:30:53 Heyo. -dev is only for dev talk about Monero. Nothing else is tolerated here. Thanks for understanding. 20:40:37 Ok. I thought that if devs dwell here, one might be up for a project job. Thank you 🙏🏼