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

[sandor111]

That's quite a statement. Pool runs fine for everyone else and the conclusion is that we don't report new blocks on the network...  

The pool doesn't report new blocks at all (WTF?), so of course cpuminer sticks with the old work. I would suggest that you try a different pool.

When I run with 0.9c I do get "Stratum detected new block" messages in the log, if that is what you mean (same pool).

Are you sure? The code regarding "Stratum detected new block" message hasn't changed.
When the pool detects a new block, stratum.job.clean is set to true.
https://github.com/siklon/cpuminer-gc3355/commit/d07b9abe2f3fbd0f530f2e6d5af54449f87c2d78

I don't mean no disrespect, but this my conclusion based on what I see from the stratum logs. 1 hour passed and no new block reported from stratum server, meanwhile there are tons of rejects like "unknown-work" each time a new job is issued and the GC3355 is still solving the previous job. It's only logical that the pool discards the old jobs when a new block is detected, so unless the stratum protocol changed, this is a failure from the pool.

How it should look:

[RowanX]

Are you sure? The code regarding "Stratum detected new block" message hasn't changed.
When the pool detects a new block, stratum.job.clean is set to true.
https://github.com/siklon/cpuminer-gc3355/commit/d07b9abe2f3fbd0f530f2e6d5af54449f87c2d78

I appreciate what you are saying but in answer to your question yes I am sure, here's a screenshot from 0.9c where the message "Stratum detected new block" can be seen:

http://i.snag.gy/jOzeL.jpg

[sandor111]

Are you sure? The code regarding "Stratum detected new block" message hasn't changed.
When the pool detects a new block, stratum.job.clean is set to true.
https://github.com/siklon/cpuminer-gc3355/commit/d07b9abe2f3fbd0f530f2e6d5af54449f87c2d78

I appreciate what you are saying but in answer to your question yes I am sure, here's a screenshot from 0.9c where the message "Stratum detected new block" can be seen:

http://i.snag.gy/jOzeL.jpg

I just tested the pool on v0.9d and it occasionally reports new blocks, so it's not related to cpuminer.

[kha0S]

Sorry if I sounded a bit harsh, but I'm actually mining using your software and I have no problems at all. I'm using this revision:

https://github.com/siklon/cpuminer-gc3355/tree/12b54ffff5dea7941fdf096bb66e2955b00f90b5

I did a quick diff with latest version and I can't find any change that might have break it.

I'm compiling now the latest version and will debug in both ends (miner and pool) to get some more info.

That's quite a statement. Pool runs fine for everyone else and the conclusion is that we don't report new blocks on the network...  

The pool doesn't report new blocks at all (WTF?), so of course cpuminer sticks with the old work. I would suggest that you try a different pool.

When I run with 0.9c I do get "Stratum detected new block" messages in the log, if that is what you mean (same pool).

Are you sure? The code regarding "Stratum detected new block" message hasn't changed.
When the pool detects a new block, stratum.job.clean is set to true.
https://github.com/siklon/cpuminer-gc3355/commit/d07b9abe2f3fbd0f530f2e6d5af54449f87c2d78

I don't mean no disrespect, but this my conclusion based on what I see from the stratum logs. 1 hour passed and no new block reported from stratum server, meanwhile there are tons of rejects like "unknown-work" each time a new job is issued and the GC3355 is still solving the previous job. It's only logical that the pool discards the old jobs when a new block is detected, so unless the stratum protocol changed, this is a failure from the pool.

How it should look:

[kha0S]

Testing with "old" version:

Pool requests job/work update
Pool logs:
2014-05-06 13:49:03,462   StratumServer   INFO   27311 clients to wake up...
2014-05-06 13:49:04,197   StratumServer   INFO   New job sent to 27311 clients in 0.734 seconds


