Topic: rpi B for cgminer (Read 7858 times)

No the CPU usage isn't directly linear.

However, USB seems to be the larger factor in CPU usage on the rpi.
My driver also doesn't linearly increase the polling for work results - with the Jala, it polls more often than needed since latency is still an issue when it takes almost 1s to complete a nonce range.

The 50or60GH/s device will need polling for results about twice as often as I do with the Jala
Sending work to it of course is 10x as much and processing replies is also 10x as much.
Anyway, we'll see once I get one ... not sure when yet.

How much do you think the rPi could handle? If a SC Single is ~10x as much hashpower, are we gonna see ~10x as much CPU usage?

I tried a while back, it to ~275 days to-go worth of data, then seems to take longer than a day to add the blockchain for that day - so was neverexpected to finish - left it a while and my rPi died

Another good reason for having "balance as at" version of the blockchain

Yeah!

Jala rpi screen shot ... mining 256diff - using approx 3% CPU
Click to see:

That is good to hear, I really hope they can handle a Single SC.

Finally switched mine off today to replace the SD card (attempt 3 - this time Class 10, 8GB)
A bit over 23 days non-stop mining on an MMQ at 820MH/s with cmginer2.11.3a
(was actually mining for 26 days but I restarted cgminer when I updated it to 2.11.3a)

I was wondering if something like this would work, but running it on an SSD in a SATA to USB case.

I have, it runs fine.  I will eventually be including it as part of MinePeon for the PI but it will most likely require access to a bitcoind running on another machine.

I have actually even had bitcoind running running on a PI but I gave up long before the blockchain synced.  I suspect if I let it go I would have ended up with a toasted SD card.

Is anyone running p2pool on an rpi?  I would guess the memory overhead of running bitcoin-qt would be WAY too much for the 256MB memory in my rpi (or 512MB in the newer ones) and SD card combination. 

Has anyone done this yet?  If so, what were your results?

dd if=/dev/mmcblk0 | ssh 192.168.0.X "dd of=/home/minepeon/latest.img"
^^^^^ Saved my ass on my development PI thousands of times. 

(I am not near it and not logged in so that is from memory, change to fit your needs and put it into crontab)

Ahhhhhhh 

I win!  (linux geek competition going on here)

But seriously, if handled right the PI seems rock steady.  Perfect to be used as a mine controller.

Cool, good to hear. I've had no issues either.

