Author

Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 716. (Read 4670673 times)

legendary
Activity: 1106
Merit: 1000
So the new default directory to store block chain data in  is C:\ProgramData in Windows?
full member
Activity: 149
Merit: 100
Cant wait to try the new version!
legendary
Activity: 2968
Merit: 1198
Hydrogen Helix runs fantastic on OSX.  
Any plans for implementing the terminal buttons? (Tab for filling in, and up arrow for last command)?

Thanks!

rlwrap works on Linux (mentioned at the end of the README file). I don't know if there is an equivalent utility on OSX.
legendary
Activity: 1092
Merit: 1000
Hydrogen Helix runs fantastic on OSX. 
Any plans for implementing the terminal buttons? (Tab for filling in, and up arrow for last command)?

Thanks!
jr. member
Activity: 50
Merit: 5
Is the daemon supposed to pass blocks synced during a session out of memory?

The blockchain is stored on disk first and foremost.

Your OS might or might not also keep some portion of it in memory as a form of caching, depending on the amount of other memory usage on your computer.

The synced blocks during my sessions have been appearing in memory and grow until my memory is maxed out. These are cleared only when I exit the daemon.

The blockchain itself is being saved to disk, but my ram usage grows with each reported synced block. I am syncing from nothing. My programs hang as the memory becomes maxed out.

Is this a bug?

That does not sounds like you are using the current version.


I'll try resyncing from scratch again, as I'm almost caught up.

The version I am using is the HH release from github yesterday, windows.

It put 1.59 GB from my most recent session into memory over one hour. Note this is not what It starts up with, which is around 200 Mb. Just figured I'd ask, because I remembered you posting that it only took up a few hundred mb as well. In total it took 1.79 Gb before I restarted it.

TY smooth.

As I said it will use what you have. If no other programs are using the memory, then your OS will give it more (especially during sync). If other programs need RAM, the memory usage for the node will shrink down to almost nothing (especially once synced).

However, you shouldn't see anything hang. That was what I thought pointed to a problem.



I can't rule out that there is something else wrong with the OS currently.

Give me a few hours, I'll have a duplicate fresh OS installation on this HW and get back to you.
legendary
Activity: 2968
Merit: 1198
Is the daemon supposed to pass blocks synced during a session out of memory?

The blockchain is stored on disk first and foremost.

Your OS might or might not also keep some portion of it in memory as a form of caching, depending on the amount of other memory usage on your computer.

The synced blocks during my sessions have been appearing in memory and grow until my memory is maxed out. These are cleared only when I exit the daemon.

The blockchain itself is being saved to disk, but my ram usage grows with each reported synced block. I am syncing from nothing. My programs hang as the memory becomes maxed out.

Is this a bug?

That does not sounds like you are using the current version.


I'll try resyncing from scratch again, as I'm almost caught up.

The version I am using is the HH release from github yesterday, windows.

It put 1.59 GB from my most recent session into memory over one hour. Note this is not what It starts up with, which is around 200 Mb. Just figured I'd ask, because I remembered you posting that it only took up a few hundred mb as well. In total it took 1.79 Gb before I restarted it.

TY smooth.

As I said it will use what you have. If no other programs are using the memory, then your OS will give it more (especially during sync). If other programs need RAM, the memory usage for the node will shrink down to almost nothing (especially once synced).

However, you shouldn't see anything hang. That was what I thought pointed to a problem.

jr. member
Activity: 50
Merit: 5
Is the daemon supposed to pass blocks synced during a session out of memory?

The blockchain is stored on disk first and foremost.

Your OS might or might not also keep some portion of it in memory as a form of caching, depending on the amount of other memory usage on your computer.

The synced blocks during my sessions have been appearing in memory and grow until my memory is maxed out. These are cleared only when I exit the daemon.

The blockchain itself is being saved to disk, but my ram usage grows with each reported synced block. I am syncing from nothing. My programs hang as the memory becomes maxed out.

