Doh!
Yeah, fixed now in the ditro. I still had the php code for saving the miner configuration file to /opt/pinepeon/etc/cgminer.conf. I had moved the file to /opt/pinepeon/etc/miner.conf and used the same file for cgminer and bfgminer.
I will get a new image out tonight (in about 8 hours) to fix the problem.
I do have plans for multi rig support Morblias, I just have not got to it yet. It was one of the things I plan to add after I get out of alpha.
Topic: Linux mining distro for the Raspberry PI - MinePeon - page 135. (Read 684877 times)
It seems like it is using miner.conf. I also modified cgminer.conf and it didn't stay, then changed miner.conf and it was all good. I also modified index.php to combine it with miner.php so it shows both the graphs and stats on same page (http://i.imgur.com/nKniGUA.jpg), and removed the submit button so someone couldn't get on it and change my pool.
In miner.php all you need to do is add your other IPs to $rigs (and make sure to do --api-listen and --api-allow RPi IP on other rigs):
I am not really sure how rrdtools works, but this might be possible for the graphs also. Any idea MineForeman?
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.
In miner.php all you need to do is add your other IPs to $rigs (and make sure to do --api-listen and --api-allow RPi IP on other rigs):
I am not really sure how rrdtools works, but this might be possible for the graphs also. Any idea MineForeman?
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.
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.
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?
The Rpi is awesome
Those graphs are amazing! Thank you
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.
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.
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.
... 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.
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.
... 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 ?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?
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.
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)
... 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 ?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?
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 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.
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
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
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
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.Share Reset
Stats
Accepted (%) Stale/Dupe/Other
bensguild_raspberry 226.16 MH/s 35368 (99.88%) 42 / 0 / 0 0:00:15
Any other log I can check ?
And also thank you !
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).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
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!
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.
.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.
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.
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.
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.
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.
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.
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.
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.
.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.
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
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 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
. Jump to: