-
binaryFate
selsta:
community.rino.io/blocks/frequencies is back up, thanks for letting us know
-
garth
I never realized that. Thanks
-
Mochi101
selsta, I'll start it syncing as soon as this one is done... Last blocks are slow... Mass adoption is real.
-
selsta
mine is at 96%
-
Mochi101
I'm at 99%
-
selsta
-
Mochi101
He should get off and he should sue them for the lost year of life.
-
Mochi101
11635 blocks left... these last ones are difficult...
-
Mochi101
Not sure how monerod is calculating that estimated time left but I really don't think it's accurate.
-
mesaoptimizer
cryptwerk.com/pay-with/xmr = cryp Twerk. who even makes these names
-
Mochi101
<10k for a full sync selsta!
-
Guest63
I sent a transaction to a pre-0.18 node that appears to be bricked (stuck at 2688888). I think my transaction is sitting in their memory pool and is not being relayed, because I can't find the transaction on xmrchain.net. It appears like my wallet balance is Y - X where X is the amount of XMR I sent in a transaction to the bricked node. How can I
-
Guest63
confirm that the inputs I used to generate the tranasction sent to the bricked node are considered unspent by my wallet?
-
moneromooo
Try "incoming_transfers" in monero-wallet-cli. It'll display all outputs, whether they're spent, and in which tx.
-
moneromooo
If that tx is not mined (in your copy of the chain), those outputs will show as unspent.
-
Guest63
Okay, I do not see the transaction id of the transaction (6fa3cfa75ef51d194dfbceac9714fd67c89eded4ce7711fe36b2b7ee7d74647c) I relayed to the bricked node there. So I assume that my current balance is correct and I can spend the outputs that I previously used in the transaction to the bricked node.
-
Guest63
Is my assumption above correct?
-
moneromooo
Yes.
-
Guest63
Cheers, thank you for your help. Donated 0.1 XMR to the Dev fund.
-
moneromooo
A little pony does a happy dance somewhere.
-
Guest63
66ffb708a0069f55738838f22311d04aba8d0eff2e1660a6fe1856c06f8a23dd
-
Guest63
Heading off now. Peace
-
Mochi101
selsta, 38h 16m to sync. Starting now with the patched daemon.
-
selsta
mine took 8h 10min
-
selsta
hopefully the lmdb patches speed things up
-
hyc
are you using non-default db-sync-mode? probably should, in this case
-
hyc
e.g. db-sync-mode=fast:async:1000000
-
Mochi101
just a normy start my daemon with zero flags type sunc
-
Mochi101
like anybody off the street would do
-
hyc
ok, I guess it'll be a good data point
-
Mochi101
ie: normal people who just want to get on the road to mass adoption
-
Mochi101
:D
-
Mochi101
but now I'm syncing with selsta's patched version
-
hyc
but that means there's an automatic sync performed...
-
Mochi101
sorry?
-
hyc
hang on, looking up the details
-
selsta
hyc: isn't that only done after the initial sync?
-
Mochi101
selsta, how come you included the wallet cli in the archive? Is it any different?
-
dsc_
< Mochi101> ie: normal people who just want to get on the road to mass adoption <== I tried to make Feather as plug-n-play as possible, as the original idea was: "sane defaults for noobs who previously used Electrum wallet" and yes some xmr devs dont like that approach but oh well :P there are different target audiences
-
dsc_
Mochi101: also 'normies' (your words) dont use the CLI (I would assume)
-
Mochi101
I think targetting the normies is the way to go.
-
selsta
we include all CLI tools
-
Mochi101
mmm... ok... this is true too dsc_
-
dsc_
you are a closet expert
-
Mochi101
Not an expert dsc_. More of a power user I'd say.
-
dsc_
Mochi101: dont hide your inner desire to prefer terminal interfaces, nothing to be ashamed about
-
Mochi101
I like the CLI wallet over any GUI wallet. But that probably stems from my experience with the GUI before it could smoothly handle wallets with 10s of thousands of transactions.
-
Mochi101
Neither Moneroju or Cake can handle my wallets either.
-
Mochi101
I reported this on their Githubs so hopefully they address the issues.
-
Mochi101
23% selsta
-
hyc
ok it seems like the timed fsync the code used to do is gone now, anyway
-
Mochi101
A little over 1 hour in and I'm at 50% selsta
-
Mochi101
selsta, did you remove the code for the estimated time left to sync?
-
selsta
no
-
Mochi101
doesn't seem to be giving me this anymore
-
selsta
it should be v0.18.1.0 with the lmdb patch
-
Mochi101
55% and I haven't received one message about estimated hours left to sync
-
selsta
it only gets printed once in a while
-
selsta
if you scroll up it never got printed?
-
Mochi101
nope
-
Mochi101
Not that it was very accurate anyways.
-
Mochi101
Especially the last 100k blocks.
-
selsta
rbrunner: any idea why it would not print?
-
rbrunner
I noticed that as well that sometimes it stops to print the ETA estimates, but never got to the bottom of it.
-
rbrunner
Most of the time simply restarting the daemon gets the estimates back.
-
rbrunner
I think it has to do with the fact that syncing is a quite complicated multi-threaded process, and it seems to have a way to proceed that never passes the point in code anymore where I print
-
Mochi101
Maybe the patch makes the syncing so fast that the daemon can't even calculate it anymore.
-
Mochi101
:D
-
rbrunner
Yeah, genius theory.
-
rbrunner
:)
-
Mochi101
Oh I got a sync message selsta, rbrunner... finally: 2022-08-15 19:14:47.362 I Synced 1790240/2690289 (66%, 900049 left, 1% of total synced, estimated 10.0 hours left)
-
Mochi101
oh manybe because of block size the first 66% of blocks equals 1% of the sync in block size and it can't calculate below 1% ?
-
Mochi101
estimated time is going up now though
-
rbrunner
It's true that early blocks (2014 to 2016 or so) contain many less txs than later blocks and sync much faster, but it's not extreme enough to completely throw off calculation
-
Mochi101
I didn't notice if it had messages or not before 66% synced on the unpatched daemon.
-
Mochi101
This really "feels" a lot faster.
-
Mochi101
Just my perception though, reality will be in the numbers at the end.
-
hyc
did you record timings at various points along the way, the last time?
-
Mochi101
hyc, sadly no
-
Mochi101
I never thought about it.
-
selsta
from what I have seen from IRC chat log timing, so far there is no large difference
-
Mochi101
selsta, on a windows system?
-
hyc
yeah I would guess at most there will be a small reduction in CPU time
-
hyc
and if it's I/O bound anyway, that's not going to matter much
-
selsta
let's wait for it to finish
-
hyc
the existing code doing explicit Flushes spends a lot of CPU time finding which pages to flush, but the number of I/Os is still what it is
-
hyc
with the patch, the explicit Flushes aren't needed, but the number of I/Os is still the same
-
moneromooo
You can chek times from log timestmaps, assuming you did not nuke logs.
-
selsta
Mochi101: you posted when you started syncing and when you were at specific percentages, so far it looks close to identical
-
selsta
addding supercop would speed things up a lot
-
hyc
I suppose we could try to test crash recovery by running in a VM and randomly doing kill -9 on the VM while syncing
-
hyc
if that corrupts things on the old code but not with the patch, then we won
-
rbrunner
By the way, here you can see how much the average block sizes vary depending on height, in that hack that I implemented to improve the estimates:
-
rbrunner
-
Mochi101
yeah, I was looking at that earlier rbrunner. That's why I mentioned that it might not be able to calculate before 1% synced by size which is 66% of total blocks