Linux mining distro for the Raspberry PI - MinePeon

[MineForeman.com]

That's just weird!  Especially since you are having the same problem with the default build and mine.

I would be very interested if you find out what it is, it is not like we don't know it works with other Raspberry PI's on other networks (with MinePeon or raspian).

It never ceases to amaze me the issues that come up in testing, perhaps it is your DHCP server?

Anyway, I will post instructions on how to do a manual assignment in a bit.  Thanks for helping out with testing.

[1715107590]

1715107590

[1715107590]

1715107590

[1715107590]

1715107590

[HolyScott]

Been running minepeon for about a week with no problems, only reboots are ones I have done myself. How close are we to a new version update? I see new versions of cgminer and bfgminer have just been released and would like the new versions. Also have you thought about including bitcoind, namecoind, and maybe the p2pool script at all? blockchain would require expanding the card up to 16 gb or so. I still haven't expanded my card from within arch linux, as I am waiting for next update before I do heavy customizing. Thanks alot.

[MineForeman.com]

Thanks alot.

Your very welcome.

Next update should be some time this weekend, there are just a few things that I want to lock down (graphing, updating preserving configuration without re downloading and imaging, backup pools and BFGMiner support mainly).

An option for p2pool & bitcoind (with automatic partition sizing) will come as soon as I get the live update working right, at the moment updating is done by downloading the entire image so you would have to re-sync the blockchain every time.  Once the update system is working correctly all you should have to do is hit a button on the web interface.

I am concerned about the amount of IO thrashing that will come with the blockchain and it may just turn out to be a good way to toast SD cards, but that is what testing is for  .

[serp]

Well the dhcp all seemed to start working last night.  I have no idea what was going on.  At this point I assume something was funky on my end.  Sorry for the trouble.

On a tangent point, it looks like in Arch that drivers need to be downloaded/compiled to get the commonly used (for rpi) Edimax wireless adapter working.  What would be the odds of getting that included in a future release?   Here's a link to the process http://archlinuxarm.org/forum/viewtopic.php?f=6&t=1129&hilit=edimax&sid=56a38bc88efd3a15275a1d6d29742ecf

[MineForeman.com]

Yeah, weird stuff going on with your DHCP   .

The module for that adapter is actually already present in the Kernel, I am not sure when it got included in the standard Arch Kernel but it is there, you can load it with "modprobe 8192cu".

However, I have not included anything to configure wireless adaptors, it adds a layer of complexity to the setup that I was trying to avoid (SSID, encryption keys etc..).  I will pop down to the local shop and pick up a wireless adaptor and at least include and test the tools to get it going from the console.

Morblias was kind enough to donate 1 BTC earlier (thanks Morblias), I might see if I can get a few different sorts.

[serp]

I just donated a coin too for all the work you've put into this.  If this leads to stable ASIC mining off an rpi then it'll be worth more than that.

For the wireless, I did the modprobe then installed wireless_tools and wicd.  I attempted to use the wicd-curses but something broke on that so I'm possibly missing some other package there.  I'll look up using wicd-cli.

[MineForeman.com]

Thanks for the coin!  It is nice to be appreciated.

wicd-curses can be easily dropped in to configure networks by;-

pacman -Syu
pacman -S wicd

You will then need to reboot though (dbus needs to be restarted more exactly, but a full reboot will do too).

I am off to the shops now to get some interfaces, it works for wired, but I have not tested wireless.  If it works out I will include it in the next build for you.

[serp]

Got wireless up.. it's not too bad.  I had not started the wicd service is why I could not get wicd-curses to work.

Just a brief setup steps for the Edimax adapter.

modprobe 8192cu
pacman -S wireless_tools (unsure if needed?)
pacman -S wicd
reboot
ifconfig wlan0
systemctl start wicd
systemctl enable wicd.service
wicd-curses

At this point it's just a text-based gui to set up your wireless that is pretty dummy proof.

The current caveat is that you'll need a wired connection to install the extra packages now.  Might be possible to just have  it where the user just needs to type wicd-curses on first boot to set it up.  That'd require it start off wired or to have a keyboard/screen but I don't see a way around that for wireless.

