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

Quote from: sandor111 on May 09, 2014, 10:55:53 AM

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.

That's no issue, the bandwidth consumed when mining is relatively low.
BTW, there is no difference between Windows build or the others. I still stand by that it's a pool issue, because I'm getting 0.2-1% reject rate on any pool I tested except that one.

nice to meet u~ greater writer . i have tow pis usbminiminer and one blade , i can run it use the v1.0a together? thx .

Sure, you can use it together.

chinatom

member

Activity: 71

Merit: 10

Quote from: sandor111 on May 09, 2014, 10:55:53 AM

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.

That's no issue, the bandwidth consumed when mining is relatively low.
BTW, there is no difference between Windows build or the others. I still stand by that it's a pool issue, because I'm getting 0.2-1% reject rate on any pool I tested except that one.

nice to meet u~ greater writer . i have tow pis usbminiminer and one blade , i can run it use the v1.0a together? thx .

RowanX

member

Activity: 86

Merit: 10

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.

That's no issue, the bandwidth consumed when mining is relatively low.
BTW, there is no difference between Windows build or the others. I still stand by that it's a pool issue, because I'm getting 0.2-1% reject rate on any pool I tested except that one.

Sure I see what you mean. Its just curious that 0.9c works fine with GiveMeCoins pool.

sandor111

hero member

Activity: 616

Merit: 500

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.

That's no issue, the bandwidth consumed when mining is relatively low.
BTW, there is no difference between Windows build or the others. I still stand by that it's a pool issue, because I'm getting 0.2-1% reject rate on any pool I tested except that one.

RowanX

member

Activity: 86

Merit: 10

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.

sandor111

hero member

Activity: 616

Merit: 500

Quote from: sandor111 on May 08, 2014, 04:01:25 PM

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

member

Activity: 86

Merit: 10

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).

Mr. Jinx

member

Activity: 112

Merit: 10

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?

reactor

sr. member

Activity: 420

Merit: 250

Quote from: sandor111 on May 09, 2014, 08:28:53 AM

Quote from: RowanX on May 09, 2014, 08:08:12 AM

Quote from: sandor111 on May 09, 2014, 08:05:20 AM

Quote from: RowanX on May 09, 2014, 08:08:12 AM

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:

Quote

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%.

RowanX

member

Activity: 86

Merit: 10

Nice one Sandor, no more crash here.

Kiss

v1.0a

sandor111

hero member

Activity: 616

Merit: 500

Quote from: sandor111 on May 09, 2014, 08:05:20 AM

Quote from: sandor111 on May 09, 2014, 08:05:20 AM

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:

Quote

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

member

Activity: 86

Merit: 10

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:

Quote

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

hero member

Activity: 616

Merit: 500

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:

Quote

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

member

Activity: 86

Merit: 10

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:

Quote

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

hero member

Activity: 616

Merit: 500

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

member

Activity: 86

Merit: 10