Topic: [Minera v0.9.0] Your next mining dashboard - S9/L3+/D3/CPUminer/CGminer/BFGminer - page 152. (Read 850463 times)

Is there a way to force submit stales. For some reason miner(not just this one) think it is a stale share but it is not. I'm loosing up to 20% to his...

I had a similar situation with GHash (Multipool) and with MagicPool. I gave up on those pools and now everything is working properly with Nicehash, Clevermining, etc. Try changing your pools and see what happens.

Someone mentioned the importance of a good USB hub and I second that. If you are powering a RasPi or something else from the same hub where you are connecting your Blades, don't be cheap and buy a decent hub. I'm using one powered by a 2A source. Plenty of juice for my Pi, my Netgear Wi-Fi adapter and to properly connect my 2 Blades

That would be awesome!

Tried to use Minera but the interface I saw in the screenshots here,never showed up at all and secondly it won't connect to my wifi network as I can't access ethernet where I live so I'd like someone to create a plug and play solution that connects via Wi-fi for me.In case you're wondering I'm a new user of this who's frustrated with lack of support for Wifi and thought I'll go back to dealing with what I know instead of trying to make this work as I don't have the time (I run a mining contracts business on top of being a freelance professional video editor and time is money.Using beta software is never a good idea for people like me as they'll be things in there I just don't like and I'm not prepared to deal with the risk associated with it).

I'm only contributing here so I can be sure that the developers understand that the GUI and wifi support should happen out of the box,like it does with a windows PC or a mac and that these features are added.

i tried to split them on more hubs. that doesn´t get better.
i also tried a more expensive hub. same problem.

what makes a hub a good hub?

I haven't Blades but I know they need really good USB powered Hub when they arent' "alone". Did you try to connect one or two Blades only?

Another Problem.

Seams like cpuminer doesn´t detect the blades correctly. Sometimes i have to restart the miner several times, to get them all running.

[2014-06-06 19:39:17] 0: GC3355 chip mining thread started, in SINGLE mode
[2014-06-06 19:39:17] 0: Open device /dev/ttyACM15
[2014-06-06 19:39:17] 1: GC3355 chip mining thread started, in SINGLE mode
[2014-06-06 19:39:17] 1: Open device /dev/ttyACM14
[2014-06-06 19:39:17] Stratum detected new block
[2014-06-06 19:39:17] New Job_id: 90fe Diff: 512 Work_id: fcc59b85
[2014-06-06 19:39:17] 2: GC3355 chip mining thread started, in SINGLE mode
[2014-06-06 19:39:17] 2: Open device /dev/ttyACM13
[2014-06-06 19:39:17] 3: GC3355 chip mining thread started, in SINGLE mode
[2014-06-06 19:39:17] 3: Open device /dev/ttyACM12
[2014-06-06 19:39:17] 4: GC3355 chip mining thread started, in SINGLE mode
[2014-06-06 19:39:17] 4: Open device /dev/ttyACM11
[2014-06-06 19:39:17] 5: GC3355 chip mining thread started, in SINGLE mode
[2014-06-06 19:39:17] 5: Open device /dev/ttyACM10
[2014-06-06 19:39:17] 6: GC3355 chip mining thread started, in SINGLE mode
[2014-06-06 19:39:17] 6: Open device /dev/ttyACM3
[2014-06-06 19:39:18] 7: GC3355 chip mining thread started, in SINGLE mode
[2014-06-06 19:39:18] 7: Open device /dev/ttyACM2
[2014-06-06 19:39:18] 8: GC3355 chip mining thread started, in SINGLE mode
[2014-06-06 19:39:18] 8: Open device /dev/ttyACM9
[2014-06-06 19:39:18] 9: GC3355 chip mining thread started, in SINGLE mode
[2014-06-06 19:39:18] 9: Open device /dev/ttyACM8
[2014-06-06 19:39:18] 10: GC3355 chip mining thread started, in SINGLE mode
[2014-06-06 19:39:18] 10: Open device /dev/ttyACM7
[2014-06-06 19:39:18] 11: GC3355 chip mining thread started, in SINGLE mode
[2014-06-06 19:39:18] 11: Open device /dev/ttyACM6
[2014-06-06 19:39:18] 12: GC3355 chip mining thread started, in SINGLE mode
[2014-06-06 19:39:18] 12: Open device /dev/ttyACM5
[2014-06-06 19:39:18] 0: Firmware version: 0x17031402
[2014-06-06 19:39:18] 0: GC3355 40-chip G-Blade Miner detected
[2014-06-06 19:39:18] 0: Set GC3355 core frequency to 840Mhz
[2014-06-06 19:39:18] 13: GC3355 chip mining thread started, in SINGLE mode
[2014-06-06 19:39:18] 13: Open device /dev/ttyACM4
[2014-06-06 19:39:18] 1: Firmware version: 0x17031402
[2014-06-06 19:39:18] 1: GC3355 40-chip G-Blade Miner detected
[2014-06-06 19:39:18] 1: Set GC3355 core frequency to 840Mhz
[2014-06-06 19:39:18] 14: GC3355 chip mining thread started, in SINGLE mode
[2014-06-06 19:39:18] 14: Open device /dev/ttyACM1
[2014-06-06 19:39:18] 2: Firmware version: 0x17031402
[2014-06-06 19:39:18] 2: GC3355 40-chip G-Blade Miner detected
[2014-06-06 19:39:18] 2: Set GC3355 core frequency to 840Mhz
[2014-06-06 19:39:18] 15: GC3355 chip mining thread started, in SINGLE mode
[2014-06-06 19:39:18] 15: Open device /dev/ttyACM0
[2014-06-06 19:39:18] 3: Firmware version: 0x17031402
[2014-06-06 19:39:18] 3: GC3355 40-chip G-Blade Miner detected
[2014-06-06 19:39:18] 3: Set GC3355 core frequency to 840Mhz
[2014-06-06 19:39:19] 4: Firmware version: 0x17031402
[2014-06-06 19:39:19] 4: GC3355 40-chip G-Blade Miner detected
[2014-06-06 19:39:19] 4: Set GC3355 core frequency to 840Mhz
[2014-06-06 19:39:19] 5: Firmware version: 0x17031402
[2014-06-06 19:39:19] 5: GC3355 40-chip G-Blade Miner detected
[2014-06-06 19:39:19] 5: Set GC3355 core frequency to 840Mhz
[2014-06-06 19:39:19] 6: Failed reading firmware version
[2014-06-06 19:39:19] 7: Firmware version: 0x17031402
[2014-06-06 19:39:19] 6: Firmware version: 0xffffffff
[2014-06-06 19:39:19] 7: GC3355 40-chip G-Blade Miner detected
[2014-06-06 19:39:19] 6: Unknown GC3355 Miner detected (chips=5)
[2014-06-06 19:39:19] 7: Set GC3355 core frequency to 840Mhz
[2014-06-06 19:39:19] 6: Set GC3355 core frequency to 840Mhz
[2014-06-06 19:39:19] 8: Firmware version: 0x17031402
[2014-06-06 19:39:19] 8: GC3355 40-chip G-Blade Miner detected
[2014-06-06 19:39:19] 8: Set GC3355 core frequency to 840Mhz
[2014-06-06 19:39:19] 9: Firmware version: 0x17031402
[2014-06-06 19:39:19] 9: GC3355 40-chip G-Blade Miner detected
[2014-06-06 19:39:19] 9: Set GC3355 core frequency to 840Mhz
[2014-06-06 19:39:19] 10: Failed reading firmware version
[2014-06-06 19:39:19] 11: Firmware version: 0x17031402
[2014-06-06 19:39:19] 10: Firmware version: 0xffffffff
[2014-06-06 19:39:19] 11: GC3355 40-chip G-Blade Miner detected
[2014-06-06 19:39:19] 10: Unknown GC3355 Miner detected (chips=5)
[2014-06-06 19:39:19] 11: Set GC3355 core frequency to 840Mhz
[2014-06-06 19:39:19] 10: Set GC3355 core frequency to 840Mhz
[2014-06-06 19:39:19] 12: Firmware version: 0x17031402
[2014-06-06 19:39:19] 12: GC3355 40-chip G-Blade Miner detected
[2014-06-06 19:39:19] 12: Set GC3355 core frequency to 840Mhz
[2014-06-06 19:39:19] 13: Firmware version: 0x17031402
[2014-06-06 19:39:19] 13: GC3355 40-chip G-Blade Miner detected
[2014-06-06 19:39:19] 13: Set GC3355 core frequency to 840Mhz
[2014-06-06 19:39:20] 14: Firmware version: 0x17031402
[2014-06-06 19:39:20] 14: GC3355 40-chip G-Blade Miner detected
[2014-06-06 19:39:20] 14: Set GC3355 core frequency to 840Mhz
[2014-06-06 19:39:20] 15: Firmware version: 0x17031402
[2014-06-06 19:39:20] 15: GC3355 40-chip G-Blade Miner detected
[2014-06-06 19:39:20] 15: Set GC3355 core frequency to 840Mhz

Hi Guys,

i didn´t have Problems with the Grids but now i got a couple of blades and i´m running into problems with them.

I´ve got two voltmodded with 7 MHash on a separate PI and they work fine.

The others are standart with 5 Mhash and these are having the Problems.
When i start mining, they all work but then one after one dies away. After two hours they are all dead.

Any Idea what to do?

CPUMiner Log http://pastebin.com/rJ3K6Kzk
Minera Log http://pastebin.com/A4pjjpTY

Cheers... Alex

Thanks for getting back to me. I'm using Safari 6.1.4 on Mac OS X Mountain Lion.

This might just be a display problem, or a delay in switching the pools. Because while tailing the log in a terminal window, I pressed the button to switch to another pool, then went to look a the log. Nothing interesting happened so I switched back to Safari. At that point the browser updated and it appeared to have switched pools. So I went back to the Terminal window and saw the "Starting Stratum on…" message indicating a pool switch.

Maybe the switch doesn't kick in until a browser update cycles along? Maybe cpuminer needs another API call to "goose" it into actually using the changed pool?


I understand the non-permanence issue. While that's important to consider, I think it's not the effect I'm seeing here.

My guess is that when you start cpuminer with the pool list from a config file, that establishes the failover order. If you later use the API to tell cpuminer which one to use, and that one fails at some point, maybe cpuminer goes back to the original list provided in the config file.

Does Sandor's JSON API allow you to specify all of the pools dynamically, or can you only tell it which one is current? I think what would be needed here to round out the feature and prevent the need for a restart of the miner is the ability to provide the entire list via the JSON API, re-establishing the failover order.

Regarding the permanence issue, I think it would be nice to have the option to be able to save the order change. Or maybe you just always save it without asking when the order is changed.

In my use case, I rarely change the pool order. When I make a change, it's because I'm dissatisfied with a pool's profitability (or something) and I want to use another one. At that point I might not make another pool order change for weeks. It would be nice to have that change be permanent so that if something bad happens, my rig doesn't go back to the original order.

As for browsers, happens in the ones I use the most: Opera and Mobile Safari. Also tested on IE, same thing, but as you've said, IE is really bad. I can test on other browsers if needed. CPUminer log continues as normal after clicking. If I click fast 3 or 4 times, I manage to get the pool switched, and the log finally says the API requested a pool change.

Are these voltmodded? I noticed the 1200mhz speed and now I'm wondering if it's possible to blow up your gridseeds if you overclock them too much.

A safe speed all gridseeds will work decently on is 850 mhz and just start editing from there.

what code did you use to add the mining contract timer?

The first one I have to reproduce that (Browser? Can you look at the cpuminer log when you click to see if something happens?)

The second one is simple, the problem is: I don't overwrite the settings when switching a pool from the dashboard, it's completely on-the-fly and not permanent, it just sends the command to cpuminer without saving anything. But of course, if you prefer and you think it's better I can easily add the save too.

For who asked Latest Minera image for RPi is here

(Or just click my signature and scroll down the page)

Already reported the first issue in the thread, I confirm it's really difficult to select a new pool.

The second issue... I don't think it's really an issue, I think it's the default behavior, and I find it better to be like this But it would be nice if we could opt for what we want.

There are some issues with the feature of dynamically selecting a pool. Basically I switched pools the other day, and I did it from the dashboard instead of changing the order in the pool in the settings and restarting.

The first issue was that I had to click the "Select This" button twice. The first time didn't seem to do anything. Or at least it didn't show any differences in the pool selection in the dashboard.

The second issue is that last night the pool that I dynamically selected must have had a connectivity problem. When I woke up this morning, the rig had switched back to the first pool in my settings, not the one that I had dynamically selected.

What it seems like is the pool order specified in the settings seems to ultimately "win" over any dynamic selected pool if that pool has a connection problem. Given that, I think that the only safe way to manage pools currently is to change their order in the settings and restart the miner. That's what I did this morning.

What would be really nice would be if we can change the pool order in the settings without restarting the miner, and have that take immediate affect. That in combination with the dynamic selection of a pool would be a big improvement in pool management.

Maybe it does in fact already work that way, but I didn't try it and have no way to confirm it.

someething weird is happening, it`s been running fine but for about 2 hours now, the front end is not updating the stats, the command all work and i can restart the miner but i got no stats, no matter what i try,
i tried reboot, updating manually via ssh. restart the miner etc. in ssh i see cpuminer working fine.

Probably something stuck in the PHP but i don`t know enought to go play in there.

any help would be appreciated.

i really need to start backing up my ssd card when everything is working good. 

Sorry for sounding like a total Noob, but the whole pi controller thing is new to me.  I ssh into the controller, I'm assuming the ID/PW is minera/minera.  and reallty set nothing.  Just one file, no directories.  Also (since I'm out of town today), what is the link to the latest image?  Just want to make sure I have the latest and greatest.  Screwed around with this a while last night, and michelem, been doing a good share of mining under your name!  Like everything I restarted the box!! 

mmm, wrong permission on file?

I had the same issue.  I ended up having to edit the config file to delete the default pool.

I managed to partially fix the issue by changing the hub. Apparently there is something wrong with this brand new one I was using 

But I appreciate your suggestion and I’ll give it a try.

Cheers