[MineForeman.com]

Glad its going, I have also gone through the same steps as you and now I have wireless with a few adaptors that I picked up thanks to you guys  .

I will definitely be including the wicd packages in the next build as per your recommendation.  Like you say though, it is going to be imposable to set it up without a wired connection or a keyboard/screen combination but it is at least possible now.

Thanks for your help and contributions, testing and efforts like you have done is what makes Open Source stuff so good.

[BenTuras]

No, 40% hardware errors means you need to sort that out quickly
i.e. you are only getting 60% of your maximum work possible (losing 40% of it) way too high.

Your WU stat show that you are mining at 348Mh/s, but 40% of that is hardware errors and the U stat and MH/s shows exactly that.

However ... if 207MH/s is really what you are expecting from your device then something else is going wrong

207MH/s is about what can be expected from a Ztex board, according to http://www.ztex.de/btcminer/ it should average to 215 MH/s (typical).

PS. I don't get the 348MH/s you mention, what is WU (work unit?) and U (user?) stats ?
Can you please explain a bit more ?

Thanks!

[BenTuras]

I will let it run for a few days again and report again.

Thanks, your Ztex 1.15x should optimality running at about 215 MH/s, and at 207.45 MH/s your actually not that far from it.  I am not sure what those hardware errors are (if you could look to see if you could find more detail in the logs it would help) but it does not seem to be impacting on your hash rate all that dramatically (certainly not 66%), without having one in front of me it is hard to tell what the HW Error is, it is entirely passable it is just an intermittent fault that is recovered without impact (but still recorded as a fault).

The real proof will be at the pool and if you are still maintaining your expected hash rate.

However ... if 207MH/s is really what you are expecting from your device then something else is going wrong

Agreed.

I have checked the various logs in /var/log and the journalctl log. The only mention of ztex is the usual usb message:

Code:

[root@minepeon var]# find . -type f -exec grep -i ztex /dev/null {} \;
Binary file ./cache/man/index.db matches
./log/kernel.log.1:Jan 31 18:58:10 minepeon kernel: [   30.873030] usb 1-1.3.2: Product: btcminer for ZTEX FPGA Modules
./log/kernel.log.1:Jan 31 18:58:10 minepeon kernel: [   30.873047] usb 1-1.3.2: Manufacturer: ZTEX
./log/kernel.log.1:Jan  1 01:00:07 minepeon kernel: [    3.122728] usb 1-1.3.2: Product: btcminer for ZTEX FPGA Modules
./log/kernel.log.1:Jan  1 01:00:07 minepeon kernel: [    3.122744] usb 1-1.3.2: Manufacturer: ZTEX

and

Code:

[root@minepeon var]# journalctl|grep -i ztex
Jan 01 01:00:03 minepeon kernel: usb 1-1.3.2: Product: btcminer for ZTEX FPGA Modules
Jan 01 01:00:03 minepeon kernel: usb 1-1.3.2: Manufacturer: ZTEX

miner.php:
               

Code:

Date: 09:03:28 9-Feb-2013 UTC+00:00
Rig	STATUS	Description	When	API	CGMiner
	S	cgminer 2.10.4	09:03:28 9-Feb-2013 UTC+00:00	1.23	2.10.4
 
Rig	Elapsed	MHS av	Blks	Accepted	Rej	Utility	HW Errs	Net Blks	Work Utility
	4days 15h 37m 50s	207.89	0	19,316	12	2.88/m	11871	714	4.66/m
Σ	 	207.89	0	19,316	12	2.88/m	11871	 	4.66/m
 
Rig	 	Hash Method	Current Block Time	Current Block Hash	LP
	COIN	sha256	09:02:50 9-Feb-2013 UTC+00:00	00000000000001a468790e8f7025ac221b939cabd8d3bc434e8f768572ef140a	false
 
