Greetings.
Did you tried minepeon? I have it running in 3 Raspberry Pi's and they are stable for many days, 24/7.
Site: http://minepeon.com/index.php/Main_Page
Best regards.
Topic: Bitcoin with Raspberry Pi - page 3. (Read 17780 times)
There is no free hosting for these afaik, and the linux on RPi is stable because the community is huge.
And as I said, I now run the bitcoind on another server, so I already solved this problem.
I will use battery backup and RUT-500 redundant 3G to handle fiber/power failures for uptime at home.
And as I said, I now run the bitcoind on another server, so I already solved this problem.
I will use battery backup and RUT-500 redundant 3G to handle fiber/power failures for uptime at home.
Ok, but what about RAM memory running out? How do you "fix" that, reboot every 12 hours?
Don't try and run such software on shitty little cutter CPU's, go HERE:
http://www.hardkernel.com/renewal_2011/main.php
Get a U2.... 4 CPU & 2GB FAST memory, I've had one on line since Jan......7/24
More importantly the 10/100 & the 'other' USB ports are split out onto SEPARATE USB channels back to the chip, so... no bottle neck.
But as with ANY small Flash card based system you really need to watch your write caches.
Only had one issue , where I shorted the power and had to pull the SDcard to FSchk it on a 'real' computer. (two if you count the PSU of the shitty china telicom ADSL blowing up..)
Just wish they were a bit cheaper...... but they ARE worth the money.....
Really am happy with my purchase.
You can't go professional running anything on a Raspberry Pi. It's not designed as a professional piece of equipment.
I'm building a PaaS on a cluster of RPi's, so I obviously think you are wrong here.
I'm going to modify one of these, I mean why risk it?
Yeah, but you can't run anything professional with a bitcoind that is restarted every hour.
I think the bitcoin community really needs to move out of the garage; if we're ever going to get this thing going.
You can't go professional running anything on a Raspberry Pi. It's not designed as a professional piece of equipment. Especially something as memory/storage intensive as bitcoin.I think the bitcoin community really needs to move out of the garage; if we're ever going to get this thing going.
Ps. you should probably look at http://binerry.de/post/28263824530/raspberry-pi-watchdog-timer for making sure you can deal with your Pi locking up (never happened to me, but I don't push mine very hard) if you are using it for something important.
Quote
Hm, interesting! I just feel a bit uneasy about feeding the routers "own" power back into it.
Feels like it might work fine until there is a spike in the grid and then: poof your hub is toast, and if you're unlucky your house burns down with it...
Do you know what the USB spec. says about this?
Edit: Please see this quote from a user on the raspberry forum:
http://raspberrypi.stackexchange.com/questions/4880/powered-hubs-backfeeding-and-safety has some more useful info. But basically unless you've cheaped out on an unregulated USB hub you won't cause damage, and in most cases things will just work without problems. Neither of my PIs has failed yet, the one which I have always-on hasn't crashed once. (48 days uptime ATM, i.e. since the last time I was rearranging cabling and had to unplug it.) If you're really interested I reccomend looking at some USB hub circuits online...Feels like it might work fine until there is a spike in the grid and then: poof your hub is toast, and if you're unlucky your house burns down with it...
Do you know what the USB spec. says about this?
Edit: Please see this quote from a user on the raspberry forum:
Quote
If you leave the red wire intact, (and are thus "back-feeding" the PI, as its commonly called) you are in fact bypassing the PI's F3 polyfuse.
There is one single case I am aware of where this caused trouble when that user also used a badly designed power supply to feed the hub. The power supply wasn't properly regulated, and unloaded it outputted more than six volt! When he plugged it in it triggered the over-voltage protection diode of the PI (which triggers at about six volt) the resulting short circuit current though the diode, unimpeded by any fuse, overheated the diode so much that it melted a hole in the enclosure of his PI!
Its thus much better to "cut the red wire", and not to back-feed the PI!
There is one single case I am aware of where this caused trouble when that user also used a badly designed power supply to feed the hub. The power supply wasn't properly regulated, and unloaded it outputted more than six volt! When he plugged it in it triggered the over-voltage protection diode of the PI (which triggers at about six volt) the resulting short circuit current though the diode, unimpeded by any fuse, overheated the diode so much that it melted a hole in the enclosure of his PI!
Its thus much better to "cut the red wire", and not to back-feed the PI!
// Edit: and for some more detail look at http://www.raspberrypi.org/phpBB3/viewtopic.php?f=26&t=17560
I had bitcoind 0.8.1 running on a Raspberry Pi and performance was terrible.....very high CPU usage and too many r/w operations.
Jeff Garzik, one of the core bitcoin developers, is writing a lightweight C library called libccoin and a client called picocoin.
When finished this should be suitable for running on low powered devices like a Raspberry Pi.
Although I am concerned about running any client that will store the entire blockchain on an SDCard as it would significantly reduce the cards lifespan.
Jeff Garzik, one of the core bitcoin developers, is writing a lightweight C library called libccoin and a client called picocoin.
When finished this should be suitable for running on low powered devices like a Raspberry Pi.
Although I am concerned about running any client that will store the entire blockchain on an SDCard as it would significantly reduce the cards lifespan.
Yeah, but you can't run anything professional with a bitcoind that is restarted every hour.
I think the bitcoin community really needs to move out of the garage; if we're ever going to get this thing going.
I think the bitcoin community really needs to move out of the garage; if we're ever going to get this thing going.
Just make it restart every hour, or put it in the loop so it will start up right after the crash. I have solved my electrum server stability issues with that and I was never woken up by alert from monitoring again. 
No I meant with bitcoind, it runs out of memory after 4-5 hours... no matter what you do.
I got a pi up and running as a bitcoind node just to try it out once, and it was working with the old leveldb and only 256 MB memory.
Ok, but I need it to run 24/7 stable...
That shouldn't be necessary -- both my RPIs are powered from the hub they control without any issues so far. (Although that might depend on the hub...) I've never heard of anyone having to cut wires for this sort of thing to work.
Hm, interesting! I just feel a bit uneasy about feeding the routers "own" power back into it.
Feels like it might work fine until there is a spike in the grid and then: poof your hub/pi is toast, and if you're unlucky your house burns down with it...
Do you know what the USB spec. says about this?
Edit: Please see this quote from a moderator on the raspberry forum:
Quote
If you leave the red wire intact, (and are thus "back-feeding" the PI, as its commonly called) you are in fact bypassing the PI's F3 polyfuse.
There is one single case I am aware of where this caused trouble when that user also used a badly designed power supply to feed the hub. The power supply wasn't properly regulated, and unloaded it outputted more than six volt! When he plugged it in it triggered the over-voltage protection diode of the PI (which triggers at about six volt) the resulting short circuit current though the diode, unimpeded by any fuse, overheated the diode so much that it melted a hole in the enclosure of his PI!
Its thus much better to "cut the red wire", and not to back-feed the PI!
There is one single case I am aware of where this caused trouble when that user also used a badly designed power supply to feed the hub. The power supply wasn't properly regulated, and unloaded it outputted more than six volt! When he plugged it in it triggered the over-voltage protection diode of the PI (which triggers at about six volt) the resulting short circuit current though the diode, unimpeded by any fuse, overheated the diode so much that it melted a hole in the enclosure of his PI!
Its thus much better to "cut the red wire", and not to back-feed the PI!
No I meant with bitcoind, it runs out of memory after 4-5 hours... no matter what you do.
I got a pi up and running as a bitcoind node just to try it out once, and it was working with the old leveldb and only 256 MB memory.
I bootstrapped the blockchain:
-loadblock=
from
http://eu2.bitcoincharts.com/blockchain/
and set
-checkblocks=
-checklevel=
to smaller numbers (don't remember what, specifically)
FYI: If you wan't to recursively both power the RPi with the hub and control the hub with your RPi at the same time just cut the red wire in the uplink cable.
For my part o = 1xBE USB and 2x50GH BFL, I hope the RPi will be able to run them!
That shouldn't be necessary -- both my RPIs are powered from the hub they control without any issues so far. (Although that might depend on the hub...) I've never heard of anyone having to cut wires for this sort of thing to work. Code:
-P +-------+
| | |
| c |
| | |
+-------+ |
| hub | | < SOLUTION: Cut the red wire here!
+-------+ |
| | | | |
p o o o |
| |
| +-----+ |
+-| RPi |-+
+-----+
o = other "power hungry" devices
P = PSU power
p = USB power
c = hub controller
For my part o = 1xBE USB and 2x50GH BFL, I hope the RPi will be able to run them!
FYI: If you wan't to recursively both power the RPi with the hub and control the hub with your RPi at the same time just cut the red wire in the uplink cable.
For my part o = 1xBE USB and 2x50GH BFL, I hope the RPi will be able to run them!
Code:
-P +-------+
| | |
| c |
| | |
+-------+ |
| hub | | < SOLUTION: Cut the red wire here!
+-------+ |
| | | | |
p o o o |
| |
| +-----+ |
+-| RPi |-+
+-----+
o = other "power hungry" devices
P = PSU power
p = USB power
c = hub controller
For my part o = 1xBE USB and 2x50GH BFL, I hope the RPi will be able to run them!
No I meant with bitcoind, it runs out of memory after 4-5 hours... no matter what you do.
Ok, but what about RAM memory running out?
I have removed all unnecessary packages (e.g. ALL graphical stuff as my pi is headless). Although I have added a few others like tor and clamav.
I have one of the newer 512MB pi's. Shortly after a reboot it has about 68MB free memory.
KiB Mem: 448776 total, 378504 used, 70272 free, 28172 buffers
KiB Swap: 102396 total, 0 used, 102396 free, 264292 cached
This reduces over time and settles between 10MB and 20MB free. Analysis of memory management is a bit of a black art.
I currently have 64MB allocated to GPU. Given my headless setup this is excessive and I can reduce it if necessary making more memory available to CPU.
Ok, but what about RAM memory running out? How do you "fix" that, reboot every 12 hours?
Howto compile bitcoind on raspberry pi:
> sudo apt-get install libboost1.50-dev libboost-filesystem1.50-dev libboost-system1.50-dev libboost-program-options1.50-dev libboost-thread1.50-dev libcurl4-openssl-dev libdb5.3++-dev libminiupnpc-dev
> wget https://github.com/bitcoin/bitcoin/archive/master.zip
> unzip master.zip
> cd bitcoin-master/src
> make -f makefile.unix bitcoind
Compilation takes about 1 hour, downloading the blockchain about 20 hours and the bitcoind executable is 43MB!
> sudo apt-get install libboost1.50-dev libboost-filesystem1.50-dev libboost-system1.50-dev libboost-program-options1.50-dev libboost-thread1.50-dev libcurl4-openssl-dev libdb5.3++-dev libminiupnpc-dev
> wget https://github.com/bitcoin/bitcoin/archive/master.zip
> unzip master.zip
> cd bitcoin-master/src
> make -f makefile.unix bitcoind
Compilation takes about 1 hour, downloading the blockchain about 20 hours and the bitcoind executable is 43MB!
The strip command may help reduce the size of the bitcoind executable.
Here's my procedure for building bitcoind on a Raspberry pi:
- wget -O - http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.1/bitcoin-0.8.1-linux.tar.gz/download | zcat - | tar xvf -
- cd bitcoin-0.8.1-linux/src/src
- make -f makefile.unix USE_UPNP= USE_IPV6=1
- strip bitcoind
Code:
root@pi:/var/tmp/bitcoin-0.8.1-linux/src/src# ls -lh bitcoind
-rwxr-xr-x 1 root root 42M May 8 23:19 bitcoind
root@pi:/var/tmp/bitcoin-0.8.1-linux/src/src# strip bitcoind
root@pi:/var/tmp/bitcoin-0.8.1-linux/src/src# ls -lh bitcoind
-rwxr-xr-x 1 root root 2.5M May 8 23:38 bitcoind
You can see that the strip command reduced the binary from 42MB to 2.5MB
Also to reduce SD card wear I use the -printtoconsole option to stop constant writing to the debug.log file.
I may also link some of the other log files to /dev/null
Just FYI, since picocoin is not ready for prime time (and I think most projects will never be ready for prime time except the satoshi client; because nobody, and I mean NOBODY, wants to be responsible of erasing real money)...
This is insane though, individuals will probably never run this thing... I mean 10GB and lots of CPU/memory...
This is insane though, individuals will probably never run this thing... I mean 10GB and lots of CPU/memory...
Try archlinux on RPi, but AFAIK don't expect spectacular hashrates.
I'm just adding tutorials on how to build stuff for the RPi here:
Here's BFGMiner for ASICMiner/BFL:
> sudo apt-get install autoconf libtool libncurses-dev yasm curl libcurl4-openssl-dev pkg-config git libjansson-dev uthash-dev libevent-dev
> git clone git://github.com/luke-jr/bfgminer.git bfgminer
> cd bfgminer
> ./autogen.sh
> ./configure
> make
> ./bfgminer -o stratum+tcp://stratum.bitcoin.cz:3333 -O user:pass -S icarus:/dev/ttyUSB0
I'm going to try and run both my SC 60GH on one RPi, will be interesting to see if it works!
Here's BFGMiner for ASICMiner/BFL:
> sudo apt-get install autoconf libtool libncurses-dev yasm curl libcurl4-openssl-dev pkg-config git libjansson-dev uthash-dev libevent-dev
> git clone git://github.com/luke-jr/bfgminer.git bfgminer
> cd bfgminer
> ./autogen.sh
> ./configure
> make
> ./bfgminer -o stratum+tcp://stratum.bitcoin.cz:3333 -O user:pass -S icarus:/dev/ttyUSB0
I'm going to try and run both my SC 60GH on one RPi, will be interesting to see if it works!
Jump to: