sandor111
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 01:23:37 PM |
|
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... ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) 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/d07b9abe2f3fbd0f530f2e6d5af54449f87c2d78I 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://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FCaNfyI5.png&t=665&c=ve36AhREZ1bJdA)
|
|
|
|
RowanX
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 86
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 01:36:52 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 01:38:32 PM |
|
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.jpgI just tested the pool on v0.9d and it occasionally reports new blocks, so it's not related to cpuminer.
|
|
|
|
kha0S
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 01:40:43 PM |
|
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/12b54ffff5dea7941fdf096bb66e2955b00f90b5I 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... ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) 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/d07b9abe2f3fbd0f530f2e6d5af54449f87c2d78I 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://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FCaNfyI5.png&t=665&c=ve36AhREZ1bJdA)
|
|
|
|
kha0S
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 01:53:19 PM Last edit: May 06, 2014, 02:05:39 PM by 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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 01:57:56 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 02:26:44 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 02:45:35 PM |
|
A gridseed mini I just bought is either overvolted or very lucky. it's GSD0 on here: ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2F4TNK6VN.jpg&t=665&c=S5rTE0Cjj0g-5A) 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: 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 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... 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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 02:47:02 PM |
|
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: --gc3355-frequency=/dev/ttyACM0:825:3
|
|
|
|
RowanX
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 86
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 03:00:45 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 03:23:22 PM |
|
I tried this to start the good miner on a higher frequency, but when I loaded the TUI they all still showed 850mhz 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... 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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 03:35:39 PM |
|
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.logWindows Crash report details https://www.dropbox.com/s/m0puqwsy1e1c35s/crash.txtAnyone else see something like this? .9d runs fine, .9e fails with that error - same pool.
|
|
|
|
surgexvb
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 03:45:07 PM |
|
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
Newbie
Offline
Activity: 7
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 03:53:31 PM Last edit: May 06, 2014, 04:05:40 PM by 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 ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) with his testing)
|
|
|
|
fivejonnyfive
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 03:55:47 PM |
|
I tried this to start the good miner on a higher frequency, but when I loaded the TUI they all still showed 850mhz 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... 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
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 413
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 04:49:37 PM |
|
Thanks for your work Sandor, going to give the new version a try when I get home.
|
|
|
|
sandor111
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 05:09:23 PM |
|
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 ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) with his testing) Thanks again friend. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
MatthewBCF
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 71
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 05:12:13 PM |
|
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.
|
Crypto with a purpose :: WATER / DGB / REDD / ECC / NOBL / EMC2 / SHARE
|
|
|
unamis76
Legendary
Offline
Activity: 1512
Merit: 1012
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 07:12:14 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2014, 08:50:09 PM |
|
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. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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?
|
|
|
|
|