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

[wolfey2014]

Sandor, I'm running 0.09f and it's causing my workers to get banned from the same pool I've been mining for days without issues using 2.3.2 .... it says the reason for it is 'worker invalid percent: 100 xxx.xxx STILL BANNED!
Damn! Banned again!  
The dev says it is definitely being caused by my mining program...
What can I do to cure this short of reverting back to 2.3.2 again and waiting for this all to be debugged and stable?
HELP!

Edit: pool also reports that my miners are submitting 'invalid job not founds'
your program is still submitting shares for a job already done...

Edit deux! - now it's submitting valid shares again. I did nothing. It just like, fixed itself and got itself unbanned and shares accepted....
dev says that its a known issue with bfgminer and some cpuminers ,, doesn't update jobs fast enough or something...

Sandor, its rejecting again... "reject reason job 1215 not found"- and it keeps repeating this over and over....
whats the bug?
Can you correct this in ver 0.09i ?

Love the TUI etc, HATE the bugs!

[CartmanSPC]

Is this True?
https://www.youtube.com/watch?v=CjTcdhzfKIc

Can scrypt miners be that fast !?

Yes it's real...but I would skip it. They want too much for it ($10k) and for that cost you will soon have 300Mh+

[kskwerl]

I have 16 Gridseed blades and they restart quiet frequently how does everything look to you guys?

http://imgur.com/SePdnpg

I'm using this controller

http://www.gawminers.com/gaw-miners-server-mining-controller/

[CartmanSPC]

Can you try the latest commit, I think I just fixed that.

Yes, works now. Major props!

[RowanX]

Latest build of 0.9g instantly crashes on me (Win 8.1). Build from a few hours ago works unless I specify 2 pools, or use the --no-refresh switch, in which instance it also instantly crashes.

[CartmanSPC]

Just for comparison here are the freq's on my stock (non-moded) 5 chippers are pulling with close to 0 HW errors:



Is it okay to run with --debug on or is that only recommended when dialing in your settings? I'm running on a core i7 so CPU is not an issue.

Also, I really like how dtbartle cgminer does per_chip_stats=1. I realize that's hard with the blades but would be nice to see at least for the 5 chip miners.

[nst6563]

I came across an old phone and had this crazy off the wall idea....has anyone thought of using an older android phone running Ubuntu to control miners?  Could utilize USB OTG to connect a hub and go from there.  Just a thought...might be more powerful than a raspberry pi....and for those of us with old phones laying around it could provide a useful re-purpose of tech.

[Mr. Jinx]

cpuminer-gc3355 v0.9g

* Failover pool strategy is supported
* Low reject rate (--no-refresh -> disabled)

Great work sandor111!
Is there also an update for the lightningasic controller firmware?

[RowanX]

Latest build of 0.9g instantly crashes on me (Win 8.1). Build from a few hours ago works unless I specify 2 pools, or use the --no-refresh switch, in which instance it also instantly crashes.

That being said, it (the previous build of 0.9g) is the first version since 0.9c that is giving me a nice low amount of rejects (0.5%). During the last 10 hours:

A:5826  R:29  HW: 2 (var diff ~64)

[sandor111]

Latest build of 0.9g instantly crashes on me (Win 8.1). Build from a few hours ago works unless I specify 2 pools, or use the --no-refresh switch, in which instance it also instantly crashes.

That being said, it (the previous build of 0.9g) is the first version since 0.9c that is giving me a nice low amount of rejects (0.5%). During the last 10 hours:

A:5826  R:29  HW: 2 (var diff ~64)

Keep an eye on the dropbox links, the binaries are updated once in a while. Should work without any crashes now.

[RowanX]

Latest build of 0.9g instantly crashes on me (Win 8.1). Build from a few hours ago works unless I specify 2 pools, or use the --no-refresh switch, in which instance it also instantly crashes.

That being said, it (the previous build of 0.9g) is the first version since 0.9c that is giving me a nice low amount of rejects (0.5%). During the last 10 hours:

A:5826  R:29  HW: 2 (var diff ~64)

Keep an eye on the dropbox links, the binaries are updated once in a while. Should work without any crashes now.

As of now the link on your dropbox is saying its 11hours old. I think thats the one I'm already using but updated again just to be sure. Still crashing unfortunately.

Screenshot: http://i.snag.gy/lkQ54.jpg

Crash info from Windows:

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name:   minerd-gc3355.exe
  Application Version:   0.0.0.0
  Application Timestamp:   536c1f0e
  Fault Module Name:   minerd-gc3355.exe
  Fault Module Version:   0.0.0.0
  Fault Module Timestamp:   536c1f0e
  Exception Code:   c0000005
  Exception Offset:   00004054
  OS Version:   6.3.9600.2.0.0.256.48
  Locale ID:   2057
  Additional Information 1:   5861
  Additional Information 2:   5861822e1919d7c014bbb064c64908b2
  Additional Information 3:   d1d9
  Additional Information 4:   d1d94a13d3609d6b740644c12508f581

