Linux mining distro for the Raspberry PI - MinePeon

[BenTuras]

It's starting to work. I fiddled with the board connected to a windows PC. Updated the Ztex firmware (it was indeed old) and without switching it off connected it to the Raspi.

 cgminer version 2.10.4 - Started: [2013-01-31 20:56:50]
--------------------------------------------------------------------------------
 (5s):473.1M (avg):200.2Mh/s | Q:7  A:8  R:0  HW:1  E:114%  U:2.7/m
 ST: 2  SS: 0  DW: 12  NB: 2  LW: 27  GF: 0  RF: 0  WU: 3.0
 Connected to 50.31.149.57 diff 1 with stratum as user bensguild_raspberry
 Block: 04ebfa5299bc5b8d...  Diff:2.97M  Started: [20:57:26]  Best share: 7
--------------------------------------------------------------------------------
 [P]ool management [ S ]ettings [D]isplay options [Q]uit
 ZTX 0: 04A346C253-1 | 208.0MHz | 194.9M/200.2Mh/s | A:8 R:0 HW:1 U:2.66/m
--------------------------------------------------------------------------------

 [2013-01-31 20:56:47] ZTEX 04A346C253-1: capability missing: 0 7
 [2013-01-31 20:56:47] ZTEX 04A346C253-1: Found Ztex (fpga count = 1) , mark as
0
 [2013-01-31 20:56:47] Probing for an alive pool
 [2013-01-31 20:56:50] Switching pool 0 http://btcguild.com:8332 to stratum+tcp:
//50.31.149.57:3333
 [2013-01-31 20:56:54] ZTEX 04A346C253-1: Frequency set to 200.0 MHz
 [2013-01-31 20:56:58] Accepted aa113f67 Diff 1/1 ZTX 0
 [2013-01-31 20:56:58] Stratum from pool 0 requested work restart
 [2013-01-31 20:56:59] API running in IP access mode on port 4028
 [2013-01-31 20:57:06] Accepted 3c583a1c Diff 4/1 ZTX 0
 [2013-01-31 20:57:26] Stratum from pool 0 detected new block
 [2013-01-31 20:57:41] Accepted d31c8be8 Diff 1/1 ZTX 0
 [2013-01-31 20:57:57] Accepted 57d37c0c Diff 2/1 ZTX 0
 [2013-01-31 20:58:09] ZTEX 04A346C253-1: Frequency change from 200.0 to 204.0 MHz
 [2013-01-31 20:58:18] Accepted df48cf46 Diff 1/1 ZTX 0
 [2013-01-31 20:59:19] Accepted 22be4434 Diff 7/1 ZTX 0
 [2013-01-31 20:59:32] ZTEX 04A346C253-1: Frequency change from 204.0 to 208.0 MHz
 [2013-01-31 20:59:44] ZTX0: invalid nonce - HW error
 [2013-01-31 20:59:44] Accepted a49ee248 Diff 1/1 ZTX 0

Nice

[MineForeman.com]

Excellent!  I was indeed talking about the ZTEX firmware when I asked if you had upgraded.

It is fairly obvious in the code where the error is generated, Line 170 of libztex.c in libztex_checkDevice.  It basically means that the device has been recognised, the identifier has been read from libusb successfully but when it goes to compare the device identifier  with a list of known devices it does not match.

I am still unsure as to why you got the error though, but that is down to my lack of knowledge of ZTEX devices more than anything else and it is very hard to debug hardware that I down have sitting in front of me.

Using your 'hotplug' trick seems to work though, can I ask if it is still mining at 200.2Mh/s?

[HolyScott]

I am gonna try this when I get home from work this afternoon, I already have the image on a sd card, but I ran out of time this morning. I am running a 512MB RPi with a powered 12 port Satechi hub and 4x BFL Singles. I am currently running the modified wheezy build with cgminer miner and watchdog from here in the forums. I finally got all USB Comm errors solved after multiple rpi-update firmwares, fixed about the beginning of January. I am interested to see if this fixes comm error time outs due to USB that happen from 4 hours - 24 hours. I would like to see the option of CGminer, or BFGminer as I switch between the 2 often. Also, any plans for watchdog support / auto reboots on lockups? I will give feedback once I run for a few hours after I get home from work. Looks to be a great new project. Hopefully you stick with it for awhile.

[HolyScott]

I've have it up and working for a whole 15 minutes want to give some quick initial thoughts.