Is this a bug?

That does not sounds like you are using the current version.


I'll try resyncing from scratch again, as I'm almost caught up.

The version I am using is the HH release from github yesterday, windows.

It put 1.59 GB from my most recent session into memory over one hour. Note this is not what It starts up with, which is around 200 Mb. Just figured I'd ask, because I remembered you posting that it only took up a few hundred mb as well. In total it took 1.79 Gb before I restarted it.

TY smooth.
legendary
Activity: 2968
Merit: 1198
Is the daemon supposed to pass blocks synced during a session out of memory?

The blockchain is stored on disk first and foremost.

Your OS might or might not also keep some portion of it in memory as a form of caching, depending on the amount of other memory usage on your computer.

The synced blocks during my sessions have been appearing in memory and grow until my memory is maxed out. These are cleared only when I exit the daemon.

The blockchain itself is being saved to disk, but my ram usage grows with each reported synced block. I am syncing from nothing. My programs hang as the memory becomes maxed out.

Is this a bug?

That does not sound like you are using the current version. The usage, as I said, may increase if your OS decides to keep some of the blockchain in RAM as a cache. But that should not cause anything to hang. The memory usage should be freed up if needed.

But perhaps there is some other problem. It is hard to say on a forum. Maybe go freenode IRC, channel #monero, and see if someone can help you figure out what is going wrong.  https://webchat.freenode.net
newbie
Activity: 2
Merit: 0
XMR is doing great today and seems to have found a bottom around .001

I wonder where it's going to go from here.
jr. member
Activity: 50
Merit: 5
Is the daemon supposed to pass blocks synced during a session out of memory?

The blockchain is stored on disk first and foremost.

Your OS might or might not also keep some portion of it in memory as a form of caching, depending on the amount of other memory usage on your computer.

The synced blocks during my sessions have been appearing in memory and grow until my memory is maxed out. These are cleared only when I exit the daemon.

The blockchain itself is being saved to disk, but my ram usage grows with each reported synced block. I am syncing from nothing. My programs hang as the memory becomes maxed out.

Is this a bug?
legendary
Activity: 2968
Merit: 1198
Congratulations and thanks to all who made v0.9 possible!

I downloaded the linux64 binaries today as well as blockchain.raw. I used this to create the blockchain (used my actual path to download.raw):
sudo blockchain_import --input-file /path/to/your/download.raw --verify 0

After that process completed, I ran this command:
sudo ./bitmonerod

...and got this error message:
Code:
Creating the logger system
2016-Jan-02 00:43:04.712691 Initializing cryptonote protocol...
2016-Jan-02 00:43:04.712868 Cryptonote protocol initialized OK
2016-Jan-02 00:43:04.713234 Initializing p2p server...
[1451713384] libunbound[4214:0] info: warning: unsupported algorithm for trust anchor . DS IN
[1451713384] libunbound[4214:0] warning: trust anchor . has no supported algorithms, the anchor is ignored (check if you need to upgrade unbound and openssl)
2016-Jan-02 00:43:04.743525 Set limit-up to 2048 kB/s
2016-Jan-02 00:43:04.743885 Set limit-down to 8192 kB/s
2016-Jan-02 00:43:04.744098 Set limit-up to 2048 kB/s
2016-Jan-02 00:43:04.744425 Set limit-down to 8192 kB/s
2016-Jan-02 00:43:04.745453 Binding on 0.0.0.0:18080
2016-Jan-02 00:43:04.745744 Net service bound to 0.0.0.0:18080
2016-Jan-02 00:43:04.745867 Attempting to add IGD port mapping.
2016-Jan-02 00:43:08.832162 Added IGD port mapping.
2016-Jan-02 00:43:08.832325 P2p server initialized OK
2016-Jan-02 00:43:08.832571 Initializing core rpc server...
2016-Jan-02 00:43:08.832728 Binding on 127.0.0.1:18081
2016-Jan-02 00:43:08.832939 Core rpc server initialized OK on port: 18081
2016-Jan-02 00:43:08.833045 Initializing core...
2016-Jan-02 00:43:08.833459 Loading blockchain from folder /home/mike/.bitmonero/lmdb ...
2016-Jan-02 00:43:08.833574 option: fastest
2016-Jan-02 00:43:08.833667 option: async
2016-Jan-02 00:43:08.833759 option: 1000
2016-Jan-02 00:43:08.834491 LMDB memory map needs resized, doing that now.
2016-Jan-02 00:43:08.834707 LMDB Mapsize increased.  Old: 10215MiB, New: 11239MiB
2016-Jan-02 00:43:08.908128 Error attempting to retrieve a hard fork version from the db
2016-Jan-02 00:43:08.908449 ERROR /DISTRIBUTION-BUILD/src/daemon/daemon.cpp:146 Uncaught exception! Error attempting to retrieve a hard fork version from the db
2016-Jan-02 00:43:08.908585 Deinitializing rpc server...
2016-Jan-02 00:43:08.908876 Deinitializing p2p...
2016-Jan-02 00:43:08.910596 Deinitializing core...
2016-Jan-02 00:43:08.911011 Closing IO Service.
2016-Jan-02 00:43:08.957527 Deinitializing cryptonote_protocol...