Miner:
[2014-05-06 13:48:33.064] 0@2: accepted 8/8 (100.00%) 72.0/359.1/646.8 (Pool: 1090.5) KH/s
[2014-05-06 13:49:4.091] < {"params": ["1399384143 4224", "b46edf47912d75f69737cff24290e0c47fcb1afbf673a9de797c268912cc6737", "01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff2b03a594081e4d696e656420627920474956452d4d452d434f494e532e636f6d5368e84f", "ffffffff01104e122a010000001976a914de78b22dd28d8fbdef1183e39163e7def6a6289588ac0 0000000", ["4824993d9322847a1a4f11b20b57e62d9d16ead47281d9f844634025c59c92c2", "79778b4d1517c4b2e3f8258732a931d0204f7da7c5e940eb45216f5f4ddcee56", "4c5a7a7da57a18ee4e9668fa9e208279c2cbb21f0a388f19aab908169df26e5d", "97e8d3c27811cbda28ce58bacbc9b6a93b2ad3fe7ff421d137b78b0460abf57c", "63ffcc197be62f0c49fddfa686998a44539de726bf84cff4cb2554db878ecf38"], "00000002", "1b08ee37", "5368e84f", false], "method": "mining.notify", "id": null}
[2014-05-06 13:49:4.092] New job_id: 1399384143 4224 Diff: 192
[2014-05-06 13:49:4.092] Dispatching new work to GC3355 threads
[2014-05-06 13:49:28.195] 0@4 850MHz: Got nonce ad3be7cc, Hash <= Htarget!

Pool send new block/work notification

Pool logs:
2014-05-06 13:50:55,960   newBlockNotification   INFO   Received new block notification
2014-05-06 13:50:56,087   merkleMaker   INFO   New block: a9bc28c7f11ee507f8501bf943ccf269d1b299a780badadff3e153424c868ea4 (height: 562342; bits: 1b08ee37)
2014-05-06 13:50:56,095   StratumServer   INFO   27300 clients to wake up...
2014-05-06 13:50:56,096   JSONRPCServer   INFO   Nobody to longpoll
2014-05-06 13:50:56,187   BitcoinLink   DEBUG   Received block inv over p2p for a9bc28c7f11ee507f8501bf943ccf269d1b299a780badadff3e153424c868ea4
2014-05-06 13:50:58,390   StratumServer   INFO   New job sent to 27290 clients in 0.685 seconds

Miner:
[2014-05-06 13:50:58.303] < {"params": ["1399384257 4228", "4c868ea4f3e1534280badadfd1b299a743ccf269f8501bf9f11ee507a9bc28c7", "01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff2d03a69408204d696e656420627920474956452d4d452d434f494e532e636f6d5368e8c113d8 ", "ffffffff0100f2052a010000001976a914de78b22dd28d8fbdef1183e39163e7def6a6289588ac0 0000000", ["3bf39da2705661be6ed50a275c836320d6821fa8bff2a7bec95cffff16a41143"], "00000002", "1b08ee37", "5368e8c1", false], "method": "mining.notify", "id": null}
[2014-05-06 13:50:58.304] New job_id: 1399384257 4228 Diff: 224
[2014-05-06 13:50:58.304] Dispatching new work to GC3355 threads

Testing with "latest" version:

Pool requests job/work update
Pool logs:
2014-05-06 13:57:36,589   StratumServer   INFO   27338 clients to wake up...
2014-05-06 13:57:37,358   StratumServer   INFO   New job sent to 27338 clients in 0.769 seconds