Rig	STATS	ID	Elapsed	Calls	Wait	Max	Min	Pool Calls	Pool Attempts	Pool Wait	Pool Max	Pool Min	Pool Av	Work Had Roll Time	Work Can Roll	Work Had Expire	Work Roll Time	Work Diff	Min Diff	Max Diff	Min Diff Count	Max Diff Count	Times Sent	Bytes Sent	Times Recv	Bytes Recv
	0	ZTX0	4days 15h 37m 50s	19886	68.883706	4.848618	0.000050	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 
	1	POOL0	4days 15h 37m 50s	19886	68.883706	4.848618	0.000050	0	0	0.000000	0.000000	99999999.000000	0.000000	false	false	false	0	1.00000000	1.00000000	1.00000000	48427	48427	19,342	2,307,777	33,894	15,376,129

And BtcGuild:

Code:

Worker Name	Speed	Shares	Last
Share	Reset
Stats
Accepted (%)	Stale/Dupe/Other
bensguild_raspberry	226.16 MH/s	35368 (99.88%)	42 / 0 / 0	0:00:15	

Sorry for the lousy formatting, copying webpages into here doesn't give a very readable result.

Any other log I can check ?

And also thank you !

[BenTuras]

... Well if it's a ztex then the latest code (from denisx) does the out of bounds work checking properly also.

Maybe the problem is the firmware/bitstream needs updating in the ztex and most of the errors actually don't exist but the code is testing it anyway?

Kano, I have tried to locate the latest code from denisx, but couln't find it on ztex.de, google or on here. Can you please point me into the right direction ?

I updated the ztex firmware to the latest available on ztex.de last weekend after having issues that the board was not recognized, see earlier in this thread.

[kano]

... Well if it's a ztex then the latest code (from denisx) does the out of bounds work checking properly also.

Maybe the problem is the firmware/bitstream needs updating in the ztex and most of the errors actually don't exist but the code is testing it anyway?

Kano, I have tried to locate the latest code from denisx, but couln't find it on ztex.de, google or on here. Can you please point me into the right direction ?

I updated the ztex firmware to the latest available on ztex.de last weekend after having issues that the board was not recognized, see earlier in this thread.