Any ideas?  EDIT: All files in the log directory were empty.

Looks like maybe a problem with the import tool. While it is being investigated I suggest you just sync from the network instead. Most people have found that to be fast and efficient.

Also, you shouldn't really need to sudo for the daemon, it should work fine without privileges, though now that you have done it once the permissions on your .bitmonero folder might be messed up. Try renaming it to something else.
legendary
Activity: 2968
Merit: 1198
Is the daemon supposed to pass blocks synced during a session out of memory?

The blockchain is stored on disk first and foremost.

Your OS might or might not also keep some portion of it in memory as a form of caching, depending on the amount of other memory usage on your computer.
jr. member
Activity: 50
Merit: 5
Is the daemon supposed to pass blocks synced during a session out of memory?

Congratulations on the release Smiley
hero member
Activity: 850
Merit: 1000
Congratulations and thanks to all who made v0.9 possible!

I downloaded the linux64 binaries today as well as blockchain.raw. I used this to create the blockchain (used my actual path to download.raw):
sudo blockchain_import --input-file /path/to/your/download.raw --verify 0

After that process completed, I ran this command:
sudo ./bitmonerod

...and got this error message:
Code:
Creating the logger system
2016-Jan-02 00:43:04.712691 Initializing cryptonote protocol...
2016-Jan-02 00:43:04.712868 Cryptonote protocol initialized OK
2016-Jan-02 00:43:04.713234 Initializing p2p server...
[1451713384] libunbound[4214:0] info: warning: unsupported algorithm for trust anchor . DS IN
[1451713384] libunbound[4214:0] warning: trust anchor . has no supported algorithms, the anchor is ignored (check if you need to upgrade unbound and openssl)
2016-Jan-02 00:43:04.743525 Set limit-up to 2048 kB/s
2016-Jan-02 00:43:04.743885 Set limit-down to 8192 kB/s
2016-Jan-02 00:43:04.744098 Set limit-up to 2048 kB/s
2016-Jan-02 00:43:04.744425 Set limit-down to 8192 kB/s
2016-Jan-02 00:43:04.745453 Binding on 0.0.0.0:18080
2016-Jan-02 00:43:04.745744 Net service bound to 0.0.0.0:18080
2016-Jan-02 00:43:04.745867 Attempting to add IGD port mapping.
2016-Jan-02 00:43:08.832162 Added IGD port mapping.
2016-Jan-02 00:43:08.832325 P2p server initialized OK
2016-Jan-02 00:43:08.832571 Initializing core rpc server...
2016-Jan-02 00:43:08.832728 Binding on 127.0.0.1:18081
2016-Jan-02 00:43:08.832939 Core rpc server initialized OK on port: 18081
2016-Jan-02 00:43:08.833045 Initializing core...
2016-Jan-02 00:43:08.833459 Loading blockchain from folder /home/mike/.bitmonero/lmdb ...
2016-Jan-02 00:43:08.833574 option: fastest
2016-Jan-02 00:43:08.833667 option: async
2016-Jan-02 00:43:08.833759 option: 1000
2016-Jan-02 00:43:08.834491 LMDB memory map needs resized, doing that now.
2016-Jan-02 00:43:08.834707 LMDB Mapsize increased.  Old: 10215MiB, New: 11239MiB
2016-Jan-02 00:43:08.908128 Error attempting to retrieve a hard fork version from the db
2016-Jan-02 00:43:08.908449 ERROR /DISTRIBUTION-BUILD/src/daemon/daemon.cpp:146 Uncaught exception! Error attempting to retrieve a hard fork version from the db
2016-Jan-02 00:43:08.908585 Deinitializing rpc server...
2016-Jan-02 00:43:08.908876 Deinitializing p2p...
2016-Jan-02 00:43:08.910596 Deinitializing core...
2016-Jan-02 00:43:08.911011 Closing IO Service.
2016-Jan-02 00:43:08.957527 Deinitializing cryptonote_protocol...