Miner:
[2014-05-06 13:57:37] 0@3: ~3605 steps until frequency adjusts to 875MHz
[2014-05-06 13:57:37] > {"method": "mining.submit", "params": ["khaos.1", "1399384601 4236", "80000007", "5368ea19", "bcdf9f99"], "id":3922}
[2014-05-06 13:57:37] < {"params": ["1399384656 4237", "b1dd9bc8bb14ba0dcd3e974ef256f16a222868a5701cb14777ba8b5052675499", "01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff2b03a794081e4d696e656420627920474956452d4d452d434f494e532e636f6d5368ea50", "ffffffff01f4c71d2a010000001976a914de78b22dd28d8fbdef1183e39163e7def6a6289588ac0 0000000", ["30cbc1b278b900b0387022f78463b5ec06312bcc17b2ee61ab540713f4f7d46e", "5f17aaa8594c1580851e32af1e6d0a0babd977846f82aa1957d4291824a7c17c", "e76cd8236034069334b372728cc1ba7cf7c86c3219411b55b90df82f00ac9fd1", "67951aa8c764c43646c6264683dacb491a98d97cd7aef32c9d0f4518a7b39494", "92b7397f62140979dc269723822b880497631f9e0e4dd0204e48ef88e750b3a4"], "00000002", "1b08ee37", "5368ea50", false], "method": "mining.notify", "id": null}
[2014-05-06 13:57:37] New job_id: 1399384656 4237 Diff: 128
[2014-05-06 13:57:37] < {"error": null, "result": true, "id": 3922}


Pool send new block/work notification
Pool logs:
2014-05-06 14:01:01,777   newBlockNotification   INFO   Received new block notification
2014-05-06 14:01:01,812   merkleMaker   INFO   New block: af7e5e7bcdcf7027f0728df40687407ec8cb71025454b40506e40c0d9da680b5 (height: 562345; bits: 1b08ee37)
2014-05-06 14:01:01,816   JSONRPCServer   INFO   Nobody to longpoll
2014-05-06 14:01:01,816   StratumServer   INFO   27458 clients to wake up...
2014-05-06 14:01:01,907   BitcoinLink   DEBUG   Received block inv over p2p for af7e5e7bcdcf7027f0728df40687407ec8cb71025454b40506e40c0d9da680b5
2014-05-06 14:01:02,520   JSONRPCServer   INFO   Nobody to longpoll
2014-05-06 14:01:02,840   StratumServer   INFO   New job sent to 27458 clients in 1.024 seconds


Miner logs:
[2014-05-06 14:01:03] New job_id: 1399384862 4239 Diff: 96
[2014-05-06 14:01:05] < {"params": ["1399384862 4239", "9da680b506e40c0d5454b405c8cb71020687407ef0728df4cdcf7027af7e5e7b", "01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff2d03a99408204d696e656420627920474956452d4d452d434f494e532e636f6d5368eb1e1ad6 ", "ffffffff0100f2052a010000001976a914de78b22dd28d8fbdef1183e39163e7def6a6289588ac0 0000000", ["e6962a9ae8378cb5e69680e95b1e682ef45ed4c7d8b3d2b3276a6a4e8f3514e8", "028c24cab4d50f5a38b11af16f11a6f7f92f5355fb210f1a7ed8f3d23d53f8c8"], "00000002", "1b08ee37", "5368eb1e", false], "method": "mining.notify", "id": null}
[2014-05-06 14:01:06] 1@1 850MHz: Got nonce 333b2143, Hash <= Htarget! (0xeb1b2f5f) 71.9 KH/s


Looks like both version work fine (at least for me).

[jamieb81]

Hi sandor,

I don't know if anyone else has this issue but on this version, when checked the miners this morning

they were like super super hot! something that never happened before at same frequency settings

I just checked the power meter, and it is still at ~7W/unit, cool to the touch. Probably the effect of overvolting?

well they have always been overvolted.

simple test I did run them on the real old cpuminer single instances at 1200mh and they are cold to the touch,

with latest cpuminer they get more than warm, too hot for it to be good imo

[sandor111]

Hi sandor,

I don't know if anyone else has this issue but on this version, when checked the miners this morning

they were like super super hot! something that never happened before at same frequency settings

I just checked the power meter, and it is still at ~7W/unit, cool to the touch. Probably the effect of overvolting?

well they have always been overvolted.

