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).
Topic: [GUIDE] GridSeed 5-Chip USB, Blade & Black Miner Support/Tuning - page 24. (Read 308847 times)
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.
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:
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
Quote
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.
Quote
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:
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
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.
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
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
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
Quote
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.
Quote
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:
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
Quote
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.
Quote
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've only been running it for a little while but 0.9e seems to be giving the same problems as 0.9d, for me (Windows version). i.e. too many rejects with message "DEBUG: reject reason: unknown-work". Who here on Windows is or is not having the same issue? I've gone back to using 0.9c, again - its working fantastic. Sandor do you think this issue is likely to be specific to my setup? You are the magic jesus of mining and I look forward to your reply. 
In 0.9d, new work is sent when there is a new job and after a nonce is found, in 0.9c it would stop hashing immediately and send the new work. The latter is actually inefficient and slows down the mining.
Could you post a log with --debug and --protocol option enabled?
Personally I'm still getting 0.2% rejects whatever the pool I go with.
Sure thing. Just add --debug and --protocol-dump to my bat file? I assume it will output the debug dump into a file in the same directory. How long should I run it for to produce something useful. An hour? I'll do it tomorrow its 3am here and I need to collapse.
Sandor I can't see that the debug/log is being stored anywhere just printed to the screen? Rejects still seem high for me in your Windows build from today of 0.9e (A:306 R:36 H:0 over 60mins). Here is an excerpt from the log when some errors occured. Does this shed any light?
[2014-05-06 10:55:11] 1: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "55555581", "5368b16b", "a098f0cc"], "id":4016}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4016}
[2014-05-06 10:55:11] Rejected ccf098a0 GSD 1@4
[2014-05-06 10:55:11] DEBUG: reject reason: unknown-work
[2014-05-06 10:55:11] 0@0 875MHz: Got nonce 002ede29, Hash <= Htarget! (0xb1547f34) 74.1 KH /s
[2014-05-06 10:55:11] 0: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "8000002b", "5368b16b", "29de2e00"], "id":4017}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4017}
[2014-05-06 10:55:12] Rejected 002ede29 GSD 0@0
[2014-05-06 10:55:12] DEBUG: reject reason: unknown-work
Add --log
Here is an hours worth of log:
http://pastebin.com/BghRt9LX
FWIW this was my bat file (running 2 Gridseeds):
minerd-gc3355 --debug --protocol-dump --log --freq=850 --gc3355=\\.\COM1,\\.\COM2 --url=stratum+tcp://xxxxxxxxx.com:3333 --userpass=Rowan.1:pass --gc3355-freq=\\.\COM1:875,\\.\COM1:850:2,\\.\COM2:850:0,\\.\COM2:850:1,\\.\COM2:825:2,\\.\COM2:875:3,\\.\COM2:850:4,
pause
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've only been running it for a little while but 0.9e seems to be giving the same problems as 0.9d, for me (Windows version). i.e. too many rejects with message "DEBUG: reject reason: unknown-work". Who here on Windows is or is not having the same issue? I've gone back to using 0.9c, again - its working fantastic. Sandor do you think this issue is likely to be specific to my setup? You are the magic jesus of mining and I look forward to your reply.
In 0.9d, new work is sent when there is a new job and after a nonce is found, in 0.9c it would stop hashing immediately and send the new work. The latter is actually inefficient and slows down the mining.
Could you post a log with --debug and --protocol option enabled?
Personally I'm still getting 0.2% rejects whatever the pool I go with.
Sure thing. Just add --debug and --protocol-dump to my bat file? I assume it will output the debug dump into a file in the same directory. How long should I run it for to produce something useful. An hour? I'll do it tomorrow its 3am here and I need to collapse.
Sandor I can't see that the debug/log is being stored anywhere just printed to the screen? Rejects still seem high for me in your Windows build from today of 0.9e (A:306 R:36 H:0 over 60mins). Here is an excerpt from the log when some errors occured. Does this shed any light?
[2014-05-06 10:55:11] 1: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "55555581", "5368b16b", "a098f0cc"], "id":4016}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4016}
[2014-05-06 10:55:11] Rejected ccf098a0 GSD 1@4
[2014-05-06 10:55:11] DEBUG: reject reason: unknown-work
[2014-05-06 10:55:11] 0@0 875MHz: Got nonce 002ede29, Hash <= Htarget! (0xb1547f34) 74.1 KH /s
[2014-05-06 10:55:11] 0: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "8000002b", "5368b16b", "29de2e00"], "id":4017}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4017}
[2014-05-06 10:55:12] Rejected 002ede29 GSD 0@0
[2014-05-06 10:55:12] DEBUG: reject reason: unknown-work
Add --log
Here is an hours worth of log:
http://pastebin.com/BghRt9LX
FWIW this was my bat file (running 2 Gridseeds):
minerd-gc3355 --debug --protocol-dump --log --freq=850 --gc3355=\\.\COM1,\\.\COM2 --url=stratum+tcp://xxxxxxxxx.com:3333 --userpass=Rowan.1:pass --gc3355-freq=\\.\COM1:875,\\.\COM1:850:2,\\.\COM2:850:0,\\.\COM2:850:1,\\.\COM2:825:2,\\.\COM2:875:3,\\.\COM2:850:4,
pause
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).
I've only been running it for a little while but 0.9e seems to be giving the same problems as 0.9d, for me (Windows version). i.e. too many rejects with message "DEBUG: reject reason: unknown-work". Who here on Windows is or is not having the same issue? I've gone back to using 0.9c, again - its working fantastic. Sandor do you think this issue is likely to be specific to my setup? You are the magic jesus of mining and I look forward to your reply.
In 0.9d, new work is sent when there is a new job and after a nonce is found, in 0.9c it would stop hashing immediately and send the new work. The latter is actually inefficient and slows down the mining.
Could you post a log with --debug and --protocol option enabled?
Personally I'm still getting 0.2% rejects whatever the pool I go with.
Sure thing. Just add --debug and --protocol-dump to my bat file? I assume it will output the debug dump into a file in the same directory. How long should I run it for to produce something useful. An hour? I'll do it tomorrow its 3am here and I need to collapse.
Sandor I can't see that the debug/log is being stored anywhere just printed to the screen? Rejects still seem high for me in your Windows build from today of 0.9e (A:306 R:36 H:0 over 60mins). Here is an excerpt from the log when some errors occured. Does this shed any light?
[2014-05-06 10:55:11] 1: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "55555581", "5368b16b", "a098f0cc"], "id":4016}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4016}
[2014-05-06 10:55:11] Rejected ccf098a0 GSD 1@4
[2014-05-06 10:55:11] DEBUG: reject reason: unknown-work
[2014-05-06 10:55:11] 0@0 875MHz: Got nonce 002ede29, Hash <= Htarget! (0xb1547f34) 74.1 KH /s
[2014-05-06 10:55:11] 0: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "8000002b", "5368b16b", "29de2e00"], "id":4017}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4017}
[2014-05-06 10:55:12] Rejected 002ede29 GSD 0@0
[2014-05-06 10:55:12] DEBUG: reject reason: unknown-work
Add --log
Here is an hours worth of log:
http://pastebin.com/BghRt9LX
FWIW this was my bat file (running 2 Gridseeds):
minerd-gc3355 --debug --protocol-dump --log --freq=850 --gc3355=\\.\COM1,\\.\COM2 --url=stratum+tcp://xxxxxxxxx.com:3333 --userpass=Rowan.1:pass --gc3355-freq=\\.\COM1:875,\\.\COM1:850:2,\\.\COM2:850:0,\\.\COM2:850:1,\\.\COM2:825:2,\\.\COM2:875:3,\\.\COM2:850:4,
pause
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.
I've only been running it for a little while but 0.9e seems to be giving the same problems as 0.9d, for me (Windows version). i.e. too many rejects with message "DEBUG: reject reason: unknown-work". Who here on Windows is or is not having the same issue? I've gone back to using 0.9c, again - its working fantastic. Sandor do you think this issue is likely to be specific to my setup? You are the magic jesus of mining and I look forward to your reply.
In 0.9d, new work is sent when there is a new job and after a nonce is found, in 0.9c it would stop hashing immediately and send the new work. The latter is actually inefficient and slows down the mining.
Could you post a log with --debug and --protocol option enabled?
Personally I'm still getting 0.2% rejects whatever the pool I go with.
Sure thing. Just add --debug and --protocol-dump to my bat file? I assume it will output the debug dump into a file in the same directory. How long should I run it for to produce something useful. An hour? I'll do it tomorrow its 3am here and I need to collapse.
Sandor I can't see that the debug/log is being stored anywhere just printed to the screen? Rejects still seem high for me in your Windows build from today of 0.9e (A:306 R:36 H:0 over 60mins). Here is an excerpt from the log when some errors occured. Does this shed any light?
[2014-05-06 10:55:11] 1: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "55555581", "5368b16b", "a098f0cc"], "id":4016}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4016}
[2014-05-06 10:55:11] Rejected ccf098a0 GSD 1@4
[2014-05-06 10:55:11] DEBUG: reject reason: unknown-work
[2014-05-06 10:55:11] 0@0 875MHz: Got nonce 002ede29, Hash <= Htarget! (0xb1547f34) 74.1 KH /s
[2014-05-06 10:55:11] 0: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "8000002b", "5368b16b", "29de2e00"], "id":4017}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4017}
[2014-05-06 10:55:12] Rejected 002ede29 GSD 0@0
[2014-05-06 10:55:12] DEBUG: reject reason: unknown-work
Add --log
Here is an hours worth of log:
http://pastebin.com/BghRt9LX
FWIW this was my bat file (running 2 Gridseeds):
minerd-gc3355 --debug --protocol-dump --log --freq=850 --gc3355=\\.\COM1,\\.\COM2 --url=stratum+tcp://xxxxxxxxx.com:3333 --userpass=Rowan.1:pass --gc3355-freq=\\.\COM1:875,\\.\COM1:850:2,\\.\COM2:850:0,\\.\COM2:850:1,\\.\COM2:825:2,\\.\COM2:875:3,\\.\COM2:850:4,
pause
Sandor111, is there a way in the batch file that you can specify a frequency for GDS 0 and another for GDS 1? Or do they both have to be the same?
thx
thx
Sure, look in my signature for examples on that.
Just curious, On a Raspberry Pi do the device names stay constant across reboots?
They stay constant.
You don't say... I was curious about this but haven't paid enough attention across reboots and reconfigs. Knowing this I may have to move the 5-chips to a multicoin pool or something for better diff.
Sandor111, is there a way in the batch file that you can specify a frequency for GDS 0 and another for GDS 1? Or do they both have to be the same?
thx
thx
Sure, look in my signature for examples on that.
Just curious, On a Raspberry Pi do the device names stay constant across reboots?
They stay constant.
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.
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.
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 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?
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 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
The freezing problem seems to have something to do.with the autotune feature. When enabled, it freezes every 2 hours or so everytime. When I disable it, now it has been running fine for 12 hours.
That's because the the autotune features prints a line immediately after another, so it's more likely to deadlock (tui_lock).
Do you still experience freezing even with v0.9a? It should be a thing of the past now.
Looks like "--freq=950" overrides the "--gc3355-freq=\\.\COM42:700"
How could i set one device lower/higher than all the rest without typing each individually?
Edit: OK. I got it. I needed to write individual freq before the overall.
How could i set one device lower/higher than all the rest without typing each individually?
Edit: OK. I got it. I needed to write individual freq before the overall.
I'm pretty sure it's not the case. The most specific frequency is always applied.
Sandor111, I've been using the latest (0.9a) on/off for ~4 days and my blades are always freezing, esp when getting a new block or after I see "dispatching new work.." - One might conclude it is any message except "accepted" which has a chance of causing the freeze.
I can't say I've tried everything, but I am pretty sure it isn't the cards as this is an issue occurring in cpuminer, not cgminer.
Overall I think it is a fantastic step fwd, seems stable. I know you are going to add the single step freq soon too, so that will be a big plus.
Otherwise, any ideas on why the blade freezes, particularly when the difficulty jumps and/or new block or dispatching work ..I wish I could be more precise but it is definitely when something besides hashing happens.
I have a pile of 5chips that run on the same raspi with no issue too.
Thanks
The latest is 0.9e, in which Blade stability issues is fixed.
I've only been running it for a little while but 0.9e seems to be giving the same problems as 0.9d, for me (Windows version). i.e. too many rejects with message "DEBUG: reject reason: unknown-work". Who here on Windows is or is not having the same issue? I've gone back to using 0.9c, again - its working fantastic. Sandor do you think this issue is likely to be specific to my setup? You are the magic jesus of mining and I look forward to your reply.
In 0.9d, new work is sent when there is a new job and after a nonce is found, in 0.9c it would stop hashing immediately and send the new work. The latter is actually inefficient and slows down the mining.
Could you post a log with --debug and --protocol option enabled?
Personally I'm still getting 0.2% rejects whatever the pool I go with.
Sure thing. Just add --debug and --protocol-dump to my bat file? I assume it will output the debug dump into a file in the same directory. How long should I run it for to produce something useful. An hour? I'll do it tomorrow its 3am here and I need to collapse.
Sandor I can't see that the debug/log is being stored anywhere just printed to the screen? Rejects still seem high for me in your Windows build from today of 0.9e (A:306 R:36 H:0 over 60mins). Here is an excerpt from the log when some errors occured. Does this shed any light?
[2014-05-06 10:55:11] 1: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "55555581", "5368b16b", "a098f0cc"], "id":4016}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4016}
[2014-05-06 10:55:11] Rejected ccf098a0 GSD 1@4
[2014-05-06 10:55:11] DEBUG: reject reason: unknown-work
[2014-05-06 10:55:11] 0@0 875MHz: Got nonce 002ede29, Hash <= Htarget! (0xb1547f34) 74.1 KH /s
[2014-05-06 10:55:11] 0: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "8000002b", "5368b16b", "29de2e00"], "id":4017}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4017}
[2014-05-06 10:55:12] Rejected 002ede29 GSD 0@0
[2014-05-06 10:55:12] DEBUG: reject reason: unknown-work
Add --log
I've only been running it for a little while but 0.9e seems to be giving the same problems as 0.9d, for me (Windows version). i.e. too many rejects with message "DEBUG: reject reason: unknown-work". Who here on Windows is or is not having the same issue? I've gone back to using 0.9c, again - its working fantastic. Sandor do you think this issue is likely to be specific to my setup? You are the magic jesus of mining and I look forward to your reply.
In 0.9d, new work is sent when there is a new job and after a nonce is found, in 0.9c it would stop hashing immediately and send the new work. The latter is actually inefficient and slows down the mining.
Could you post a log with --debug and --protocol option enabled?
Personally I'm still getting 0.2% rejects whatever the pool I go with.
Sure thing. Just add --debug and --protocol-dump to my bat file? I assume it will output the debug dump into a file in the same directory. How long should I run it for to produce something useful. An hour? I'll do it tomorrow its 3am here and I need to collapse.
Sandor I can't see that the debug/log is being stored anywhere just printed to the screen? Rejects still seem high for me in your Windows build from today of 0.9e (A:306 R:36 H:0 over 60mins). Here is an excerpt from the log when some errors occured. Does this shed any light?
[2014-05-06 10:55:11] 1: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "55555581", "5368b16b", "a098f0cc"], "id":4016}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4016}
[2014-05-06 10:55:11] Rejected ccf098a0 GSD 1@4
[2014-05-06 10:55:11] DEBUG: reject reason: unknown-work
[2014-05-06 10:55:11] 0@0 875MHz: Got nonce 002ede29, Hash <= Htarget! (0xb1547f34) 74.1 KH /s
[2014-05-06 10:55:11] 0: Dispatching new work to GC3355 cores (0xb1547f34)
[2014-05-06 10:55:11] > {"method": "mining.submit", "params": ["Rowan.1", "139937 0091 3796", "8000002b", "5368b16b", "29de2e00"], "id":4017}
[2014-05-06 10:55:11] < {"error": [20, "unknown-work", null], "result": null, "id": 4017}
[2014-05-06 10:55:12] Rejected 002ede29 GSD 0@0
[2014-05-06 10:55:12] DEBUG: reject reason: unknown-work
I have to say I've had little but trouble since switching off the last non-versioned minerd I got on the 28th April
It seems to be the issue that everyone else has - eventually work just stops being submitted. Still appears to be working, still have a full set of stats coming but the pool is reporting nothing its end!
I'm giving 0.9e a try now and will see how long it can run for
It seems to be the issue that everyone else has - eventually work just stops being submitted. Still appears to be working, still have a full set of stats coming but the pool is reporting nothing its end!
I'm giving 0.9e a try now and will see how long it can run for
I've only been running it for a little while but 0.9e seems to be giving the same problems as 0.9d, for me (Windows version). i.e. too many rejects with message "DEBUG: reject reason: unknown-work". Who here on Windows is or is not having the same issue? I've gone back to using 0.9c, again - its working fantastic. Sandor do you think this issue is likely to be specific to my setup? You are the magic jesus of mining and I look forward to your reply.
In 0.9d, new work is sent when there is a new job and after a nonce is found, in 0.9c it would stop hashing immediately and send the new work. The latter is actually inefficient and slows down the mining.
Could you post a log with --debug and --protocol option enabled?
Personally I'm still getting 0.2% rejects whatever the pool I go with.
Same issue here still.too on Raspberrypi. I get a LOT of rejects, sometimes my pool shows.only 75% efficiency. I've tried different pools.with the same result. Tried with auto tune on and off, same result. Using version 0.9e. C worked the best so far. 5 chip miners, 21 per RasPi.
Jump to: