03:30:18 -xmr-pr- tryphe opened issue #8194: Cannot sync past block ~2450000
03:30:18 -xmr-pr- > https://github.com/monero-project/monero/issues/8194
03:37:34 <selsta> 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
03:37:42 <selsta> I think that's more realistic than OpenCL
08:18:44 <hyc> moneromooo https://old.reddit.com/r/Monero/comments/t21q3l/hunting_for_logic_bugs_in_monero/hymeexr/
08:19:08 <hyc> this regarding commit f6e2636493970f3cf3279fd9773efe211868ffb4
08:20:46 <hyc> 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.
08:41:08 <moneromooo> lol
08:41:46 <moneromooo> Undoing things manually everywhere would be pretty annoying. Lots of code.
08:42:01 <moneromooo> And code that'd probably be buggy.
08:42:28 <moneromooo> So this is really "how monero ensures things are cancelled right".
08:42:42 <hyc> yeah, and avoiding all that is why you use an ACID transactional DB in the first place
08:45:52 <moneromooo> hyc: I had asked that a while ago, didn't get a reply, but:
08:46:45 <moneromooo> 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.
08:47:27 <hyc> you can read multiple values for the same DUPFIXED key
08:47:37 <hyc> there is no other multiple-fetch option
08:48:16 <hyc> and if N is small it's not like you'd save much overhead anyway
08:48:16 <moneromooo> If you mean MDB_NEXT_MULTIPLE and friends, htose are unlikely to help in my case.
08:48:45 <moneromooo> N would be... a couple hundred maybe. DB size would be a few dozen millions.
08:49:27 <hyc> doesn't sound like it'd make a difference
08:49:41 <moneromooo> OK, fair enough.
08:49:51 <hyc> all you really need to do is keep reusing the same cursor
08:50:02 <hyc> that will avoid the worst overhead
08:50:25 <moneromooo> Yes, already the case.
08:52:05 <hyc> you can experiment with this https://bugs.openldap.org/show_bug.cgi?id=9769
08:52:35 <hyc> submitter claims a 2x speedup
08:52:47 <hyc> I haven't had time to test it myself yet
08:53:16 <hyc> it looks like it just returns a page's worth of contiguous records.
08:53:31 <hyc> if you're doing random lookups, it probably won't help
08:54:18 <moneromooo> Yes, I expect the locality to be very poor, though not inexistent.
08:56:24 <hyc> if you profile mdb_cursor_get() workload I doubt you will find any hotspot that can be removed...
17:26:10 <Guest54> Hello
17:28:08 <bootlegbilly[m]> Hi
17:50:00 <selsta> moneromooo: do you see anything interesting in the logs here? https://github.com/monero-project/monero/issues/8194#issuecomment-1053098301
17:50:08 <selsta> the whole issue sounds weird
18:02:29 <moneromooo> The first few blocks that are needed are requested from a peer that doesn't send them.
18:02:48 <moneromooo> The timeout seems to be 25 seconds here.
18:04:48 <moneromooo> 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.
18:27:18 <selsta> it's weird that they were able to reproduce it until they updated their OS
18:27:25 <selsta> maybe bad luck
18:31:15 <moneromooo> There are two instances of possible large delays in networking. So, who knows.