EDIT: Oh sorry, you are saying just keep an eye on the dropbox links, i.e. the next compile shouldn't crash?

[sandor111]

Latest build of 0.9g instantly crashes on me (Win 8.1). Build from a few hours ago works unless I specify 2 pools, or use the --no-refresh switch, in which instance it also instantly crashes.

That being said, it (the previous build of 0.9g) is the first version since 0.9c that is giving me a nice low amount of rejects (0.5%). During the last 10 hours:

A:5826  R:29  HW: 2 (var diff ~64)

Keep an eye on the dropbox links, the binaries are updated once in a while. Should work without any crashes now.

As of now the link on your dropbox is saying its 11hours old. I think thats the one I'm already using but updated again just to be sure. Still crashing unfortunately.

Screenshot: http://i.snag.gy/lkQ54.jpg

Crash info from Windows:

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name:   minerd-gc3355.exe
  Application Version:   0.0.0.0
  Application Timestamp:   536c1f0e
  Fault Module Name:   minerd-gc3355.exe
  Fault Module Version:   0.0.0.0
  Fault Module Timestamp:   536c1f0e
  Exception Code:   c0000005
  Exception Offset:   00004054
  OS Version:   6.3.9600.2.0.0.256.48
  Locale ID:   2057
  Additional Information 1:   5861
  Additional Information 2:   5861822e1919d7c014bbb064c64908b2
  Additional Information 3:   d1d9
  Additional Information 4:   d1d94a13d3609d6b740644c12508f581

EDIT: Oh sorry, you are saying just keep an eye on the dropbox links, i.e. the next compile shouldn't crash?

The latest build on dropbox (13h ago) should not crash. What is your cpuminer command line?

[RowanX]

Latest build of 0.9g instantly crashes on me (Win 8.1). Build from a few hours ago works unless I specify 2 pools, or use the --no-refresh switch, in which instance it also instantly crashes.

That being said, it (the previous build of 0.9g) is the first version since 0.9c that is giving me a nice low amount of rejects (0.5%). During the last 10 hours:

A:5826  R:29  HW: 2 (var diff ~64)

Keep an eye on the dropbox links, the binaries are updated once in a while. Should work without any crashes now.

As of now the link on your dropbox is saying its 11hours old. I think thats the one I'm already using but updated again just to be sure. Still crashing unfortunately.

Screenshot: http://i.snag.gy/lkQ54.jpg

Crash info from Windows:

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name:   minerd-gc3355.exe
  Application Version:   0.0.0.0
  Application Timestamp:   536c1f0e
  Fault Module Name:   minerd-gc3355.exe
  Fault Module Version:   0.0.0.0
  Fault Module Timestamp:   536c1f0e
  Exception Code:   c0000005
  Exception Offset:   00004054
  OS Version:   6.3.9600.2.0.0.256.48
  Locale ID:   2057
  Additional Information 1:   5861
  Additional Information 2:   5861822e1919d7c014bbb064c64908b2
  Additional Information 3:   d1d9
  Additional Information 4:   d1d94a13d3609d6b740644c12508f581

EDIT: Oh sorry, you are saying just keep an eye on the dropbox links, i.e. the next compile shouldn't crash?

The latest build on dropbox (13h ago) should not crash. What is your cpuminer command line?

It works OK when I remove this part from my bat file:

--gc3355-freq=\\.\COM1:875,\\.\COM1:850:2,\\.\COM2:850:0,\\.\COM2:850:1,\\.\COM2:825:2,\\.\COM2:875:3,\\.\COM2:850:4,

Is there a problem with that syntax? 0.9c does not have a problem with it.

[sandor111]

Latest build of 0.9g instantly crashes on me (Win 8.1). Build from a few hours ago works unless I specify 2 pools, or use the --no-refresh switch, in which instance it also instantly crashes.

That being said, it (the previous build of 0.9g) is the first version since 0.9c that is giving me a nice low amount of rejects (0.5%). During the last 10 hours:

A:5826  R:29  HW: 2 (var diff ~64)

Keep an eye on the dropbox links, the binaries are updated once in a while. Should work without any crashes now.

As of now the link on your dropbox is saying its 11hours old. I think thats the one I'm already using but updated again just to be sure. Still crashing unfortunately.

Screenshot: http://i.snag.gy/lkQ54.jpg

Crash info from Windows:

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name:   minerd-gc3355.exe
  Application Version:   0.0.0.0
  Application Timestamp:   536c1f0e
  Fault Module Name:   minerd-gc3355.exe
  Fault Module Version:   0.0.0.0
  Fault Module Timestamp:   536c1f0e
  Exception Code:   c0000005
  Exception Offset:   00004054
  OS Version:   6.3.9600.2.0.0.256.48
  Locale ID:   2057
  Additional Information 1:   5861
  Additional Information 2:   5861822e1919d7c014bbb064c64908b2
  Additional Information 3:   d1d9
  Additional Information 4:   d1d94a13d3609d6b740644c12508f581

