[GUIDE] GridSeed 5-Chip USB, Blade & Black Miner Support/Tuning

[sandor111]

I'm using cpuminer v1.0a under Ubuntu 12.10. I've got the minerd application set to load via rc.local as part of a Minera installation.

I've got a problem after a reboot where minerd goes into a weird state where it doesn't hash anything. When I grab the stats with a python script I wrote, I see the following weirdness:

Code:

{
    "start_time": 1399756136, 
    "err": 0, 
    "devices": {
        "ttyACM1": {
            "serial": "6D89577A4857", 
            "chips": []
        }, 
        "ttyACM0": {
            "serial": "6D8A21A34857", 
            "chips": []
        }, 
        "ttyACM2": {
            "serial": "6D8E40854857", 
            "chips": []
        }
    }
}

If I manually stop and start minerd, it starts working. But that kind of the defeats the purpose of the auto restart feature.

Any ideas what might cause this? Maybe minerd is being launched too early, where certain system resources are not yet available?

I posted this in the Minera thread, but it seems like this is an issue with cpuminer being started under rc.local.

It's probably being started to early, when the filesystem and networking aren't fully initialized yet. One solution would be to add a sleep 30.

[alienesb]

Is there a Windows version of 1b compiled somewhere?

https://github.com/siklon/cpuminer-gc3355/

That's not windows ready though right? I'd have to compile it myself from the binary which I'm not so keen on doing if it's been done already. The reason I need this is because I'm getting the 10 minute no-hash thing going where it just keeps getting new work_id but not submitting. I have the reset going but that takes awhile to ramp up to full speed and it happens way to often.

[fivejonnyfive]

The first is the effective hashrate (pool hashrate), the second is the current hashrate. The first will tend to get closer to the second over time.

Ahh I was wondering about that myself. Thanks!

[edonkey]

It's probably being started to early, when the filesystem and networking aren't fully initialized yet. One solution would be to add a sleep 30.

Thanks for getting back to me. I guess I can change rc.local to call a script that either implements a delay or calls something that waits for resources to be available.

[KryptoKings]

is there a special way to kill the fan? can i just cut the wire?

[wax7]

Newer Use the Blade without working Fan!
But the noise goes safe down then inserting 1 or 2 Diode's. Dont do it if you doent know wath i mean!

[michelem]

I'm using cpuminer v1.0a under Ubuntu 12.10. I've got the minerd application set to load via rc.local as part of a Minera installation.

I've got a problem after a reboot where minerd goes into a weird state where it doesn't hash anything. When I grab the stats with a python script I wrote, I see the following weirdness:

Code:

{
    "start_time": 1399756136, 
    "err": 0, 
    "devices": {
        "ttyACM1": {
            "serial": "6D89577A4857", 
            "chips": []
        }, 
        "ttyACM0": {
            "serial": "6D8A21A34857", 
            "chips": []
        }, 
        "ttyACM2": {
            "serial": "6D8E40854857", 
            "chips": []
        }
    }
}

If I manually stop and start minerd, it starts working. But that kind of the defeats the purpose of the auto restart feature.

Any ideas what might cause this? Maybe minerd is being launched too early, where certain system resources are not yet available?

I posted this in the Minera thread, but it seems like this is an issue with cpuminer being started under rc.local.

It's probably being started to early, when the filesystem and networking aren't fully initialized yet. One solution would be to add a sleep 30.

Yes it's sure that, wait until I release the new start/stop agent on Minera so we can say goodbye to rc.local

In the meantime, you can add a sleep line as suggested (I think 10 is sufficient but best if you try).

Remember that Minera overwrites rc.local every time you save the settings, so you should save your optimal settings, change the rc.local adding a sleep then don't touch the settings anymore or remember to re-add the sleep.

Only few days until I release the new start/stop agent.

[ryen123]

Is there a Windows version of 1b compiled somewhere?

https://github.com/siklon/cpuminer-gc3355/

That's not windows ready though right? I'd have to compile it myself from the binary which I'm not so keen on doing if it's been done already. The reason I need this is because I'm getting the 10 minute no-hash thing going where it just keeps getting new work_id but not submitting. I have the reset going but that takes awhile to ramp up to full speed and it happens way to often.

Scroll to bottom of page, under binaries.

[alienesb]

Is there a Windows version of 1b compiled somewhere?

https://github.com/siklon/cpuminer-gc3355/

