Minera unusable when using with multiple G-Blades about minera

[michelem09]

I'm investigating this, I'm thinking about a problem to get such large data from the minerd to parse the stats.

[prolic]

@jess85 G-Blades stopped mining at my rig, too. After installing the latest update of https://github.com/siklon/cpuminer-gc3355 (this commit siklon/cpuminer-gc3355@93f6b97) these problems disappeared.

Don't know about the stats problem, sorry.

[michelem09]

Let me update CPUMiner in Minera, I didn't see the update.

[jess85]

Is the updated CPUminer already live in Minera 0.1.10a? what can we do next to help resolve stats and performance issues for those running multiple G-Blades?

[michelem09]

Yes there is. I'm sorry but without having the ability to see what's happening is really hard for me.
Don't know if you can, but let me access your Rpi could be really useful, of course I won't touch anything neither stop the miner, I only need to see how the stats were get and how they are stored.

[michelem09]

Please @jess85 can you do a pull and retry? I did a change I would like to test with your environment.
I think the problem for the stats is strictly linked to the amount of data your miner have to send to Minera which in your case (10 G-Blade units) is really big.

Please try this:

cd /var/www/minera
sudo git pull
sudo service php5-fpm restart

After this, try to see the dashboard with the miner started. Try also to see the URL

http://<mineraip>/minera/index.php/app/stats

Please let me know

[jess85]

Will be able to test in just a few hours when I get back home. Will let you know then.

[anthonyboone]

I'd love to add another blade to my setup. —
Anthony Boone
[email protected]

On Mon, May 19, 2014 at 11:33 AM, jess85 [email protected] wrote:

Will be able to test in just a few hours when I get back home. Will let you know then.

Reply to this email directly or view it on GitHub:
#19 (comment)

[michelem09]

Anthony, how much Blades are you running on Minera now?

[prolic]

I am running on 2 blades + 10 mini usbs. Third blade is coming ...

[jess85]

At around 5 whole blades (10 blade boards) it starts messing up. Sometimes it will work with 5 whole blades sometimes it won't. But once you pass that it starts messing up very quickly. 10+ is instant broken. It works most smoothly at around 2 whole blades. Doing a pull as you requested.

[anthonyboone]

I am running one blade. With blades getting cheaper I might as well get one. —
Anthony Boone
[email protected]

On Mon, May 19, 2014 at 9:39 PM, jess85 [email protected] wrote:

At around 5 whole blades (10 blade boards) it starts messing up. Sometimes it will work with 5 whole blades sometimes it won't. But once you pass that it starts messing up very quickly. 10+ is instant broken. It works most smoothly at around 2 whole blades. Doing a pull as you requested.

Reply to this email directly or view it on GitHub:
#19 (comment)

[michelem09]

Please @jess85 let me know after the pull if something changes.
Thanks

[jess85]

So the reason for my delay is because I've been hit with quite a dosage of wtf.

You see, I did as you told me to and the upgraded raz kept on having the same problem.
HOWEVER, meanwhile a secondary raz that I have, that was not re-updated as you requested all of a sudden started working with about 20 whole g-blades connected to it. So I'm left very confused. I redid the entire process twice to make sure the raz that is working is not the re-updated one, and I just don't understand why. I hope you might :)

[jess85]

...and now they both have their stats working. The stats.json produces an error every once in a while but now it doesn't seem to break the entire system and at worst just causes for a 1-2 minute delay in stats update. Can't speak about performance yet (but that would likely be cpuminer, not minera, right?).

[michelem09]

Please @jess85 try the new update 0.1.11 I just pushed (there is also on-the-fly pool selection), and probably this could fix completely the G-Blade problem.
Please let me know!

[jess85]

Seems like it is all working but can't verify because I'm getting a constant barrage of: "DataTables warning: table id=pools-table-details - Requested unknown parameter '2' for row 0. For more information about this error, please see http://datatables.net/tn/4" errors.

[michelem09]

Can you clear the browser cache? How many pools have you?

[jess85]

1 pool. clearing now.

[michelem09]

please try to save&restart too from the settings page

[jess85]

Also did save&restart.
No more errors but stats page broken again. Stats page produces a bunch of NaN values for frequency, %hw, %ac, and %re. All miners after row 3 have proper frequency and last share time though.

[jess85]

What I said on the last post was regarding the miner table so to clarify, in addition to the miner table, none of the other values on any other place on the page is working. Except temperature, pool alive, and miner uptime I suppose.

I am using IE9 if its of any value. Will try other browsers to see if I get similar results.

[jess85]

Good news. Firefox, everything works perfectly. I'm an idiot for not trying that right away.. my bad.

[michelem09]

Yes please try Firefox or better Chrome.
Then please check the page:

http://<mineraip>/minera/index.php/app/stats

And if you can paste the result in www.pastebin.net

[michelem09]

Really? Yes IE is really bad and I'm developing Minera on a Mac so I never tried it on IE.
So how many G-Blade can you run now together without problems?

[jess85]

Will do a stress test in a couple hours

[michelem09]

hey thanks for your time really appreciate!

[jess85]

Well, it definitely can not handle 14 whole G-Blades and above. Went down one blade board at a time restarting the miner every single time until I was down to 14 G-Blades. Then I got tired. stats.json still says {"error":true}. Also important to note, miner runs only 30% of the blade farm or only 30% capacity of each blade after about 5 minutes of running. I have to separate them into different raspberry pi's to get it to perform properly.

[michelem09]

Well, I think this is a case-limit of the whole architecture starting from USB Hub to G-Blades, RPI, Minerd and Minera. I don't think it's the case to try more than this.

May be with an Ubuntu installation on a common PC instead an RPI something could change but nevermind if you can't try.

Well, I'm going to close this putting a warning on the README. Can I write Minera on RPI cannot handle more than 10 G-Blades?

[jess85]

Before you do this, I'm going to stress test every miner software out there. It might just be RPi that's the problem making your software is great for other raspberry pi like products and linux laptops/pcs when someone wants to run multiple blades and also good with RPi if they run gridseeds/few blades/etc.

[michelem09]

Hello @jess85 I just pushed a commit that could probably fix the large data problem.
Try at least with 5 Blades:

cd /var/www/minera
sudo git fetch --all
sudo git reset --hard origin/master
sudo ./upgrade_minera.sh

Please let me know.

[michelem09]

Jess, I'm closing this as solved because I think the fix should work fine.
Please feel free to reopen if you wish.
Thanks

[jess855]

Sorry for the dalyed response, forgot username and password and finally decided to create new account. You solved the problem alright and basically here's what I found.
While each G-Blade = 2 boards.
If you adequately power your usb hub(s) you will reach a raspberry pi limit of 17 boards (8.5 G-blades) with stable performance. There is a way to get flaky performance up to 21 boards per raspberry pi but I'd recommend staying at the 17 boards because I have yet to experience unexplainable low megahashes per board or slowly decaying performance.

I believe it is a memory limit of raspberry pi but heck I just rather purchased more Pis than figure it out at the moment :)

[michelem09]

Very good! Thanks for feedback!