Closed jess85 closed 10 years ago
I'm investigating this, I'm thinking about a problem to get such large data from the minerd to parse the stats.
@jess85 G-Blades stopped mining at my rig, too. After installing the latest update of https://github.com/siklon/cpuminer-gc3355 (this commit https://github.com/siklon/cpuminer-gc3355/commit/93f6b97e9a2f1d374f7a8a4a05a61c023735d911) these problems disappeared.
Don't know about the stats problem, sorry.
Let me update CPUMiner in Minera, I didn't see the update.
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?
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.
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
Will be able to test in just a few hours when I get back home. Will let you know then.
I'd love to add another blade to my setup. — Anthony Boone anthonyboone1@gmail.com
On Mon, May 19, 2014 at 11:33 AM, jess85 notifications@github.com 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: https://github.com/michelem09/minera/issues/19#issuecomment-43526662
Anthony, how much Blades are you running on Minera now?
I am running on 2 blades + 10 mini usbs. Third blade is coming ...
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.
I am running one blade. With blades getting cheaper I might as well get one. — Anthony Boone anthonyboone1@gmail.com
On Mon, May 19, 2014 at 9:39 PM, jess85 notifications@github.com 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: https://github.com/michelem09/minera/issues/19#issuecomment-43580951
Please @jess85 let me know after the pull if something changes. Thanks
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 :)
...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?).
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!
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.
Can you clear the browser cache? How many pools have you?
1 pool. clearing now.
please try to save&restart too from the settings page
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.
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.
Good news. Firefox, everything works perfectly. I'm an idiot for not trying that right away.. my bad.
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
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?
Will do a stress test in a couple hours
hey thanks for your time really appreciate!
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.
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?
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.
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.
Jess, I'm closing this as solved because I think the fix should work fine. Please feel free to reopen if you wish. Thanks
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 :)
Very good! Thanks for feedback!
Issues for me begin after running 10 whole G-Blades (20 blade boards) but it may very well begin even earlier, I can't afford to redo my setup to test the exact number at which this problem begins.
The Bugs: Most recently after I did a fresh image flash to an SD and turned up my raz for the first time to input pool info for mining I got a:
in the dashboard.
stats.json:
Log shows:
many times over but other than mining for 10 whole blades (pool confirms this) still nothing. I also tried forcing api port to 4028 via parameter but still nothing.
Another more critical issue is that it will not mine on more than 10 G-Blades (roughly 20 blade boards) at a time. This is a super critical problem because it has forced me to run all blades on 3 raspberry pi's (plus no stats reading =/) and yes yes proper usb powered hubs, same exact setup allows me to mine with all G-blades on an adjacent laptop.
Just as critical, over time, G-blades seem to stop mining one by one until I reset the device (manually) and the low (difficulty) reject rate is exponentially high for at least the first 45 minutes or so (which happens to be around the time it starts dropping G-Blades from the original whole working 10).
I've messed with it long enough by now to safely assume these are bugs born from both cpuminer and minera being incompatible with running over 10 whole G-Blades.
If you have fix for this it would be super duper appreciated :D