simple test I did run them on the real old cpuminer single instances at 1200mh and they are cold to the touch,

with latest cpuminer they get more than warm, too hot for it to be good imo

Can anyone with an overvolted Gridseed confirm that this is the case?

[fivejonnyfive]

A gridseed mini I just bought is either overvolted or very lucky.

it's GSD0 on here:



With regard to what you asked earlier it is indeed cold to the touch - but I can't confirm it's overvolted or by how much.

I do have a kind of dumb question for you by the way: what's the code to specify the chip frequency for just the fast unit? Here's the script I have starting the miner now:

Code:

sudo screen -dmS 0 ./minerd-gc3355 --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2 --gc3355-autotune --freq=850 --url=stratum+tcp://useast.wafflepool.com:3333 --userpass=redacted:pass

I tried this to start the good miner on a higher frequency, but when I loaded the TUI they all still showed 850mhz

Code:

sudo screen -dmS 0 ./minerd-gc3355 --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2 --gc3355-freq=/dev/ttyACM0:1000 --gc3355-autotune --freq=850 --url=stratum+tcp://useast.wafflepool.com:3333 --userpass=redacted:pass

Im thinking that the --freq flag overrides the -gc3355-freq flag? I thought the more specific one wins in that fight but should I try this instead?
EDIT: This one just defaults them all to 600mhz...

Code:

sudo screen -dmS 0 ./minerd-gc3355 --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2 --gc3355-freq=/dev/ttyACM0:1000,/dev/ttyACM1:845,/dev/ttyACM2:855 --gc3355-autotune

anyway, thanks again for this great software.

[sandor111]

For Blade users, I'm quoting this bit of important tuning info again

