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

ManeBjorn

legendary

Activity: 1288

Merit: 1004

You will want to use a separate instance of cpuminer to run your Blade. A Blade uses roughly 150 watts so you will need a PSU that can deliver that.
Is your Blade coming with power cables?
I suggest the heavy PCIe cables made by Cabez for the Blade.
They are simple and easy to run.
Here is a sample argument that I use. 838 seems to be the sweetspot frequency for the Blades.

Code:

minerd.exe --freq=838 --debug --gc3355=\\.\COM6,\\.\COM7 --gc3355-chips=40 --url=poolandporthere --userpass=usernamehere:passwordhere

pause

This is to run the two Blades I have. Make sure you pay attention to which COM ports it installs on. Then put your COMs in there.
Then everything should run well.
Here is my review on the Blades.
http://www.cryptocoinsnews.com/news/5-2-mhs-scrypt-miner-review-gridseed-blade/2014/05/08
I hope this helps.
Happy Mining.

Quote from: philipma1957 on May 16, 2014, 10:15:29 PM

I have a blade on the way. dhl should have it to me by monday or tues.

While I run the 5 chip units as many as 30 using cpuminer at freq 850 I can not seem to find a thread just for the blades…

What power supply? can I set it up with my 5 chip gridseeds using a com port and freq 850 on the same fork of cpuminer?

Is there a blade setup thread? I just spent 30 minutes reading this thread and can't seem to see simple setup for the blades.

philipma1957

legendary

Activity: 4326

Merit: 8950

'The right to privacy matters'

I have a blade on the way. dhl should have it to me by monday or tues.

While I run the 5 chip units as many as 30 using cpuminer at freq 850 I can not seem to find a thread just for the blades…

What power supply? can I set it up with my 5 chip gridseeds using a com port and freq 850 on the same fork of cpuminer?

Is there a blade setup thread? I just spent 30 minutes reading this thread and can't seem to see simple setup for the blades.

okay I found some info on gawminers.

http://www.gawminers.com/blog/gridseed-blade-miner-setup-guide/

they say use the same driver

http://www.st.com/web/en/catalog/tools/PF257938

but they say use

3.7.2 cgminer

http://cryptomining-blog.com/1990-updated-cgminer-3-7-2-with-support-for-gridseed-5-chip-and-80-chip-gc3355-asics/

I was using this for my five chip gridseeds

cpuminer

http://cryptomining-blog.com/1828-updated-cgminer-3-7-2-and-cpuminer-for-overclocking-gridseed-5-chip-gc3355-asics/

does the blade not work with cpuminer?

wolfey2014

sr. member

Activity: 378

Merit: 250

Can anyone who knows what their doing help me out here?
I'm still fairly green where commands go.

In cpuminer 1.0b, I see the command for setting each pod to it's own fixed frequency but I don't understand what DEV and F or n stand for or how to alter the command line.
-f, --gc3355-freq=DEV0:F0,DEV1:F1,...,DEVn:Fn

How do I write it into the string? Or, what do I change the string to?

Here's an example of the current command line I'm using:

minerdoc --freq=1175 --gc3355=\\.\com2,\\.\com4,\\.\com5,\\.\com6 --gc3355-autotune --url=stratum+tcp://xxxxx.com:3488 --userpass=xxxx.x:xxxx

It sets the whole smashes freq to 1175 then sets about auto tuning.

So how do I change the string to run individual frequencies for each pod? Not each chip but each 5 chip pod.
I don't understand what -f is saying.

Thanks!

cmilian

member

Activity: 93

Merit: 10

Thanks!

Did not do the Fan Mod. Just moved some to another USB hub to check.

wolfey2014

sr. member

Activity: 378

Merit: 250

Quote from: cmilian on May 16, 2014, 12:04:00 PM

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?

Have you checked the volt mod thread? There may be some answers there.
Did you perform the 5V USB fan mod as well?
Is your USB power supply still adequate to handle the load?
How about your main 12V power supply? Still adequate?

Any other programs running simultaneously on your PC that are communicating via the net at the same time?

I've recently quit running any wallets, especially the ones that are mining, at the same time because they were interfering with send receive comms' of cpuminer.

Just some ideas.
Hope they help.
Good luck!

cmilian

member

Activity: 93

Merit: 10

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?

dk32167

newbie

Activity: 3

Merit: 0

Quote from: dishwara on May 16, 2014, 09:05:59 AM

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

dishwara

legendary

Activity: 1855

Merit: 1016

Quote from: dk32167 on May 16, 2014, 05:26:36 AM

Quote from: dk32167 on May 15, 2014, 12:42:32 PM

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

newbie

Activity: 3

Merit: 0

Quote from: dk32167 on May 15, 2014, 12:42:32 PM

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?

sandor111

hero member

Activity: 616

Merit: 500

Quote from: reactor on May 15, 2014, 01:39:40 PM

Quote from: sandor111 on May 15, 2014, 01:37:21 PM

Quote from: reactor on May 15, 2014, 08:12:32 AM

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.

Quote from: alienesb on May 15, 2014, 11:25:35 AM

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.

reactor

sr. member

Activity: 420

Merit: 250

Quote from: sandor111 on May 15, 2014, 01:37:21 PM

Quote from: reactor on May 15, 2014, 08:12:32 AM

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.

Quote from: alienesb on May 15, 2014, 11:25:35 AM

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

hero member

Activity: 616

Merit: 500

Quote from: reactor on May 15, 2014, 08:12:32 AM

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.

Quote from: alienesb on May 15, 2014, 11:25:35 AM

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.

Kokok

newbie

Activity: 54

Merit: 0

Quote from: KryptoKings on May 15, 2014, 09:51:32 AM

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.

dk32167

newbie

Activity: 3

Merit: 0

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

alienesb

hero member

Activity: 868

Merit: 1000

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?

KryptoKings

hero member

Activity: 854

Merit: 506

Quote from: wax7 on May 15, 2014, 10:24:04 AM

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

hero member

Activity: 868

Merit: 1000

Quote from: ryen123 on May 15, 2014, 10:34:38 AM

Quote from: alienesb on May 15, 2014, 09:38:28 AM

Quote from: plzt on May 14, 2014, 05:57:42 PM

Quote from: alienesb on May 14, 2014, 05:28:56 PM

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.

ryen123

sr. member

Activity: 292

Merit: 250

Quote from: alienesb on May 15, 2014, 09:38:28 AM

Quote from: plzt on May 14, 2014, 05:57:42 PM

Quote from: alienesb on May 14, 2014, 05:28:56 PM

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.

michelem

legendary

Activity: 1015

Merit: 1000

Quote from: sandor111 on May 15, 2014, 09:14:57 AM

Quote from: edonkey on May 15, 2014, 09:04:47 AM

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 Wink

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.

wax7

member

Activity: 93

Merit: 10

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!

Topic: [GUIDE] GridSeed 5-Chip USB, Blade & Black Miner Support/Tuning - page 11. (Read 308847 times)