I would like to see installed on default distro, tmux in additional to screen, bfgminer, htop, and nload. nload does not work cause there is no home directory, which brings me to should everything be running of the root account? which would also need sudo if you do change to a different user. I was shocked at how low memory and cpu usage is. Looking to be a very optimized mining distro.

[MineForeman.com]

I am interested to see if this fixes comm error time outs due to USB that happen from 4 hours - 24 hours.

I am interested in this too, I have a few questions about it as well;-

1. How do your resolve the errors?  Do you have too reboot, cold reboot or what?

2. Can you give me a log example?  Worst come to worst I can monitor the logs for the error and do something.

I would like to see the option of CGminer, or BFGminer as I switch between the 2 often.

BFGMiner is in the plans, I am working ways for the user to switch between the two from the WebUI keeping configuration, stats etc in place.  Its not hard, just time consuming.

Also, any plans for watchdog support / auto reboots on lockups?

Watchdog has been installed and configured since the beginning (I hope we don't need it).

Hopefully you stick with it for awhile.

I run a mining co-op (link in the footer) and while it is not a full time job (yet) I have a stack of client's ASIC devices on the way in the next few months to replace their GPU stuff.  My original plan was to run the new ASIC's off normal PC's running my own linux build but after receiving my Raspberry PI I was very impressed.

So I decided to port to the RasPI, put a shiny WebUI on it and release it for all to use.  

My cunning plan is to become 100% bitcoin funded and supported (a lot of time and effort goes into projects like this).  I have a donation address to support MinePeon so if you want to make sure I stick with it, help out with the development costs   .

[MineForeman.com]

I would like to see installed on default distro

Not going to happen sorry, I would not be able to get anywhere near the amount of optimisation, it is Arch Linux though (upstream compatible).

bfgminer

100% agree.

tmux, htop, and nload.

They wont cause any issues (apart from a small about of space) but they are a bit out of scope for a mining device.  I am not saying no, just I have not thought that people will be sitting at the console all that much (or ssh).  The plan is to make everything available via the WebUI.  I don't plan on adding local users by default for the same reason.

should everything be running of the root account?

Nope, I need to move the miner to its own user, I just have not tested that yet.  Apart from that all daemons already run under their own user (where applicable).

I was shocked at how low memory and cpu usage is. Looking to be a very optimized mining distro.

Thanks, that sums up the goals of MinePeon exactly!

[kano]

Well ... be worth trying it with a BFL or MMQ and my latest cgminer hotplug
It seems that the step to libusb has reduced the CPU usage also ... feel free to compare and report

... you could also add php and miner.php (that is included with cgminer)
miner.php gives a (customisable) reporting and manipulating interface to cgminer with optional password protection with 3 user levels.
See API-README
I work on and update miner.php regularly (coz I also use it)

[MineForeman.com]

Well ... be worth trying it with a BFL or MMQ and my latest cgminer hotplug

It is certainly going to be great having you as a tester (and contributor), I do systems, and while I don't shy away from a compiler or writing code, I am in no way hardcore enough to get into the nitty and gritty bits to work on miners like you do (prolonged coding leads to insanity in my case).

... you could also add php and miner.php

Already done, php is my first choice in web scripting languages, it resembles C enough that I can write 10 lines without having to go to google.  Miner.php is also there in the http root directory (or click the link to stats at the top).

I have to say though, I find the API a bit funky.  I was just expecting to use it as a JSON-RPC socket (like you would with bitcoind) but no, you seem to have to literally open a socket, jam some JSON in it and then it spews JSON back out.  I have just worked around it, but on my todo list is to see if I can get it to behave more like a RPC service (pushed to main git of course, if accepted).

EDIT:  BTW, You get your RasPI yet?

[kano]

...
I have to say though, I find the API a bit funky.  I was just expecting to use it as a JSON-RPC socket (like you would with bitcoind) but no, you seem to have to literally open a socket, jam some JSON in it and then it spews JSON back out.  I have just worked around it, but on my todo list is to see if I can get it to behave more like a RPC service (pushed to main git of course, if accepted).

EDIT:  BTW, You get your RasPI yet?

No rpi yet.

As for the API - it's like that by design - and you'd need a good argument to get it changed - coz I wrote it and have veto on it - and backward compatibility with itself is one of the biggest points I have with it.
Curl sux and using a web protocol to send a single simple string is beyond ridiculous IMO
There is sample PHP, Java and C code included with cgminer (and miner.php itself) for the basics of talking to the API.
But it is indeed the simplest socket there is: send a string (packet) and get a string (packet) back and close.
Also happens to be the smallest and easiest amount of code to do that also
You can even use any simple socket tool to send a request and get a reply (e.g. nc)
It doesn't need to be JSON either (in fact I don't use JSON as you will see with miner.php, just simple text) - JSON was added for no particular reason as an after thought when I didn't want to and no one paying for the bounty requested it - other than it was easy to add and someone unrelated asked about it. JSON sux, doubles or triples the size of the data, and requires a slow processing (library) at both ends ... and doesn't support comments
The cgminer clone even uses JSON to pass API data around internally in the C code - yep I rejected that change also - that's also ridiculous - and it's not in 'the' cgminer.