I forgot that the chip_id can only be half a byte long (0-7) when sending commands to the GC3355 chip, but the chip_id we are seeing from the nonces ranges from 0-39 (= # of chips)
You cannot set the frequency of chip 39, it will overflow the 4 bits. BUT... chip_id 0 is actually referencing chip 0, 8, 16, 24, 32. chip_id 1 is actually referencing chip 1, 9, 17, 25, 33... and so on, they are clusters of 8 chips.
To get the chip_id (to be used in frequency setting), simply do chip_id = chip_id_cpuminer % 8.
So if you set the frequency of chip 0, you will also set it for chip 8, 16 and 32, there is no way around that. This is why I will disable autotune for Blades in the next update.

So you can only set chip_id 0-7
For example, a Blade at ttyACM0/ttyACM1, set chip 3, 11, 19, 27, 35 of one board to 825 MHz:

Code:

--gc3355-frequency=/dev/ttyACM0:825:3

[RowanX]

Looks like both version work fine (at least for me).

Is this the RPi or Windows build you were testing? Windows here, with my problems..

[sandor111]

I tried this to start the good miner on a higher frequency, but when I loaded the TUI they all still showed 850mhz

Code:

sudo screen -dmS 0 ./minerd-gc3355 --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2 --gc3355-freq=/dev/ttyACM0:1000 --gc3355-autotune --freq=850 --url=stratum+tcp://useast.wafflepool.com:3333 --userpass=redacted:pass

Im thinking that the --freq flag overrides the -gc3355-freq flag? I thought the more specific one wins in that fight but should I try this instead?
EDIT: This one just defaults them all to 600mhz...

Code:

sudo screen -dmS 0 ./minerd-gc3355 --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2 --gc3355-freq=/dev/ttyACM0:1000,/dev/ttyACM1:845,/dev/ttyACM2:855 --gc3355-autotune

On which version is that? It always picks the most specific frequency, works fine here.

[nst6563]

I've been testing the .9e build and it's been crashing multiple times since yesterday.  I've been testing various settings and whatnot, and have now switched pools to see if it's a pool issue.  What I've found in the debug log was an error encountered:  [2014-05-06 09:11:38] stratum_recv_line failed.  It happens randomly as well.  I've seen it happen in as little as 10 minutes, and as long as a couple hours.  

cpuminer log for .9e (I noticed at the bottom there is a stratum error)
https://www.dropbox.com/s/94b7clr695f77up/cpuminer-gc3355-Manicminer.log

Windows Crash report details
https://www.dropbox.com/s/m0puqwsy1e1c35s/crash.txt

Anyone else see something like this?
.9d runs fine, .9e fails with that error - same pool.

[surgexvb]

Sandor, how do I pull an old version from github?  I need to revert to an older version.  Ever since about 0.9c I get super high rejects, but cpuminer actually only reports a small portion of them, my pool reports a much higher amount.  I never had this problem with the original gridseed cpuminer and not with your early versioning.  I believe ever since you updated the stratum code to fix a bug, those versions and on give problems.

I get the "debug: job not found" error all the time. 

Also what is your advice on compiling for the Pi.  Should I.use the cfflags ="03" option or the "March=armv6....." options that Mr Jinx suggested?

[Icemoment]

I used ./configure CFLAGS="-march=armv6 -mfpu=vfp -mfloat-abi=hard -lncurses" for 0.9e and it's been running for 9hour now on blade.
Thanks to Sandor for fixing those stability errors (he tortured my blade for about 7 hours   with his testing)

[fivejonnyfive]

I tried this to start the good miner on a higher frequency, but when I loaded the TUI they all still showed 850mhz

Code:

sudo screen -dmS 0 ./minerd-gc3355 --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2 --gc3355-freq=/dev/ttyACM0:1000 --gc3355-autotune --freq=850 --url=stratum+tcp://useast.wafflepool.com:3333 --userpass=redacted:pass

Im thinking that the --freq flag overrides the -gc3355-freq flag? I thought the more specific one wins in that fight but should I try this instead?
EDIT: This one just defaults them all to 600mhz...

Code:

sudo screen -dmS 0 ./minerd-gc3355 --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2 --gc3355-freq=/dev/ttyACM0:1000,/dev/ttyACM1:845,/dev/ttyACM2:855 --gc3355-autotune

On which version is that? It always picks the most specific frequency, works fine here.

Raspberry Pi, 0.9d.
I guess I should probably update to 0.9e and retest but I thought the only update there was for blades.

Edit: Same behavior on 0.9e.

[toxic0n]

Thanks for your work Sandor, going to give the new version a try when I get home.

[sandor111]

I used ./configure CFLAGS="-march=armv6 -mfpu=vfp -mfloat-abi=hard -lncurses" for 0.9e and it's been running for 9hour now on blade.
Thanks to Sandor for fixing those stability errors (he tortured my blade for about 7 hours   with his testing)

Thanks again friend.

[MatthewBCF]

Nice update Sandor - RE v0.9e - I see blades more stable now, but after time it still falls into the path of not posting work..the 5chips remain good though when that happens.

Trying with the new timeout flag to see if that keeps them going after 1-2 hrs.  Will report back if they don't recycle with the flag.

[unamis76]

Testing the new version... The old one seemed to quit every now and then. Didn't have logs enabled, so I didn't know why. Also, I had a chip who simply didn't step up to the frequency I had programmed for it. Just installed the new version, testing right now.

[racebyu]

0.9e ran just fine overnight.  Notice that the 5-chips are quirkier than the blades in terms of performance, but it could also be that I'm on a pool with a fixed [higher] difficulty.  Otherwise performance is consistent across all devices and hashrate has been the highest sustained ever on these things. 

Now I just gotta figure out what ZoomHash is doing about the insane price drop while my order was in processing and we'll be in business.

Great work sandor111 with 0.9e version.
Blade on Win7 laptop running since last night at 11:30pm no issues or resets.

Is there any way or chance to get a backup pool config setting in the bat file?
I know you have the reset for the Blades if not hashing but after X resets then
go to a backup pool? If you need a unit to test on you can use mine and I can
setup TeamViewer for access?