22:41 <fluffypony> what about using OpenCL during IBD? <-- using ASM only for the initial blockchain sync is safe with forks and most of the code is already ready

I think that's more realistic than OpenCL

moneromooo old.reddit.com/r/Monero/comments/t2…ng_for_logic_bugs_in_monero/hymeexr

this regarding commit f6e2636493970f3cf3279fd9773efe211868ffb4

the commit is an improvement since it no longer tries to issue deletes that would be tossed anyway, but there was never any impact. txn abort means everything that happened since start of txn just disappears, never happened.

lol

Undoing things manually everywhere would be pretty annoying. Lots of code.

And code that'd probably be buggy.

So this is really "how monero ensures things are cancelled right".

yeah, and avoiding all that is why you use an ACID transactional DB in the first place

hyc: I had asked that a while ago, didn't get a reply, but:

If I have a large LMDB table, and want to query N items from it, with N being small compared to the table size, can I speed up lookups with some kind of multiple query ? AFAICT, MDB_MULTIPLE is only for writing.

you can read multiple values for the same DUPFIXED key

there is no other multiple-fetch option

and if N is small it's not like you'd save much overhead anyway

If you mean MDB_NEXT_MULTIPLE and friends, htose are unlikely to help in my case.

N would be... a couple hundred maybe. DB size would be a few dozen millions.

doesn't sound like it'd make a difference

OK, fair enough.

all you really need to do is keep reusing the same cursor

that will avoid the worst overhead

Yes, already the case.

you can experiment with this bugs.openldap.org/show_bug.cgi?id=9769

submitter claims a 2x speedup

I haven't had time to test it myself yet

it looks like it just returns a page's worth of contiguous records.

if you're doing random lookups, it probably won't help

Yes, I expect the locality to be very poor, though not inexistent.

if you profile mdb_cursor_get() workload I doubt you will find any hotspot that can be removed...

Hello

Hi

moneromooo: do you see anything interesting in the logs here? monero-project/monero #8194#issuecomment-1053098301

the whole issue sounds weird

The first few blocks that are needed are requested from a peer that doesn't send them.

The timeout seems to be 25 seconds here.

The blocks then get requested from another peer, but that peer gets dropped after it sends a reply to another message. Possible state machine bug here.

it's weird that they were able to reproduce it until they updated their OS

maybe bad luck

There are two instances of possible large delays in networking. So, who knows.