Topic: Linux mining distro for the Raspberry PI - MinePeon - page 136. (Read 685140 times)

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.

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.

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.

Was the LNK light on?

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

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

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 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).

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.

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?

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.


Agreed.

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

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:


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

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

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.

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.

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).


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?

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)

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).


100% agree.


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.


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).


Thanks, that sums up the goals of MinePeon exactly!

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.


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.


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


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   .

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.

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.