Any ideas?  EDIT: All files in the log directory were empty.
legendary
Activity: 2968
Merit: 1198
Congratulations on the new release!

Minor bug report:

When syncing from scratch the "days behind" is off by a factor of two.  I did not look at the relevant code yet but assume that the proper equation going forward (for 2 minute blocks) was improperly applied to the "days behind" notifications for historical (1 minute) blocks.

Noted here: https://github.com/monero-project/bitmonero/issues/591
legendary
Activity: 3836
Merit: 4969
Doomed to see the future and unable to prevent it
legendary
Activity: 2730
Merit: 1288
Congratulations on the new release!

Minor bug report:

When syncing from scratch the "days behind" is off by a factor of two.  I did not look at the relevant code yet but assume that the proper equation going forward (for 2 minute blocks) was improperly applied to the "days behind" notifications for historical (1 minute) blocks.


lol i was wondering how come there was 1200 days of existence, now it makes sense.
sr. member
Activity: 378
Merit: 250
Congratulations on the new release!

Minor bug report:

When syncing from scratch the "days behind" is off by a factor of two.  I did not look at the relevant code yet but assume that the proper equation going forward (for 2 minute blocks) was improperly applied to the "days behind" notifications for historical (1 minute) blocks.
sr. member
Activity: 336
Merit: 250
Downloaded the new 0.9 release for GNU/LInux. What a difference. Under 60 MB RAM vs over 9.2 GB RAM for the 0.8.8.6 release. A major list of improvements  https://github.com/monero-project/bitmonero/releases and some that were not even mentioned such as including the code for the tail emission.

I upgraded from one of the 0.8.8.7 betas so there was no need to re-sync the db. The wallet did require a re-sync, after copying wallet.bin.address.txt and wallet.bin.keys. Do not copy wallet.bin over it will generate an error.

What a great start to 2016 for Monero. I want to thank the development team for all of their hard work in 2015!
legendary
Activity: 2282
Merit: 1050
Monero Core Team
Downloaded the new 0.9 release for GNU/LInux. What a difference. Under 60 MB RAM vs over 9.2 GB RAM for the 0.8.8.6 release. A major list of improvements  https://github.com/monero-project/bitmonero/releases and some that were not even mentioned such as including the code for the tail emission.

I upgraded from one of the 0.8.8.7 betas so there was no need to re-sync the db. The wallet did require a re-sync, after copying wallet.bin.address.txt and wallet.bin.keys. Do not copy wallet.bin over it will generate an error.
Jump to: