<p​reland:matrix.org> Tbh a p2p-based repo sounds potentially dangerous

<p​reland:matrix.org> I like the idea, but I’d be very cautious of it

<p​cre:matrix.org> Not using a p2p-based repo sounds potentially dangerous to me.

Well, and I guess it hasn't been too battle tested?

<s​yntheticbird:monero.social> 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

<s​yntheticbird:monero.social> also not thrilled at the idea of using a p2p git that don't support CI and GActions (or equivalent)

<s​gp_:monero.social> Is there a way to benchmark the performance difference with 9181? With basic testing, it doesn't appear to make a difference

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?

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 : github.com/0xFFFC0000/benchmark-project

but still needs more work

<s​gp_:monero.social> ok, thanks for the message. I guess we'll hold off then on this patch.

If you want to follow 9181 related recent experiemnts take a look at this: 0xFFFC0000/monero #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.

<s​gp_:monero.social> Ok I will take a look, thanks. If this doesn't work, Cake will probably build a custom reader for the database

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.

sgp should work without any issue. let me know if you had any problem.

<s​gp_:monero.social> tanner is horrified by the phrase "recursive locking" haha. He's excited to try this PR in a region

<r​ucknium:monero.social> 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.

sgp Great. I have another good news too, in this 0xFFFC0000/monero #16 we will get rid of locking at all. But too complicated and too many changes at once. needs a lot of testing.

<s​gp_:monero.social> both of those are PR 16. Which is which?

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.

9181 is the one you should try.

but 16 is one I am working at the moment (experimental).

<s​gp_:monero.social> Cake tried 9181 and it appeared to make no difference

even under intense load?

<s​gp_:monero.social> 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%

it's possible that the issue is somewhere else, and not with the locks

that's why we ideally would need some test that reproduces this high load behaviour locally

sgp makes sense. thanks for the numbers. if 9181 does not improve things, this is the way forward: 0xFFFC0000/monero #16 much simpler design. getting rid of recursive locking. But at this point, I would say we need more experiments. I am fighting with github.com/0xFFFC0000/benchmark-project these days. once i have reliable benchmarks on my machine, then everything will be smoother after that

<s​gp_:monero.social> Tanner is going to test that PR 16 and I'll let you know how it goes

<r​ucknium:monero.social> x​FFFC0000: 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.

test

<d​atahoarder:monero.social> test

Interesting. Why is your pm working but sgp_ message not delivered to matrix.

this is not a PM

15:29:53 <m-relay> <s​gp_:monero.social> Tanner is going to test that PR 16 and I'll let you know how it goes

?

I am not saying it's not broken xFFFC0000 I just can't see the part it failed irc.gammaspectra.live/d0e125cc2e53b240/image.png

"x​FFFC0000" has a non-breaking space between the x and F

NBZWS

Aha. The problem is not the bridge. The problem is the recent issue in the matrix itself. Not delivering messages.

<d​atahoarder:monero.social> Yeah sadly that’s too common client wise

d​atahoarder I copy-pasted your name and it also has a non-breaking space between first two letters

Unicode character #8203

yes, that's intended sech1

to avoid pings for people on both sides

<b​iznotch:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/cLHXwGHMLYNMHyAYxiUvZhpU

<b​iznotch:matrix.org> 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

<e​ndor00:matrix.org> xBiznotch: enough with the spam

<d​iego:cypherstack.com> Heyo. -dev is only for dev talk about Monero. Nothing else is tolerated here. Thanks for understanding.

<b​iznotch:matrix.org> Ok. I thought that if devs dwell here, one might be up for a project job. Thank you 🙏🏼