My Pi has the following running on it:
- cgminer with 4 BFLs
- apache / php5 / miner.php
- stratum proxy (for my last 2 BAMT rigs I don't want to mess with since they are 100% stable and have been running over 9 months without a reboot) 
- hamachi (so I can link miner.php between 3 locations giving me one page to see the whole farm)

Good stuff man, that Pi was the best bang for buck I tell you. 

[root@minepeon log]# uptime
 14:12:22 up 19 days,  4:29,  2 users,  load average: 0.03, 0.05, 0.09

I really hope the ASICs will work on the RPi!

Well I ran the rpi-update a week or so ago and it ONLY just fits on my 2GB
Free space went below zero but of course the silly -m root space saved that.
Guess I better buy (yet another) 4GB soon.
Got yet another one last week (Class 6 this time) and it keeps failing when I try to extend the partition or even sometimes on the 2nd boot after copying the image on it - I guess I need to spend more than $10 on the SD to get a good one next time

Anyway, it now says:
# /opt/vc/bin/vcgencmd version
Mar  7 2013 19:37:36
Copyright (c) 2012 Broadcom
version 375458 (release)

... and since then ... been running non-stop with a single MMQ without any trouble at all.
I restarted cgminer early on when I was updating cgminer, but linux has been running non-stop for more than 9 days without a failure!
# uptime
05:52:39 up 9 days,  8:19,  2 users,  load average: 0.02, 0.06, 0.07

cgminer 6.75 days runtime:
cgminer version 2.11.3a - Started: [2013-03-20 11:46:46]
--------------------------------------------------------------------------------
 (5s):339.1M (avg):818.0Mh/s | Q:27211  A:499  R:3  HW:977  E:2%  U:0.1/m
 ST: 2  SS: 4  DW: 50329  NB: 1330  LW: 191680  GF: 9  RF: 0  WU: 11.5
 Connected to au.ozco.in diff 256 with stratum as user ...
 Block: 00fade471f1c07d6...  Diff:6.7M  Started: [05:54:22]  Best share: 44.9K
--------------------------------------------------------------------------------
 [P]ool management [ S]ettings [D]isplay options [Q]uit
 MMQ 0:  44.6C 196MHz  | 196.0M/195.4Mh/s | A:121 R:0 HW:372 U:0.01/m
 MMQ 1:  46.3C 208MHz  | 207.9M/207.5Mh/s | A:135 R:0 HW:197 U:0.01/m
 MMQ 2:  46.3C 210MHz  | 210.0M/210.3Mh/s | A:135 R:2 HW:191 U:0.01/m
 MMQ 3:  41.0C 204MHz  | 204.0M/204.8Mh/s | A:108 R:1 HW:217 U:0.01/m
--------------------------------------------------------------------------------

Just an FYI - I rarely don't use root - I've been logged in as root on every linux computer I use and run for the last 16 or 17 years and I'm not going to stop doing that.
I do run cgminer as non-root on my GPU mining rig since xubuntu boots into the user and you need to be that user to avoid having to use xhost
... and of course the rpi image has a 'pi' user so I've been logged in as that for rpi mining.
I blame btcoin for having started using non-root for mining ... but only for mining ...

Yeah, that is strange... Don't the network and USB use the same chipset? I though I read that somewhere, but I could be wrong. I like your failsafe/reboot Pi crontab script. (noob linux skills, trying to learn how to do that myself)

Just wondering, have you updated the firmware on your Pi? https://github.com/Hexxeh/rpi-update

Well that was interesting.
I had made a small change to my cgminer run script to log on the rpi instead of my main fileserver ...

I had a look at the two logs (for the above crashes) and they showed cgminer still running.
The rpi hadn't died, just the network had.
So the problem may be some interaction between the "Prolific Technology, Inc. PL2303 Serial Port" and the network driver?

I've written a crontab script to check if the network has been down for 5 minutues and then request a cgminer quit and shutdown the rpi
... coz I don't (usually) have a display or keyboard attached, it means it shuts down properly rather than pulling the power out
The cgminer logs show that happening also.

Anyway, the logs show:
cgminer
 [2013-03-14 09:57:47] Stratum connection to pool 0 interrupted
 [2013-03-14 09:58:02] Pool 0 http://au.ozco.in:3333 not responding!

syslog
Mar 14 09:58:03 raspberrypi ntpd[1908]: Deleting interface #2 eth0, 192.168#123, interface stats: received=99, sent=103, dropped=0, active_time=1204 secs
...
Mar 14 09:58:03 raspberrypi kernel: [ 1267.800680] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000014
Mar 14 09:58:03 raspberrypi kernel: [ 1267.800711] smsc95xx 1-1.1:1.0: eth0: Failed to write HW_CFG_LRST_ bit in HW_CFG register, ret = -110
...

kern.log
Mar 14 09:44:36 raspberrypi kernel: [  460.821299] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Mar 14 09:56:41 raspberrypi kernel: [ 1185.918029] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
... that 2nd one repeated every ~5 seconds until ...
Mar 14 09:58:03 raspberrypi kernel: [ 1267.800680] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000014
Mar 14 09:58:03 raspberrypi kernel: [ 1267.800711] smsc95xx 1-1.1:1.0: eth0: Failed to write HW_CFG_LRST_ bit in HW_CFG register, ret = -110
... then more of the above until shutdown


So basically it's the nic/nic driver that's the problem (smsc95xx) and I've seen nic errors in the logs before without mining with my Icarus

Yes thanks! I woke up and got it done. All rigs working. Now I'm off to "myminer.php" customization land. Ha.

After you read up on it, you will realize how easy it is. Only takes a couple steps to add all rigs to the miner.php via the API

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.

r π arrived! ... now to play

made my day

Heh - maybe you've discovered what happened to the Avalon ASICs after all

And.............

Customs seem to think it is some sort of incendiary device that shoots users full of heroin.....  (while downloading a torrent containing music, movies and wiki leaks files no doubt)

Suffice to say it is back on my desk now and I am filling out a declaration form. 

I should have done the declaration fist time, it will get back in the post today.

PM sent

I have a spare, PM me your details and I will ship it to you (Your only just across the ditch from me (NZ)).

Don't worry about the payment, with what I am working on it would be good to have one of the miner developers knowing that I exist  .  If anything donate it to my project working with Raspberry Pi's ( http://mineforeman.com/minepeon/ ).

I don't suppose anyone knows how to get an rpi B, paid with BTC, to Aus? (and arrive here in the near future
.. and somewhere that has it in stock ready to ship.

Current price is less than 3BTC (but I can't afford to pay with anything but BTC)
I'm interested in getting one for supporting it properly in cgminer (and using it also)
No doubt having one when I do the ASIC code would help ensure it works on the rpi also - there will be noticeable differences running ASIC vs the slower FPGA on USB ...

Of course I wouldn't at all be against anyone offering to send me one/pay for it

But if I buy it, I have to pay BTC and neither of the sites listed here support BTC.
https://bitcointalksearch.org/topic/m.1373669
... and I've no idea how long they would take to send it here anyway.

Anyone want to do a deal to get me one?

Well I'll pay the full ~3BTC (which should cover shipping also at the current BTC price) if no one is interested in supporting paying for it ...