That's not windows ready though right? I'd have to compile it myself from the binary which I'm not so keen on doing if it's been done already. The reason I need this is because I'm getting the 10 minute no-hash thing going where it just keeps getting new work_id but not submitting. I have the reset going but that takes awhile to ramp up to full speed and it happens way to often.

Scroll to bottom of page, under binaries.

Thanks.

[KryptoKings]

Newer Use the Blade without working Fan!
But the noise goes safe down then inserting 1 or 2 Diode's. Dont do it if you doent know wath i mean!

I mean on the little 5 chips. Blades are not as noise.

[alienesb]

OK, latest version working now but I still get stuck with the new job_id and work_id stalls stacking up and then the miner is eventually reset (I have it set at 120.) What's going on?

[dk32167]

Hi all,

I have 10 x 5-chip Gridseed DualMiner and wiibox controller.

If I use cgminer on ubuntu miners are working fine, but due to some problems I can't use my PC anymore and need to setup the controller.

I follow the instuction - connect controller to usb-hub, power up hub and miners, connect ethernet and power up the controller. then I go to wiibox.net and try to set up my controller. the status of controller is "conn broken" I can't see any miners connected, etc.:
http://i57.tinypic.com/35b5d2a.png

does anyone have the same problem?

thank you

[Kokok]

is there a special way to kill the fan? can i just cut the wire?

I have cut the wire at the board, for all 9 of my GRIDSEEDs without any issues. I still have a small fan blowing on all of them and my Raspberry PI, to keep things chilly.

[sandor111]

I upgraded to 1.0b for CPUMiner and am experiencing a weird issue, not sure if anyone else is seeing this.

When running, I'll experience the occasional New job > Chips reset > Chips get new work and everything continues to process like awesomeness.  Everything is running very stable and all blades are averaging over 2.8MH per side, so I'm a happy camper.  But this morning I noticed a slight down-tick from my pool average so I went to investigate.

Long story short, every time one of these work resets happens I get a kworker.  They're matched to the usb locations of blade halves, so eventually I'll have kworker/0:2, kworker/0:0, etc., littering my processes.  And bogging down my RPi.  While doing this research and at some point after it hit eight kworkers (for the 4 blades on this pi) the cpuminer instance stopped reporting work, verified poolside.  So I killed my processes and went about restarting my mining loop and CPUminer just hung with no output.  Looked and sure enough all eight kworker instances were there, however I cannot 'kill' them whatsoever, even prevented a reboot from the command line.  Cold-rebooting my system cleared everything as expected, but now I'm running again and noticing the kworkers.  

I started the process when I began writing this post, right now I've got three kworkers going.  Will update if this keeps up, but may downgrade back to .9e (last place my blades lived happily without hassle).  Anyone else seeing this?

Edit: Since I'm now monitoring for this, just noticed I went from kworker/0:2, 0:0, 0:1 to just kworker/0:2,0:0 over the course of a few minutes.  So I'm not sure if these are processing that aren't terminating correctly or if there *should* be a kworker(s) sitting there threading out the work.

OK, latest version working now but I still get stuck with the new job_id and work_id stalls stacking up and then the miner is eventually reset (I have it set at 120.) What's going on?

It would be worth checking the latest commit, it will set a global frequency if there is no specific chip frequency set. Try to run your Blades on one frequency. The Blades might not like if the frequency isn't set uniformly.

[reactor]

I upgraded to 1.0b for CPUMiner and am experiencing a weird issue, not sure if anyone else is seeing this.

When running, I'll experience the occasional New job > Chips reset > Chips get new work and everything continues to process like awesomeness.  Everything is running very stable and all blades are averaging over 2.8MH per side, so I'm a happy camper.  But this morning I noticed a slight down-tick from my pool average so I went to investigate.

Long story short, every time one of these work resets happens I get a kworker.  They're matched to the usb locations of blade halves, so eventually I'll have kworker/0:2, kworker/0:0, etc., littering my processes.  And bogging down my RPi.  While doing this research and at some point after it hit eight kworkers (for the 4 blades on this pi) the cpuminer instance stopped reporting work, verified poolside.  So I killed my processes and went about restarting my mining loop and CPUminer just hung with no output.  Looked and sure enough all eight kworker instances were there, however I cannot 'kill' them whatsoever, even prevented a reboot from the command line.  Cold-rebooting my system cleared everything as expected, but now I'm running again and noticing the kworkers.  

I started the process when I began writing this post, right now I've got three kworkers going.  Will update if this keeps up, but may downgrade back to .9e (last place my blades lived happily without hassle).  Anyone else seeing this?

