Topic: rpi B for cgminer - page 2. (Read 7858 times)

Perfect. I'll take it from here, and read up on it in the morning. I did get miner.php working on the Pi and noticed the Rig column and got all excited knowing I would be figuring out the rest soon. Thanks again for the nudge in the right direct. I love getting under the hood with this stuff.

As per API-README ...
You need to have cgminer run the API ... --api-listen
You need to say who can access it ... default is only from the machine cgminer is running with read only access.
--api-network OR --api-allow define who can access the API
Next your miner.php has a $rigs to say where to look for 1 or more cgminers.
The default is 127.0.0.1

... lots more about multiple rigs and --api-allow and miner.php and ...

Thanks! That's funny, I was just figuring out where to drop the miner.php file when got the alert on your post. Next I will read up on using the api to read cgminer data from rig to another. That should be possible right?

Do you want the rpi running the web server or something else?

If you want the rpi to run the webserver, one way is with apache and php
I'll not bother running on the rpi coz I don't need that extra stuff on there, however, the xubu commands are:
sudo apt-get install apache2
sudo apt-get install php5
sudo /etc/init.d/apache2 reload
"next copy miner.php to /var/www/"
"then view the rpi http://rpi-ip/miner.php"

I'm not scared of it and will spend lots of hours trying to figure something out or make it work in my environment. I keep LOTS of notes and I do compile cgminer builds as they come out. I've "bolted on" the latest cgminer to several BAMT rigs, etc.  After seeing and typing in the same things a lot I've started to pick bits up here and there to tweak and make things work better for me. (Scripts etc.)

I am interested in learning how to build a watchdog process like he made here: https://bitcointalksearch.org/topic/raspberry-pi-cgminer-for-your-bfl-bitforce-128789 to reboot the Pi on lockups or crash. For the most part things have been stable but I am looking to have things redundant or fail safes where possible as if you have a hand full of Single SC go down, you'll be loosing coin quick! Not like today where you can get to it in an hour or two and not feel it much. I have 5 Pi's ready to go as to not have all my eggs in one basket, it's just a matter of how many SC's each Pi can handle.

My ultimate goal would be to have a web front end that has all the info and stats from ALL the rigs, that is why I was looking into the miner.php code that comes with cgminer. I'm just trying to have a one page view of the farm. So I guess I will travel down the apache and php road and see where it takes me.

I just found your MinePeon project the other day on the BFL Forum and will definitely check it out. It looks pretty cool. Thanks!

How familiar are you with Linux?

The absolute cheat way to do it is download and install MinePeon, find its IP (from your router probably), visit the web interface, set up your pool then click on the 'stats' link at the top.

If you are somewhat familiar with Linux though, scroll up a bit and Kano has instructions on how to compile it all on a default whezey build, all you will need to do is install apache, php and drop miner.php in place.  I will look around, I was some step by step instructions somewhere that I will link (when I find them).

Has anyone seen a walk-through or setup guide for getting miner.php working with a Pi? I could have swore I saw one at one point, but I searched through my notes & bookmarks to no avail.

The problem with serial-USB is that each device has it's own kernel driver.
Thus each driver's bugs are able to take hold and cause problems (and cause incompatibilities between them)

I've not bothered to rewrite the Icarus driver coz ... I've not had the time and not really something I care too much about ...

Everything else (non-GPU) on cgminer uses libusb and mining with two different devices (BFL and MMQ) going through the same libusb has not had any major problems (i.e. no problems that were rpi specific)

All the new ASIC drivers we write are (and will be) libusb also.

... I'll have a few ASICs soon ... well ... certainly before the end of the world at least

Me too, just to make sure that I don't spread mis-information though it is NOT lib-usb that has the issue, it seems to be only the serial-usb that has 'issues', and even then I have no serial-usb FPGA devices to test with (like Kano did, and found problems).

And added to that, no one has tested ASIC with the Pi (lib-usb or serial-usb) so it may turn out to be a non issue.

Yeah, looking forward to see if it can handle 2 or 3 Single SC's. 

I can verify there are problems with the serial-USB and the default raspbian pi kernel (and any other kernel that I try).

I can also verify that the problem is NOT present in x86 and i386 identical builds (apart from architectural) so the problem is most likely somewhere or something to do with the Pi itself.

This is no means a show stopper for mining on the Pi, it is just something to be aware of.

Well after all this time just using BFL and MMQ FPGAs with direct USB without real problems, I tried my Icarus which still uses serial-USB
The rpi itself crashed when I first plugged them in.
Within 10 minutes of mining it crashed again - so I've decided to avoid doing that again with an Icarus.
YMMV

Awesome, thanks!

Just in case anyone was interested ...
I have been making an rpi binary at the same time as my usual binary I release when ckolivas makes a new release.

2.11.2
https://bitcointalksearch.org/topic/m.1603027

I put the binaries in my cgminer-binaries git:
https://github.com/kanoi/cgminer-binaries

I've had my rpi (still using 2012-12-16-wheezy-raspbian) running for a few days now with 1xMMQ and 1xBFL without any trouble
(with only one manual restart coz I rewrote a part of the MMQ driver)

