On linux mint 17 64 bit on disk blokchain 3.1 GB (3102867674 bytes)
pid aeon In RAM
heap 1/ 3,8 Gb
.........2/ 310 Mb
..........3/ 128 Mb
..........4/ 128 Mb
..........5/ 128 Mb
after this stack 9075 // 13 times average 70 - 60 Mb total around 1GB
if this something help....
If it's possible not to load all blockchain in ram, only part .....
And some incremental write blockchain on disk .....
Like DSH coin >
blocksindexes.dat
blocks.dat
blockscache.dat
Topic: [ANN] AEON [2019-09-27: Upgrade to version 0.13.0.0 ASAP HF@1146200 Oct 25] - page 236. (Read 625666 times)
August 11, 2015, 05:29:54 PM
August 11, 2015, 04:38:16 PM
The file is 2.9 GB but that also contains redundant information. The actual blockchain itself is about 1.3 GB.
For example, block hashes are stored three times -- once a block hash to block map, once in block hash to height map, and once in the previous block field of each header. This is all entirely reasonable except that I haven't been able to get the numbers to make sense with what is actually being used.
For example, block hashes are stored three times -- once a block hash to block map, once in block hash to height map, and once in the previous block field of each header. This is all entirely reasonable except that I haven't been able to get the numbers to make sense with what is actually being used.
confirming 5009MB RAM on my system, blockchain.bin itself is 2.9GB
I plan to use it but it is clearly not quite ready (no official release from Monero and bug fixes still being committed for it, on which I have been helping MoneroMooo). I feel merging it now would likely cause problems and would certainly cause additional work continuing to merge bug fixes.
In hindsight if AEON had existed in its present form developing a database for it first would have been a reasonable idea.
I have a pruning solution that is almost ready to release for AEON which will reduce memory usage and even with a database will still be useful to limit disk usage for smaller devices with limited storage.
However, I'm having some issues with tracking down the source of a lot of excess RAM usage. The AEON blockchain, in terms of actual data, is only about 1.3 GB, so the (unpruned) memory usage of roughly 5 GB seems quite excessive. I have accounted for a lot of the extra copies of data being stored (correctly) but the numbers still don't add up. The same sort of extra memory use persists with pruning and I'm trying to figure out why.
I notice demon load all blockchain in ram, 3.1 gb
Interesting. On my test systems it is about 5 GB. I'll continue to investigate.
smooth, do you have plans to use the current LMDB that is being developed on Monero? Don't you think it is a good idea to release it on AEON first to see how it would play out on Monero.
I plan to use it but it is clearly not quite ready (no official release from Monero and bug fixes still being committed for it, on which I have been helping MoneroMooo). I feel merging it now would likely cause problems and would certainly cause additional work continuing to merge bug fixes.
In hindsight if AEON had existed in its present form developing a database for it first would have been a reasonable idea.
I have a pruning solution that is almost ready to release for AEON which will reduce memory usage and even with a database will still be useful to limit disk usage for smaller devices with limited storage.
However, I'm having some issues with tracking down the source of a lot of excess RAM usage. The AEON blockchain, in terms of actual data, is only about 1.3 GB, so the (unpruned) memory usage of roughly 5 GB seems quite excessive. I have accounted for a lot of the extra copies of data being stored (correctly) but the numbers still don't add up. The same sort of extra memory use persists with pruning and I'm trying to figure out why.
Interesting. On my test systems it is about 5 GB. I'll continue to investigate.
August 11, 2015, 04:34:56 PM
confirming 5009MB RAM on my system, blockchain.bin itself is 2.9GB
I plan to use it but it is clearly not quite ready (no official release from Monero and bug fixes still being committed for it, on which I have been helping MoneroMooo). I feel merging it now would likely cause problems and would certainly cause additional work continuing to merge bug fixes.
In hindsight if AEON had existed in its present form developing a database for it first would have been a reasonable idea.
I have a pruning solution that is almost ready to release for AEON which will reduce memory usage and even with a database will still be useful to limit disk usage for smaller devices with limited storage.
However, I'm having some issues with tracking down the source of a lot of excess RAM usage. The AEON blockchain, in terms of actual data, is only about 1.3 GB, so the (unpruned) memory usage of roughly 5 GB seems quite excessive. I have accounted for a lot of the extra copies of data being stored (correctly) but the numbers still don't add up. The same sort of extra memory use persists with pruning and I'm trying to figure out why.
I notice demon load all blockchain in ram, 3.1 gb
Interesting. On my test systems it is about 5 GB. I'll continue to investigate.
smooth, do you have plans to use the current LMDB that is being developed on Monero? Don't you think it is a good idea to release it on AEON first to see how it would play out on Monero.
I plan to use it but it is clearly not quite ready (no official release from Monero and bug fixes still being committed for it, on which I have been helping MoneroMooo). I feel merging it now would likely cause problems and would certainly cause additional work continuing to merge bug fixes.
In hindsight if AEON had existed in its present form developing a database for it first would have been a reasonable idea.
I have a pruning solution that is almost ready to release for AEON which will reduce memory usage and even with a database will still be useful to limit disk usage for smaller devices with limited storage.
However, I'm having some issues with tracking down the source of a lot of excess RAM usage. The AEON blockchain, in terms of actual data, is only about 1.3 GB, so the (unpruned) memory usage of roughly 5 GB seems quite excessive. I have accounted for a lot of the extra copies of data being stored (correctly) but the numbers still don't add up. The same sort of extra memory use persists with pruning and I'm trying to figure out why.
Interesting. On my test systems it is about 5 GB. I'll continue to investigate.
August 11, 2015, 04:24:51 PM
smooth, do you have plans to use the current LMDB that is being developed on Monero? Don't you think it is a good idea to release it on AEON first to see how it would play out on Monero.
I plan to use it but it is clearly not quite ready (no official release from Monero and bug fixes still being committed for it, on which I have been helping MoneroMooo). I feel merging it now would likely cause problems and would certainly cause additional work continuing to merge bug fixes.
In hindsight if AEON had existed in its present form developing a database for it first would have been a reasonable idea.
I have a pruning solution that is almost ready to release for AEON which will reduce memory usage and even with a database will still be useful to limit disk usage for smaller devices with limited storage.
However, I'm having some issues with tracking down the source of a lot of excess RAM usage. The AEON blockchain, in terms of actual data, is only about 1.3 GB, so the (unpruned) memory usage of roughly 5 GB seems quite excessive. I have accounted for a lot of the extra copies of data being stored (correctly) but the numbers still don't add up. The same sort of extra memory use persists with pruning and I'm trying to figure out why.
Interesting. On my test systems it is about 5 GB. I'll continue to investigate.
August 11, 2015, 04:22:03 PM
smooth, do you have plans to use the current LMDB that is being developed on Monero? Don't you think it is a good idea to release it on AEON first to see how it would play out on Monero.
I plan to use it but it is clearly not quite ready (no official release from Monero and bug fixes still being committed for it, on which I have been helping MoneroMooo). I feel merging it now would likely cause problems and would certainly cause additional work continuing to merge bug fixes.
In hindsight if AEON had existed in its present form developing a database for it first would have been a reasonable idea.
I have a pruning solution that is almost ready to release for AEON which will reduce memory usage and even with a database will still be useful to limit disk usage for smaller devices with limited storage.
However, I'm having some issues with tracking down the source of a lot of excess RAM usage. The AEON blockchain, in terms of actual data, is only about 1.3 GB, so the (unpruned) memory usage of roughly 5 GB seems quite excessive. I have accounted for a lot of the extra copies of data being stored (correctly) but the numbers still don't add up. The same sort of extra memory use persists with pruning and I'm trying to figure out why.
August 11, 2015, 04:13:28 PM
smooth, do you have plans to use the current LMDB that is being developed on Monero? Don't you think it is a good idea to release it on AEON first to see how it would play out on Monero.
I plan to use it but it is clearly not quite ready (no official release from Monero and bug fixes still being committed for it, on which I have been helping MoneroMooo). I feel merging it now would likely cause problems and would certainly cause additional work continuing to merge bug fixes.
In hindsight if AEON had existed in its present form developing a database for it first would have been a reasonable idea.
I have a pruning solution that is almost ready to release for AEON which will reduce memory usage and even with a database will still be useful to limit disk usage for smaller devices with limited storage.
However, I'm having some issues with tracking down the source of a lot of excess RAM usage. The AEON blockchain, in terms of actual data, is only about 1.3 GB, so the (unpruned) memory usage of roughly 5 GB seems quite excessive. I have accounted for a lot of the extra copies of data being stored (correctly) but the numbers still don't add up. The same sort of extra memory use persists with pruning and I'm trying to figure out why.
August 11, 2015, 03:39:53 PM
+1
Would rather see LMDB support come before GUI. CN light is already heading in the right direction low end PC's.
Would rather see LMDB support come before GUI. CN light is already heading in the right direction low end PC's.
smooth, do you have plans to use the current LMDB that is being developed on Monero? Don't you think it is a good idea to release it on AEON first to see how it would play out on Monero.
I would like to point other solution to the RAM usage but no Cryptonote coin but Monero is developing one from scratch.
I would like to point other solution to the RAM usage but no Cryptonote coin but Monero is developing one from scratch.
August 11, 2015, 01:13:57 PM
smooth, do you have plans to use the current LMDB that is being developed on Monero? Don't you think it is a good idea to release it on AEON first to see how it would play out on Monero.
I would like to point other solution to the RAM usage but no Cryptonote coin but Monero is developing one from scratch.
I would like to point other solution to the RAM usage but no Cryptonote coin but Monero is developing one from scratch.
August 11, 2015, 11:46:37 AM
This is a reminder that, as of now, Minergate and Chainradar are both on the WRONG fork of the Aeon blockhain, as they seem to still not have updated their daemon.
Current block height is 594648.
Note that while chainradar shows 599580, this does not mean they have more cumulative weight, as the new block target is 4 minutes.
Current block height is 594648.
Note that while chainradar shows 599580, this does not mean they have more cumulative weight, as the new block target is 4 minutes.
August 10, 2015, 09:09:25 PM
New to Aeon. I like the way things look here. I am taking note of this Cryptonote. 
August 10, 2015, 08:27:53 PM
Right, I got that I thought he had found the actual reason.
I guess it has to be the GF, as he gets the correct IP, but even ping times out (from PM).
I thought he had found the actual reason.I guess it has to be the GF, as he gets the correct IP, but even ping times out (from PM).
Should be the government banned access to your address , only to visit your pool through the wall software
August 10, 2015, 04:03:20 PM
I spotted a problem with daemon on my pool. i suspect it to be the source of two orphaned blocks.
to solve it, i will restart a daemon with a new conf in a few moments. (I take this opportunity to upgrade to 0.9.1.1 too)
my apologies for the downtime. (espected time: several minutes.)
i'm aware it's boring but everything has to be tried against orphaned blocks.
[edit] done. everything must be ok now
to solve it, i will restart a daemon with a new conf in a few moments. (I take this opportunity to upgrade to 0.9.1.1 too)
my apologies for the downtime. (espected time: several minutes.)
i'm aware it's boring but everything has to be tried against orphaned blocks.
[edit] done. everything must be ok now
August 10, 2015, 01:44:51 PM
Right, I got that I thought he had found the actual reason.
I guess it has to be the GF, as he gets the correct IP, but even ping times out (from PM).
I thought he had found the actual reason.I guess it has to be the GF, as he gets the correct IP, but even ping times out (from PM).
August 10, 2015, 12:24:42 PM
I know what the reason, I do not pass your pond wall software Rom（VPN）
I'm sorry, I can't quite understand what you mean here.
He can't access your pool, but he can apparently access Arux's pool.
There is some kind of firewall or routing issue, maybe GFOC.
August 10, 2015, 12:22:28 PM
I know what the reason, I do not pass your pond wall software Rom（VPN）
I'm sorry, I can't quite understand what you mean here.
August 10, 2015, 07:05:21 AM
no payouts Again 
Wow it didn't last long this time.
Consolidated again. Interestingly, only one payment per batch failed overnight, and the other 4-5 of each batch went through just fine. Your payment just needs too many outputs
I've decreased the batch size as well now, which should help too.Sorry about that.
Thank you
August 10, 2015, 06:45:24 AM
That is odd.
The first miner seems to be Wolf's. It works on Arux' pool but not mine, can you confirm ?
The second miner seems to be LJ's. There was a bug in that miner which caused the hashes to be wrong. This was fixed two days ago or so, so make sure you have the most recent version.
If I try your first command:
minerd -a cryptonight-light -o stratum+tcp://52.8.47.33:3333 -u
WmtVTeq17d57y1gHwB6LwNNR41GwvgdKSBNd272WF7D931cXZRsHtFzTm9JkFHsZbuWV5Pr8Te2dwVV B
MZMeo8Pn2Ebx6dZaw -p x
Then I can connect to Arux' pool, and changing the IP to my pool also works (there was a space in the address, but I think it's just BCT adding it).
I don't see connections for this address apart from my tests, nor bans, so it looks like your connection is stopped before it reaches the server.
I know what the reason, I do not pass your pond wall software Rom（VPN） The first miner seems to be Wolf's. It works on Arux' pool but not mine, can you confirm ?
The second miner seems to be LJ's. There was a bug in that miner which caused the hashes to be wrong. This was fixed two days ago or so, so make sure you have the most recent version.
If I try your first command:
minerd -a cryptonight-light -o stratum+tcp://52.8.47.33:3333 -u
WmtVTeq17d57y1gHwB6LwNNR41GwvgdKSBNd272WF7D931cXZRsHtFzTm9JkFHsZbuWV5Pr8Te2dwVV B
MZMeo8Pn2Ebx6dZaw -p x
Then I can connect to Arux' pool, and changing the IP to my pool also works (there was a space in the address, but I think it's just BCT adding it).
I don't see connections for this address apart from my tests, nor bans, so it looks like your connection is stopped before it reaches the server.
August 10, 2015, 03:11:51 AM
no payouts Again
Wow it didn't last long this time.
Consolidated again. Interestingly, only one payment per batch failed overnight, and the other 4-5 of each batch went through just fine. Your payment just needs too many outputs
I've decreased the batch size as well now, which should help too.Sorry about that.
August 10, 2015, 02:22:08 AM
MoneroMooo
Pool Pending Balance raising without payouts.
Pool Pending Balance raising without payouts.
Thanks, I've just consolidated coins again. Payouts will restart as soon as they unlock.
August 09, 2015, 05:35:38 PM
@GingerAle,
I'm out and just online a couple of minutes a day for all of the week ahead, so I can't help much with troubleshooting during this time. However, here are some important basics:
- cuda toolkit 7.0 is largely broken, and will cause most miner software to spit invalid hashes
- good cuda toolkits are 6.5 (standard, usually fastest), and 7.5 RC (developer exclusive, usually slower, bleeding edge)
- you need to edit configure.sh (linux), or VStudio project cuda properties (windows), to match your desired target architecture
The miner should launch with the same -l settings as you would previously used with regular cryptonight, but you can add some more blocks or threads as the light variant uses less memory (so you might hash faster with more threads). The light version is selected in ccminer, by adding -A to your launch string.
I've had confirmations of the miner working on Windows, on Linux, and all cards of compute level 3.5 & 5.x. Some lower compute levels should also work, but I have no experience on these, nor access to them. I've even used this ccminer on AWS already for kicks, works just fine (and can burn one's credit card really fast)
Good Luck!
I'm out and just online a couple of minutes a day for all of the week ahead, so I can't help much with troubleshooting during this time. However, here are some important basics:
- cuda toolkit 7.0 is largely broken, and will cause most miner software to spit invalid hashes
- good cuda toolkits are 6.5 (standard, usually fastest), and 7.5 RC (developer exclusive, usually slower, bleeding edge)
- you need to edit configure.sh (linux), or VStudio project cuda properties (windows), to match your desired target architecture
The miner should launch with the same -l settings as you would previously used with regular cryptonight, but you can add some more blocks or threads as the light variant uses less memory (so you might hash faster with more threads). The light version is selected in ccminer, by adding -A to your launch string.
I've had confirmations of the miner working on Windows, on Linux, and all cards of compute level 3.5 & 5.x. Some lower compute levels should also work, but I have no experience on these, nor access to them. I've even used this ccminer on AWS already for kicks, works just fine (and can burn one's credit card really fast)
Good Luck!
Jump to: