<r​brunner7:monero.social> Did I miss something? moneroecosystem.org is now in the hands of some domain squatter and redirects to some shop page?

the maintainer of the non-monero-project repo archived it a while ago github.com/monero-ecosystem , i assume erciccione let the domain expire

<r​brunner7:monero.social> Thanks for the info, plowsof. Seems that woodser's wallet API stuff was not archived along with the other things.

<3​21bob321:monero.social> monero-ecosystem.org is available

<o​frnxmr:monero.social> i'm surprised anybody ever agreed to allow their projects to live on fhe Monero-ecosystem github org. As if they couldnt have simply been mirrored or forked

<o​frnxmr:monero.social> Even the matrix space is dead / abandoned / broken

<s​yntheticbird:monero.social> meanwhile librejo alive.

<s​yntheticbird:monero.social> don't forget to backup your working branch on it

<s​yntheticbird:monero.social> there is plenty of storage

<r​brunner7:monero.social> Nice, but of course not for eternity either. If whoever maintains the domain and the server for that throws in the towel in anger a few years in the future they same think may happen ... just a fact of life.

<o​frnxmr:monero.social> wen M$ going to throw in the towel

<k​ewbit:matrix.org> What about moneroecosystem.com

<o​frnxmr:monero.social> Is it possible to use rx fast mode to validate blocks? Would it increase sync time today?

<o​frnxmr:monero.social> Decrease*

<s​yntheticbird:monero.social> rx?

<o​frnxmr:monero.social> Randomx

<o​frnxmr:monero.social> > Fast Mode requires 2GB of shared memory but has 4x-6x the performance of Light Mode which only requires 256MB of RAM. Fast mode is intended for dedicated miners. Light mode is designed to allow fullnodes to validate blocks without requiring the 2+GB of RAM

<o​frnxmr:monero.social> Validating blocks is pretty slow. I assume we'd have much better sync performance if we allowed fast mode by default, with opt in light mode. 2gb ram isnt much these days

<o​frnxmr:monero.social> Fast validation is more important than supporting running node on your smart toaster imo. We've seen a lot of issues on stressnet that are (probably or partly) due to slow-to-verify large blocks.

<s​yntheticbird:monero.social> cc boog900

<b​oog900:monero.social> There is a flag for that IIRC so you could test it

<b​oog900:monero.social> monerod and cuprate will both cache 2 VMs as well

kewbit: prefer .org for open-source projects en.wikipedia.org/wiki/.org

<k​ewbit:matrix.org> Yeah it has that stigma

<o​frnxmr:monero.social> Do you know the flag?

<o​frnxmr:monero.social> I dont see any ref to randomx

<o​frnxmr:monero.social> --fast-block-sync is for checkpoints, not rx

<b​oog900:monero.social> ah it's an environment variable: github.com/monero-project/monero/bl…3623/src/crypto/rx-slow-hash.c#L207

<b​oog900:monero.social> and the second cached VM will only cache the RX cache not the full dataset even if this is enabled

<o​frnxmr:monero.social> So shouldnt we just enable full rx?

<s​yntheticbird:monero.social> Isn't fast-sync just avoiding randomX verification?

<o​frnxmr:monero.social> Yes

<o​frnxmr:monero.social> And no

<s​yntheticbird:monero.social> No, for the latest blocks for sure

<o​frnxmr:monero.social> its avoiding slow mode

<o​frnxmr:monero.social> Chdckpoints are uses til latest release hardcoded heights, so majority of BC isnt actually verified locally

<o​frnxmr:monero.social> After checkpoints (or with --fast-block-sync=0), it verifies with light/slow mode

<s​yntheticbird:monero.social> That was my understanding as well, and since it represent only the a minority of the chain, I don't see a reason to enable full rx in fast-sync.

<s​yntheticbird:monero.social> That was my understanding as well, and since it represent only the a minority of the chain, I don't see a reason to enable full rx in fast-sync, by default.

