Aeon 'Chronos' (v0.14.1.0-e3ed1d0e6)

[DeadManWalkingTO]

Original release v0.14.1 (win 64bit) have sync/connection errors...
Build from source (win 64bit) (v0.14.1.0-e3ed1d0e6) have fix those errors!!!

[yodel-settles]

I see same sync/connections errors, daemon consistently stalls out

can any devs comment?

[stoffu]

The hard-codes seed nodes in v0.14.1.0 became non-operational at some point, and have been updated in #235, #238, #256. This is the main reason why we’re preparing for the new release v0.14.2.0.
#257

[yodel-settles]

how do I build from source, binaries are a no-go for me , sorry

[stoffu]

git clone --recursive https://github.com/aeonix/aeon
cd aeon
make

[yodel-settles]

that builds 0.14.1.0 tho correct? which has connection issues? how do I build 0.14.2.0 from source?

[stoffu]

No, v0.14.1.0-aeon is a particular tag given to a specific commit 612714c which has the seed node issue. The above command checks out the latest commit of the master branch which currently is e3ed1d0 where the seed node issue is fixed.

The release v0.14.2.0 has not yet been made.

[yodel-settles]

No, that specific commit does not fix the seed node issue.

2022-03-05 19:56:03.759 [P2P5] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:1179 [207.244.253.23:11180 OUT] Synced 431608/1450620 (29% 1019012 blocks remaining)
2022-03-05 19:56:05.436 [P2P2] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:1179 [207.244.253.23:11180 OUT] Synced 431808/1450620 (29% 1018812 blocks remaining)
2022-03-05 19:56:07.066 [P2P4] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:1179 [207.244.253.23:11180 OUT] Synced 432008/1450620 (29% 1018612 blocks remaining)
2022-03-05 19:56:08.778 [P2P2] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:1179 [207.244.253.23:11180 OUT] Synced 432208/1450621 (29% 1018413 blocks remaining)
2022-03-05 19:56:10.378 [P2P9] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:1179 [207.244.253.23:11180 OUT] Synced 432408/1450621 (29% 1018213 blocks remaining)
2022-03-05 19:56:11.953 [P2P4] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:1179 [207.244.253.23:11180 OUT] Synced 432608/1450621 (29% 1018013 blocks remaining)
2022-03-05 20:14:13.964 [P2P5] WARN global src/p2p/net_node.inl:1344 No incoming connections - check firewalls/routers allow port 11180
2022-03-05 21:14:14.036 [P2P8] WARN global src/p2p/net_node.inl:1344 No incoming connections - check firewalls/routers allow port 11180

[stoffu]

Your node is syncing just fine. The warning message is just suggesting you to open port 11180 so that others can download blocks from your node.

[yodel-settles]

I do not believe my node is running fine. I will run it for 72 hours and report back here, which I have already done before with your previously mentioned commits.

[yodel-settles]

I am not using Docker or TOR, why is there an issue with 11180? Why is it not mentioned in the basic instructions?

[stoffu]

You will eventually see "SYNCHRONIZED OK" message when your node catches up 100% with the network.

It’s common that your router or firewall to block incoming connections by default.

You don’t have to open the port and ignore the warning.

[yodel-settles]

Thanks, I am ignoring that warning, seems like network needs more nodes?

It is up to 65% right now 500382 blocks for me.

Network sync is much slower than in years past, seems borderline frustrating to use. It seems like if you quit the daemon and restart it, it seems to progress further, but if you just leave the daemon running, it does not sync as fast, if at all seemingly.

Is there a need to spin up more seed nodes?

When new release v0.14.2.0 is released, that will be good, but only if the sync is fast, otherwise the pruning/mobile/small block chain size aspect of this coin that originally drew me to it is not as much of an advantage. It's hard to have a mobile phone running this long to sync the chain from block 0 to block 100%.

[stoffu]

The number of seed nodes doesn’t affect the sync speed. Sync is very slow if your storage is a spinning hard disk drive rather than an SSD. Otherwise, sync speed is determined by the number of transactions in each block; if the usage gets higher, the sync time gets necessarily longer. There’s no getting around this principle. Pruned node only reduces the required storage size, not the sync time.

[yodel-settles]

My storage is SSD with 50GB+ free space.

It it still stuck at [206.189.157.58:11180 OUT] Synced 950304/1450686 (65% 500382 blocks remaining)

I used to be able to sync into the 1,000,000+ blocks just fine. Now, it gets stuck around block 950304. Stuck for over an hour on the same block? So the computational time for the transactions argument makes no sense based on past experience.

I am using Ubuntu 20.04.4 LTS Focal so that has got to be part of the issue. But I will try on 18.04 VM at some point soon.

The daemon gets hung up completely on 20.04.4 LTS Focal

This looks like a daemon crash to me.

Any other insights?

[yodel-settles]

I just got done testing the daemon on Ubuntu 18.04 and it stalls out too with the exact same behavior as noted above. Got my first stall when syncing from block 0 at block 589840 40%