I'm referring to the code in cgminer.
He's the one who has been supporting the cgminer ztex code coz he has ztexes.
He's made a lot of changes in there.
One was (if my memory is correct) to do with checking the finish work value (it's not a valid share - but is a valid hash)
If for some reason your firmware of bitstream doesn't return that extra information, then that sounds like a cause for extra HW errors.
(Maybe the code doesn't know when to not expect the extra hashes?)

My assumption is that: if your ztex is hashing at approximately the right rate but also getting 40% HW errors, then that 40% extra MUST be extra values - thus why I guess that is to do with his ztex changes in cgminer.

However, I don't know the details coz I've stayed away from the ztex code (coz I don't have a ztex)

[kano]

... and just somewhat of an FYI ... but relevant I believe.
I've been using the stock standard 2012-12-16-wheezy-raspbian for a few days now.
I've done a few manual restarts early on, while messing with setting it up - but cgminer current run time is 54 hours.
I've had no obvious USB lockups, but a few comm errors and a lot of throttling due to the BFL FPGA getting too hot (here in summer)
So I do consider that a useful environment for USB testing, not a simple, everything is fine, so nothing unusual is happening.

I had one cgminer crash inside libusb at the start when experimenting with my hotplug code, but other than that, had no problems at all.
My interest with this release was to resolve the often reported USB errors when I got the rpi (again thanks indeed to MineForeman.com!) but it seems that raspbian might have actually fixed it themselves?
I've only run a single BFL FPGA on it, but I'll move it down to the garage today (soon) next to my rig and put 2 of my 4 FPGAs into it (1xBFL + 1xMMQ) and see how that goes.
But of course once I finally get an ASIC device, and thus be hitting the USB up to 50x harder, and the possible contention that might also cause, I'll see if there are still problems, or if a custom kernel is indeed mandatory to resolve that.

[HolyScott]

I only ever get / got comm errors with more the 1 BFL Single hooked up. On Raspian, doing a patch rpi-update got rid of comm errors once your past january 2013 firmwares. It seems that minepeon's arch linux also has whichever firmware fixes as I have never seen a comm error in over 2 weeks of 24 / 7 testing. I was asked previously, closing, and restarting cgminer / bfgminer would fix the comm error, but I would reboot just to be safe. Usually they would show up in 4-8 hours if they where gonna happen at all. But again, only with more then 1 Single.

[MineForeman.com]

Update: MinePeon-2013-02-17.img

Very few changes have taken place this time, I am working towards a fully stable version with all of the features required.  The main additions that you will find are;-

wicd-curses: Nice curses UI to configure Wireless and Wired Networks from the console.

rrdtools: Hourly/Daily/Weekly/Monthly/Yearly Graphs on the default web page that update every 5 minutes.

bfgminer: I know there are a lot of bfgminer users out there and because they both work in the same way it is possible to support both.  In order to change to bfgminer you need to login via the console or ssh and issue the following commands (I will make this easier later);-

systemctl stop cgminer.service (Stops cgminer)
systemctl disable cgminer.service (Stops cgminer from starting at boot)
systemctl enable bfgminer.service (Makes bfgminer start at boot)
systemctl start bfgminer.service (Starts bfgminer)

There has also been quite a few upstream updates from Arch Linux and a kernel and firmware update from Raspberry.  Both cgminer and bfgminer are also the latest from git.

On other matters I have also put the default Rasberian Linux through quite a few tests and I feel quite confident that it has also overcome the USB issues.

No live update yet sorry, there is just too much going on between releases, I will have a way of saving and restoring your configuration for the next release though

Once again, thanks to everyone for testing and your contributions, there are a few more things that I want to test and stabilise but I am fairly confident that we will have a stable product by the time we need it.

[Morblias]

Those graphs are amazing! Thank you 

[Vernon715]

The Rpi is awesome

[MineForeman.com]

The Rpi is awesome

It is indeed  .

I need your guys help again, I am compiling a list of things that I want to do for the next release, my main focus is going to be on security so I am adding to the list myself;-

HTTPS for the WebUI
Username/Password for the WebUI
Move all non root functions off root

A few other things that I have been working on and need to include are;-

Timezone support
tmux, htop, and nload
Bfgminer switch from the WebUI
Up to 4 pools for backup purposes.

Once I have done all of this and it has been tested I want to take it out of Alpha and put into Beta in perpetration for ASIC's.  Before I do it though I have to ask (cos you guys are the users) is there anything else that you want to creep into the first beta build?

[HolyScott]

I may have spoken a little to soon, on the previous jan 30th build, I did have 1 BFL single go offline with the dreaded comm error, after 11 days, which to be honest is the longer I have ever had the RPi go without a reboot, usually new builds / firmwares / miner updates have me rebooting a few times a week. It MAY have been my fault it I bumped a cable in my dusting of my singles I do every few days. But to me, 1 falling offline in 11 days is NOT bad compared to 4-8 hours or 2-3 days.

New build.

 Love the charts, love bfgminer, easy to stop and switch over the services. I did have one minor problem. I edited the cgminer.conf to add my backup pools, and upon a reboot it switched back to your test pool (your welcome). I copied the file over miner.conf and had the same settings in both files, and that seemed to fix that problem. So you might want to clear up which file you need to edit for pools / backup pools tweaked config settings. Does both cgminer and bfgminer use the same settings file? So far been up 24 hours with no problems.

New features.

 I know you are aware that I would like to see; tmux, nload, htop, which are tiny disk size wise. For nload to work you need to " export HOME=/root " for it to work until you add a different user as log in. You other changes your are working on sound on the right track, being able to confire all basic, intermediate settings from the webui. I would like to see passwords on the webpage, that would be the same as the user password to log into the unit. Maybe change the webpage port off :80 just to hide it a little bit, even myip:8000 / 8080 would help be a tad more discrete. More advanced ideas, bamter.org usb gpu miner would search your network for other instances and show all graphs from all units together, is that a possibility. Even more advanced ideas, a command / gui option to click and it would expand HD use to fill the full SD card, so it would auto size the 4gb card image to the full 16gb card size you are using, raspian has a one click option to do this in the raspi-config. Also, one click overclock settings also following the raspian raspi-config? still possible is arch linux?  Great build, will keep testing for you untill the next update. Just trying to think of any other ideas for a perfect world / build / distro. Hope this helps.