EDIT: Oh sorry, you are saying just keep an eye on the dropbox links, i.e. the next compile shouldn't crash?

The latest build on dropbox (13h ago) should not crash. What is your cpuminer command line?

It works OK when I remove this part from my bat file:

--gc3355-freq=\\.\COM1:875,\\.\COM1:850:2,\\.\COM2:850:0,\\.\COM2:850:1,\\.\COM2:825:2,\\.\COM2:875:3,\\.\COM2:850:4,

Is there a problem with that syntax? 0.9c does not have a problem with it.

Thanks, found it, fixed it and updated the binary.
Finally we have a stable release.

[RowanX]

Nice one Sandor, no more crash here.

     v1.0a 

[reactor]

Latest build of 0.9g instantly crashes on me (Win 8.1). Build from a few hours ago works unless I specify 2 pools, or use the --no-refresh switch, in which instance it also instantly crashes.

That being said, it (the previous build of 0.9g) is the first version since 0.9c that is giving me a nice low amount of rejects (0.5%). During the last 10 hours:

A:5826  R:29  HW: 2 (var diff ~64)

Keep an eye on the dropbox links, the binaries are updated once in a while. Should work without any crashes now.

As of now the link on your dropbox is saying its 11hours old. I think thats the one I'm already using but updated again just to be sure. Still crashing unfortunately.

Screenshot: http://i.snag.gy/lkQ54.jpg

Crash info from Windows:

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name:   minerd-gc3355.exe
  Application Version:   0.0.0.0
  Application Timestamp:   536c1f0e
  Fault Module Name:   minerd-gc3355.exe
  Fault Module Version:   0.0.0.0
  Fault Module Timestamp:   536c1f0e
  Exception Code:   c0000005
  Exception Offset:   00004054
  OS Version:   6.3.9600.2.0.0.256.48
  Locale ID:   2057
  Additional Information 1:   5861
  Additional Information 2:   5861822e1919d7c014bbb064c64908b2
  Additional Information 3:   d1d9
  Additional Information 4:   d1d94a13d3609d6b740644c12508f581

EDIT: Oh sorry, you are saying just keep an eye on the dropbox links, i.e. the next compile shouldn't crash?

The latest build on dropbox (13h ago) should not crash. What is your cpuminer command line?

It works OK when I remove this part from my bat file:

--gc3355-freq=\\.\COM1:875,\\.\COM1:850:2,\\.\COM2:850:0,\\.\COM2:850:1,\\.\COM2:825:2,\\.\COM2:875:3,\\.\COM2:850:4,

Is there a problem with that syntax? 0.9c does not have a problem with it.

Thanks, found it, fixed it and updated the binary.
Finally we have a stable release.

Awesome, was having this problem with per-miner or per-chip frequency last night but thought it was just me missing a typo somewhere, will try upgrading my rig today when the next two blades arrive to the latest to confirm it's all working.

Also, found the older issue with the chips seeming to hang, apparently the process was not fully dying when killed.  Went through and force-killed a few minerd processes and everything in the live screens came back to normal speed quickly thereafter, all blades have been running at a consistent 5.6M since then @ 838 freq.  And that 838 is freaking magic, took one blade half which had approx 10% hw rate and dropped my overall R/HW to about 1.5%.

[Mr. Jinx]

cpuminer-gc3355 v0.9g

* Failover pool strategy is supported
* Low reject rate (--no-refresh -> disabled)

Great work sandor111!
Will there also be an update for the lightningasic controller firmware?

[RowanX]

I'm actually having the same old problem with 1.0a: too many rejects (compared to 0.9c). Setting --no-refresh seems to make it worse (A:241 R:20 H:0 in 20mins).

[sandor111]

I'm actually having the same old problem with 1.0a: too many rejects (compared to 0.9c). Setting --no-refresh seems to make it worse (will keep running for a while longer to confirm this).

Don't use --no-refresh if you are having issues with rejects, it does make it worse as it only sends new work when a new block is detected, as opposed to always sending new work to the GC3355.
It's a command line option specifically for the Blade users.

[RowanX]

I'm actually having the same old problem with 1.0a: too many rejects (compared to 0.9c). Setting --no-refresh seems to make it worse (will keep running for a while longer to confirm this).

Don't use --no-refresh if you are having issues with rejects, it does make it worse as it only sends new work when a new block is detected, as opposed to always sending new work to the GC3355.
It's a command line option specifically for the Blade users.

OK. I've switched to another pool (ghash) and cpuminer is not giving high rejects. But, difficulty stays @ 16, which is lower than I'm used to seeing - is that anything to worry about? More traffic? (noob questions I know)

I know the admins @ GiveMeCoins tested cpuminer with their pool but I don't think they tried the Windows builds, FWIW.