[MineForeman.com]

Agreed, backward compatibility is a great thing to maintain, and should be done so at just about any cost.

However horizontal compatibility is probably even more important (i.e. compatibility with every other application in the same class or related classes).  Like it or not JSON-RPC is the standard for bitcoin, bitcoind uses it, many thousands of web api's use it, even cgminer uses it.

Inventing proprietary protocols that don't conform to established standards is a very harmful thing, it is a tactic that microsoft has used for years to stifle innovation.

[kano]

Hmm - I don't think the proprietary non-standard rpi is harmful ... nor that because 'everyone' uses something I must use it also ...

[BenTuras]

Using your 'hotplug' trick seems to work though, can I ask if it is still mining at 200.2Mh/s?

Since I saw a lot of HW errors on the web page stats, I thought it was because of all the fiddling that I had been doing to get it going. So I restarted the Raspi (without making a screen shot ). But now after about 3 hours it still shows about 66% HW errors:

Code:

Web page stats:
Rig	Elapsed		MHS av		Blks	Accepted	Rej	Utility		HW Errs		Net Blks	Work Utility
0	2h 56m 21s	207.45		0	510		0	2.89/m		347		24		4.86/m

BtcGuild reports(this from running a few days):
Speed		Accepted (%)		Stale/Dupe/Other		Last Share
187.78 MH/s	16511 (99.82%)		30 / 0 / 0			0:00:37	

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

[kano]

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

[MineForeman.com]

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.

[kano]

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.

Ah OK I didn't scroll up to see what it was.
Well if it's a ztex then the latest code (from denisx) does the out of bounds work checking properly also.

I didn't write any of the ztex code and have avoided it altogether coz I don't have one, but I think what it does is check the non-share results returned at the end of processing? (or some such)
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?

[serp]

I'm having trouble getting dhcp to pick up automatically.

I'm pretty familiar with Linux but I've never used Arch before and I'm trying to debug off a little 7" screen I have for the rpi.  I generally ssh into the box but with the network not up I obviously can't do that.  I actually got the network to come up once after rebooting a few times but then after rebooting again it was not working anymore and I've not been able to get it to come up again.

The /var/log/errors.log file shows "failed to start dhcpcd on eth0" over and over.

I did some searches and ran across a few threads which lead to this https://bugs.archlinux.org/task/31093
which seems to be the most likely culprit. 

I've had this same thing happen on 2 different sd cards on 2 different rpi.

[MineForeman.com]

The /var/log/errors.log file shows "failed to start dhcpcd on eth0" over and over.

Not in front of my device at the moment, but I got that when I first pluged in my device.  I upgraded the firmware and it went away.  

Is the LNK light on?  Mine was not till I updated.

I did some searches and ran across a few threads which lead to this https://bugs.archlinux.org/task/31093
which seems to be the most likely culprit.  

I will look into that when I get back in front of the device, I had heard of that debate but I was lead to believe it was only a problem if you had more than 1 interface (eth0).

[serp]

The /var/log/errors.log file shows "failed to start dhcpcd on eth0" over and over.

Not in front of my device at the moment, but I got that when I first pluged in my device.  I upgraded the firmware and it went away.  

Is the LNK light on?  Mine was not till I updated.

Ahh well I just unboxed and booted up so maybe it's the firmware.  I'll do that then try.

[MineForeman.com]

Was the LNK light on?

EDIT:  Just checked, I do include the latest firmware with the image so it wont be that.

[serp]

I burned a fresh raspian image and had the same issue on both rpi.  If I manually set an ip it works fine though.  It's odd cause every other device on my network is dhcp and I know I've used one of those rpi with dhcp before but it might have been an older release.  I ran out of time playing last night but I'll try setting a manual ip in your release tonight.  I'm assuming there's an interfaces file somewhere in arch.