<s​gp_:monero.social> I spoke with a few people at the finney forum this weekend about the monerod read locks, and I'm pretty confident that is the main thing slowing down the cake nodes

<s​gp_:monero.social> I believe this is the pr that was discussed monero-project/monero #9181

Did they test with 9181? Did it improve performance?

<s​gp_:monero.social> no, but they can. Is the issue you observed with the one cpu core pinned to 100% still present?

It's not strictly 1 core, but when the node is synchronizing, it barely uses more than 1 CPU core

When it's past checkpoints

<s​gp_:monero.social> cake solved its node issues for now by putting the entire blockchain in ram. that seems to have done the trick

<s​gp_:monero.social> but that's pricey long-term :p

<r​ucknium:monero.social> I'm not the only one who noticed that some txs with more than 5 inputs can appear in the txpool with a fee less than 20 nanoneros per byte. Is wallet2 making these txs? When the txpool has a backlog, these txs can stay in the txpool for hours. They sit in the "queue" below the 20 nanoneros/byte txs that are getting confirmed in the "first in, first out" rule of `get_block_template<clipped message>

<r​ucknium:monero.social> ` for txs that are on the same fee/byte level.

<r​ucknium:monero.social> For example, these txs waited over 24 hours to confirm, according to my txpool archive data:

<r​ucknium:monero.social> 32cbd8640fddcf7e9d449382a3d6a4521f065d90f27a7c72984ef2c6d690d5ff, 3adcbf45dc42971b11e159a02e2cce847e14504c826c9a3ff848908f4a5bcff2, bcf3f15f1a877a0be48ec5a498c4b92d5d3a3200db452b7ec615b59c08e07dd4, 1331e6554b2be45e7c2fa63faa9f125716d061165282bbc103e85c1b519acbfc, 914470815b33c90bcd53959bf2ef472726f520d18fbc78c6bbd07136ec93a30f, eca2315b48168bf2dbb686d8fbdf1bc1bf9f0849741ab32077a4e<clipped message>

<r​ucknium:monero.social> 973242b0982, 2c3c45238bcb2fefdccc0c0e0e49ea409ae8611d5c991dfecf7a4a6a7af911e9

<r​ucknium:monero.social> Their fee/weight is, respectively, 19959.70 19959.93 19940.11 19866.95 19874.59 19775.90 19664.40

<r​ucknium:monero.social> Is this undesirable behavior? Should I make an issue on GitHub? If these txs cannot have an exact 20 nanoneros/byte fee because of their unusual size, maybe they could have a slightly higher fee than 20 nanoneros/byte instead of slightly lower.

Would this just not change which txes get to wait ?

I guess a floor would just shuffle, since exactly 20 per weight-byte can be done, since it's a multiplication...

<r​ucknium:monero.social> It would reduce or eliminate extreme wait times in this circumstance. If it changed, the 20 nanoneros/byte txs would wait behind the unusual txs, but the 20 nanonero/byte txs would confirm in approximately the backlog time that `print_pool_stats` says.

The problem is in the fee algorithm. Transaction weight is not transaction size for transactions with more than 1 input

It does some rounding, and such transactions end up with less than 20

In a set of txes, you'll always have one that's the last if all txes can be compared.

Right now mempool clears regularly, so it's not urgent

<r​ucknium:monero.social> Yes, not urgent, but is it undesirable?

<r​ucknium:monero.social> I thought weight != size when number of _outputs_ is greater than 2.

<r​ucknium:monero.social> Zero to Monero 2.0 says "Transaction weight for a miner transaction (see Section 7.3.6), or a normal transaction with two outputs, is equal to the size in bytes. When a normal transaction has more than two outputs the weight is somewhat higher than the size."

oh right, outputs\

Weight is higher to account for BP's sublinear size vs verification cost.

AFAIK this is the only case where weight is not equal to size.

Hello, could anyone tell me what's the default limit for incoming connections and possibly tell me where to find that value in the code? I couldn't find it.

Default is no limit

sech1, thanks. I'm asking because the 2020 paper Exploring the Monero Peer-to-Peer Network says that the default is 1, which really can't be right. Right?

it's probably a typo, default is -1 (unlimited)

max connections per IP defaults to 1 though

sech1, thanks!

I was thinking, maybe radicle (radicle.xyz

is usefull for self-hosting the monero project (related to monero-project/meta #522)

but I'm not sure if it's possible or easy to use Tor with it

And well, maybe it makes the barrier to entry a bit too high, (if you guys decide to even use it, as it hasn't officially been released yet, radicle.xyz/faq#who-is-using-radicl…rrently-how-many-users-does-it-have

well, and it being related with radworks (which funds itself on the $RAD token, which is another crypto currency), so maybe it's not a good idea?