Bitcoin Forum

Hello everyone,

I'm trying to run Bitcoin Core on a tiny Intel Edison board (http://en.wikipedia.org/wiki/Intel_Edison). The plan is to eventually create the smallest physical Bitcoin Node (it's the size of a postage stamp!). The board has a dual core Intel Atom on board with 1 GB of RAM and 4 GB of storage, I'm using an external 32 GB USB drive to store the blockchain.

The thing is that bitcoind appears to crash after about 16 hours - I see no messages as to why in debug.log, I simply leave it running overnight and find it dead. Memory usage (when running normally) is around 350MB.

I've tried to mess with the startup options, like this:

./bitcoind -maxconnections=16 -daemon -disablewallet -datadir=/mnt

but it still crashes after less than 24 hours.

I'm using version 0.9.3, the 32-bit x86 binary.

I could always restart it when it crashes, but it just doesn't seem the right thing to do, I'd rather get to the bottom of this and see why it crashes and how to recover. I understand people have been running bitcoind on machines with less RAM (512MB Raspberry Pi for instance), so I thought 1 GB should be more than enough (if that's the reason for the crash).

Any ideas on how to proceed?

Thank  you,
Razvan

Do you have swap turned on? For the initial sync 1GB may not be enough (eg https://github.com/bitcoin/bitcoin/issues/3324).

So you might try the 64 bit version with swap turned on and see if that helps.

It's not the initial sync, I've copied the blockchain ("blocks" and "chainstate" folders) from an in-sync node and it took a while to start, but now it's synchronized, the crash happens during normal operation, it's not using much processor time, just a ton of memory. I don't have swap enabled, I'm really not very keen on enabling swap to flash - but does it really need swap when it has 1 GB of RAM?? As I said, memory usage is around 350MB (I've restarted it a few hours ago and now it's at 293MB (the VSZ field in "ps -w").

I'm now running it with -debug and sending output to the console, so I should see it when it crashes, previous runs were without -debug.

Also, I can't run the 64-bit version, this is a 32-bit x86 system based on Intel Atom.

You might try limiting the number of connections to see if you can try to see if that is an issue.  I have more than 1GB, so haven't tested it that way.  

And the link was just an example where 32 bit versions were needing more ram. :-)

This is a cool project btw.

Ok, I'm running it now like this


Memory appears to be stable at around 290MB, let's see if it still crashes after 16 hours, I'll leave it running overnight.

Yeah, that should be a good test.  Helping to decrease the number of variables is good.  If it does crash, you might try setting maxconnections to something like 2, just to see what happens.  Buffering could be impacting memory usage on the machine.  It is hard to do much but guess.  ;-)

One thing I am not sure about also is setting dbcache=4.  I think the default is 100MB (vs 4MB), so changing that back to the default might be something to try also.  I haven't seen many people decreasing it from the default.

The dbcache setting is from an IRC discussion - see http://bitcoinstats.com/irc/bitcoin-dev/logs/2014/09/18 . If things work ok with these settings, I'll remove the restrictions one by one and see what happens. I now have 8 incoming and 8 outgoing transactions, memory usage 330MB. Stable so far.

Fingers crossed. If you get it stable then as you say, changing it from there step by step should work.

It ran fine for over 24 hours with the new settings, I'll try to take them out one by one and see if things change.

For the fun of it, I've installed X Windows and Bitcoin QT on the Edison and gave it a try (side by side with a web browser and a terminal) and you can see the result below:

http://www.veri.fi/edisonvnc.png

So we basically have Bitcoin QT (a full visual Bitcoin node, with full verification!!) running on something the size of a postage stamp.

Nice!

Glad it seems stable so far.

i thought the Intel Edison used 2 Atom Silvermont cores, which Slivermount is x86-64 based.. so why couldn’t you use x64 on it? or was it the Quark MCU that stopped you?

Well, according to https://communities.intel.com/thread/57334?start=0&tstart=0 it's not very clear if it's a 64-bit processor or a 32-bit one (their reference kernel is 32-bit and nobody's been able to make it work in 64-bit mode so far - see the thread above).

How is it running now. I want to do the same with mine after I take the dust off. Can you list the setup steps with the first step is selecting the OS.
I want to use ubilinux.