I noticed that the MMQ was using about 3% CPU per daughter board (so about 12% for an MMQ)
So I changed the MMQ code to only poll every 100ms (instead of every 10ms) and check the temperature every 500ms (instead of every 300ms)
This has reduced it to roughly 0.5% CPU per daughter board (so about 2% for an MMQ)

On top of that of course there is the main cgminer code - and that's using somewhere around another 0.5% CPU Stratum mining on OzCoin
(and the BFL is using a bit under 0.2% CPU)

This does bring up some information in advance for ASIC
The BFL SC polling for results will probably be only a few times every nonce range time - so for 80GH/s it will be ~54ms per nonce range so maybe poll once every 1/3 of that (or maybe only once per nonce range will be enough?)
Anyway I haven't decided yet and of course wont until I actually have some hardware - but the reality is that it may well only be as much USB CPU usage as the MMQ code before I changed it.
The amount of data sent to do the work would be of course be one queued element per result (based on the current BFL spec) thus it may even be realistic to consider the USB CPU usage of the BFL SC Single to be less than the old MMQ code.

However, the main cgminer code will be processing 70~100 times the number of 1diff shares.
So I'd guess that the rpi should be able to handle a single 60~80GH/s ASIC, but not sure how that will go with more than one.
Of course until I get some ASIC hardware and can see the real CPU usage, this is all just guess work

P.S. my new MMQ code is in my 'hotplug' branch here:
https://github.com/kanoi/cgminer/tree/hotplug

hmm maybe the MMQ needs an --mmq-options so you can specify the poll time ...
(something like Icarus has for specifying options)

Good point, I am very interested in this as well, I dont have FPGA's to test with but I was never able to reproduce the problem with either wheezy-raspbian or MinePeon, and I tried really hard.


MinePeon is meant to be a plug and play, lean and mean optimised mining build.  Having to log in, download stuff, run scripts and configure stuff is something I am trying to avoid.  I am trying to make it accessible to all, no mater what your linux skills are like.

I'm interested to see what the USB problem is with the standard rpi release or if it is gone.
I'll use that as the base for testing, since that's what rpi release with it.
In general I avoid custom kernels+releases for a number of reasons (I've mentioned on the board before) but in this case I'll test yours also when I have time.
However, at this point even playing with this is time I'm short of.

Had the compile failed I probably would have delayed it until I actually got an ASIC because:
I've got my plane tickets to BFL - Kansas City today (email digital ticket details from the travel agent) from Josh
So I'm now short on time for the next month
I never get much done quickly - so the flight to the USA on the 17th Feb (my time) and a week in total, means there's stuff I need to get done before that - non BTC stuff also
I'll test it with your kernel/config when I get to testing the ASICs but your custom interface/mining management anyone can test and I'll not use it anyway.

My original interest with your custom version was to resolve USB problems, but if the problems aren't there any more, then IMO you are better to supply a script+downloads to produce your release from the base rpi release (of course if the USB problems are still there - then that's a completely different issue altogether) So for now I'll just let it run on wheezy-raspbian (2012-12-16) and see if it fails/crashes/drops the device at all.

Good to hear you got it all going .

Any reason you used wheezy?  It would have been nice to have you on-board as a tester/contributor.

After messing with it for a while ... then finally connecting it to my 40" HDMI TV ... I found why it wouldn't boot.
It didn't like my new cheap Class 6 4GB SD card so I gave up until I had time to find another one.
Yesterday I found an old (2006) 2GB one from my camera (in 'archive') that was full of photos ...
Transferred all that to the new 'crappy?' 4GB and put the new 4GB into 'archive' then put 2012-12-16-wheezy-raspbian on the 2GB and all works fine.

FYI anyone wanting to compile FPGA USB style from 2012-12-16-wheezy-raspbian add the following:
apt-get install vim screen
apt-get install automake
apt-get install libcurl4-openssl-dev
apt-get install libusb-1.0.0-dev
apt-get install libncurses5-dev
CFLAGS="-g -W -Wall" ./autogen.sh --enable-icarus --enable-bitforce --enable-ztex --enable-modminer
make clean
make

No code changes required at all
... and my new USB code/hotplug/Device locking all works fine with the BFL (the device locking is if you run 2 cgminers)

When I ran the above I didn't include ztex coz I don't have one.
Icarus you'll have to specifiy the /dev/ttyUSBn or also: apt-get install libudev-dev
However I detest the serial-USB and thus have no desire to even install libudev-dev for testing

So this is a first attempt at using the standard rpi ubuntu and see how the USB survives.
http://www.raspberrypi.org/downloads

Click on the images to see bigger ones:


For the power lead I was able to use an old wall plug phone charger I have - I found to my surprise

Much thanks indeed to MineForeman.com for the rpi B 512

So now it's ready to try ASIC as soon as I get one and write a driver

Pi seems broken in this font.  To me it looks like a RN (Short for registered nurse) has turned up any your going to play with her.

Anyway, have fun, its a great toy.