Edit: Since I'm now monitoring for this, just noticed I went from kworker/0:2, 0:0, 0:1 to just kworker/0:2,0:0 over the course of a few minutes.  So I'm not sure if these are processing that aren't terminating correctly or if there *should* be a kworker(s) sitting there threading out the work.

OK, latest version working now but I still get stuck with the new job_id and work_id stalls stacking up and then the miner is eventually reset (I have it set at 120.) What's going on?

It would be worth checking the latest commit, it will set a global frequency if there is no specific chip frequency set. Try to run your Blades on one frequency. The Blades might not like if the frequency isn't set uniformly.

Out of curiosity, I'm running 1.0b for blades @ 838 and 5chips running on another instance (one of the .9s, g maybe?), would this have any impact?

[sandor111]

I upgraded to 1.0b for CPUMiner and am experiencing a weird issue, not sure if anyone else is seeing this.

When running, I'll experience the occasional New job > Chips reset > Chips get new work and everything continues to process like awesomeness.  Everything is running very stable and all blades are averaging over 2.8MH per side, so I'm a happy camper.  But this morning I noticed a slight down-tick from my pool average so I went to investigate.

Long story short, every time one of these work resets happens I get a kworker.  They're matched to the usb locations of blade halves, so eventually I'll have kworker/0:2, kworker/0:0, etc., littering my processes.  And bogging down my RPi.  While doing this research and at some point after it hit eight kworkers (for the 4 blades on this pi) the cpuminer instance stopped reporting work, verified poolside.  So I killed my processes and went about restarting my mining loop and CPUminer just hung with no output.  Looked and sure enough all eight kworker instances were there, however I cannot 'kill' them whatsoever, even prevented a reboot from the command line.  Cold-rebooting my system cleared everything as expected, but now I'm running again and noticing the kworkers.  

I started the process when I began writing this post, right now I've got three kworkers going.  Will update if this keeps up, but may downgrade back to .9e (last place my blades lived happily without hassle).  Anyone else seeing this?

Edit: Since I'm now monitoring for this, just noticed I went from kworker/0:2, 0:0, 0:1 to just kworker/0:2,0:0 over the course of a few minutes.  So I'm not sure if these are processing that aren't terminating correctly or if there *should* be a kworker(s) sitting there threading out the work.

OK, latest version working now but I still get stuck with the new job_id and work_id stalls stacking up and then the miner is eventually reset (I have it set at 120.) What's going on?

It would be worth checking the latest commit, it will set a global frequency if there is no specific chip frequency set. Try to run your Blades on one frequency. The Blades might not like if the frequency isn't set uniformly.

Out of curiosity, I'm running 1.0b for blades @ 838 and 5chips running on another instance (one of the .9s, g maybe?), would this have any impact?

It's fine.

[dk32167]

Hi all,

I have 10 x 5-chip Gridseed DualMiner and wiibox controller.

If I use cgminer on ubuntu miners are working fine, but due to some problems I can't use my PC anymore and need to setup the controller.

I follow the instuction - connect controller to usb-hub, power up hub and miners, connect ethernet and power up the controller. then I go to wiibox.net and try to set up my controller. the status of controller is "conn broken" I can't see any miners connected, etc.:
http://i57.tinypic.com/35b5d2a.png

does anyone have the same problem?

thank you

any answers?

[dishwara]

Hi all,

I have 10 x 5-chip Gridseed DualMiner and wiibox controller.

If I use cgminer on ubuntu miners are working fine, but due to some problems I can't use my PC anymore and need to setup the controller.

I follow the instuction - connect controller to usb-hub, power up hub and miners, connect ethernet and power up the controller. then I go to wiibox.net and try to set up my controller. the status of controller is "conn broken" I can't see any miners connected, etc.:


does anyone have the same problem?

thank you

any answers?

It seems its not connected to internet or local network.
Local IP : not acquire meaning no connection.
Check ethernet cable & connect it to router.

[dk32167]

It seems its not connected to internet or local network.
Local IP : not acquire meaning no connection.
Check ethernet cable & connect it to router.

it is, I found the device and bound it to my account in the moment before this screenshot.
Moreover, I can login to the control panel via web 192.168.1.X

[cmilian]

Guys I am running 6 Gridseeds, 5 of the Volt OC, however, the strangest this is happening, they all run fine, but periodically they ALL have a chain of nonce errors at the same time. Then they go back to normal and so on. Both OC and non Volt OC get the errors at the same time.

Any ideas on where to start looking?