<o​frnxmr:monero.social> Im assuming you dont run a stressnet node 😡

<s​yntheticbird:monero.social> I don't like stress indeed.

<o​frnxmr:monero.social> Syncing blocks normally is a painfully long experience

<o​frnxmr:monero.social> Syncing 7gb testnet takes like 20hrs

<s​yntheticbird:monero.social> but only because you don't have checkpoints for the stressnet

<o​frnxmr:monero.social> Its not scalable

<o​frnxmr:monero.social> Nodes reorg and take a long time to verify blocks

<o​frnxmr:monero.social> No, its because we have big blocks with 5000 tx in them

<s​yntheticbird:monero.social> If we take post-RCT timing (and enormous tx volume), this is reasonable with monerod syncing in full-sync.

<s​yntheticbird:monero.social> anyway my point is enabling full RX by default wouldn't make sense for fast-sync but for full-sync it does.

<o​frnxmr:monero.social> chdckpoints arent a solution. They speed up initial sync. They dont so anything for syncing a 7mb block

<o​frnxmr:monero.social> "full sync" is literally "running a node"

<o​frnxmr:monero.social> It shouldnt take 30sec to sync a block

<s​yntheticbird:monero.social> bro you understand me full-sync = no-fast-sync

<o​frnxmr:monero.social> Fast sync is a hack so ppl dont see how long it takes to verify

<o​frnxmr:monero.social> Yes, and it also means "the next block"

<o​frnxmr:monero.social> If the next block it 5mb, it takes like 30secs to sync. (i dont remember exact time)

<o​frnxmr:monero.social> Thats _way_ to long to propagate without being reorged

<b​oog900:monero.social> I wouldn't think enabling RX fast mode would actually help much here

<o​frnxmr:monero.social> that sucks.

<o​frnxmr:monero.social> I assumed (blindly) that it would be a similar 4-6x speedup

<b​oog900:monero.social> It would be a 4-6x speed up of RX but if RX only takes up 1% of the time to verify it wouldn't change much

<o​frnxmr:monero.social> How do we know the % is 1 and not 99?

<o​frnxmr:monero.social> What other ops are taking up the time?

<b​oog900:monero.social> I don't, it might make a difference on mainnet, however the cost of RX should be the same no matter the tx count

<b​oog900:monero.social> So it makes me think something else is taking up the time on stressnet

<o​frnxmr:monero.social> there shouldnt be any diff between networks at chain tip aside from block size and tx pool

<b​oog900:monero.social> exactly so the fact we don't take 30s to sync a block on mainnet makes me think RX isn't the issue here. However using RX full mem could still reduce block verification by on non trivial amount compared to normal mainnet time.

<o​frnxmr:monero.social> Mainnet blocks are 300kb vs 5mb on stressnet .. .. ..

<o​frnxmr:monero.social> Stressnet runs fine with 300kb blocks too

<o​frnxmr:monero.social> (were not at 5mb right now, but verification time seemingly grows with block size)

<b​oog900:monero.social> I know, all I am saying is this means RX full mem won't help

<o​frnxmr:monero.social> The more tx youre verifying, the longer it takes. Maybe its not rx, but you see the same slowdoen when popping blocks with a full tx pool

<o​frnxmr:monero.social> same slowdown when starting up the node with a large txpool

<o​frnxmr:monero.social> Which leads me to believe that # of tx definitely does matter

<o​frnxmr:monero.social> We can skip verification, which makes things near instant, so its not an io issue

<r​ucknium:monero.social> ofrnxmr: AFAIK. It's tx verification time. See my Table 1 on page 6: github.com/Rucknium/misc-research/b…ck-marble-optimal-fee-ring-size.pdf

<r​ucknium:monero.social> With ring size 16, block size 443KB, it takes 2.69 seconds to verify all txs in the block.

<r​ucknium:monero.social> See Appendix A for how those estimates were obtained.

<b​oog900:monero.social> I said for the cost of RX ... the number of txs defiantly matters for verification time