|
For those who had a high reject rate since v0.9e, you should try v0.9g. It has an additional command line parameter to only send work when a new block is detected (--no-refresh), by default it always sends new work as previously, so there should be much less rejects. You may enable this if your G-Blade is having trouble keeping up with the work sent.
|
|
|
|
cpuminer-gc3355 v0.9g * Failover pool strategy is supported * Low reject rate (--no-refresh -> disabled) --url=stratum+tcp://pool1:port --userpass=user1:pass1 --url=stratum+tcp://pool2:port --userpass=user2:pass2 --url=stratum+tcp://pool3:port --userpass=user3:pass3 Pool 1 is the main pool, if it is down, it will try to connect to the backup pool(s) and query the main pool until it is back up and switch pools automatically. Will add support for config file soon. Binaries have been updated. Windows: https://www.dropbox.com/s/ttqa9p851siz8oi/minerd-gc3355.zipRaspberry PI: https://www.dropbox.com/s/xc3lvysi8vtrt00/minerd-gc3355 |
|
|
|
A couple of feature requests for Sandor's cpuminer.
It would be great if cpuminer directly supported failover to other pools, with the option to return to the primary pool. As it is, it looks like the dev suggests a script with multiple calls to minerd, where a different pool is specified on each command line. While I can see that this kind of works, the result is that the miner will be stuck on alternate pools until those pools fail.
In my case with cgminer, I have my primary pool set to a multi-pool. When fails, the rig points at a fixed coin pool. When the primary comes back online, it points back to the primary.
The reason why I have it configured this way is because I prefer the multi-pool for profitability. But when it's down I don't want to point the rig at another multi pool because it's usually for only a brief time, which often results in not meeting the minimum payout, and dust sitting in the secondary pool forever. It's much cleaner to just mine a single coin for a brief time while the primary is out. That way there are no exchange issues.
The second feature request is for support of a config file. It would be great to be able to specify options in a JSON config file rather than on the raw command line. This would especially be useful to specify auto tune derived frequencies (which can be large for bigger rigs).
Also, if the failover feature is implemented at some point, it's cleaner to specify multiple pools and user credentials in a config file rather than on the command line.
I have to say that this is where cgminer excels..json conf file, multiple pools, multiple modes of running those pools..quotas even.. Definitely not knocking cpuminer tho! I'm using it for 90% of my hash now.. And features often come down to motivation right - The more who donate to Sandor the more likely we are to see any of these nice-to-haves..I for one made sure to..always good to feed the programmers now and again  I'm testing the failover code ATM, will be released soon. |
|
|
|
|
I would suggest to drop SHA mining, and go with Scrypt only, the Gridseeds are clearly not made for that. There are far better alternatives to SHA mining.
|
|
|
|
Is there a way to have cpuminer automatically find all of the Gridseed 5-chip devices rather than specify each one via the --gc3355=/dev option?
If you're on Linux, you can use this command: minerd -o stratum+tcp://pool.com -u USERNAME -p PASSWORD --gc3355-autotune --gc3355=`ls -m /dev/ttyACM* | sed -e 's/, /,/g' | tr -d '\n'` --freq=1200 Thanks! I'm on a Raspberry Pi, so it's Linux. But when I do the following command on my current GridSeed rig (running cgminer; haven't moved over to minerd yet), I get an error: sudo ls -m /dev/ttyACM*
ls: cannot access /dev/ttyACM*: No such file or directory
But in checking the siklon/cpuminer-gc3355 read me on github it appears that cgminer is somehow responsible for preventing ttyUSB or ttyACM devices from being visible. I guess I need to quit cgminer and reboot in order to work around it. I'll try that on my test rig when I get home tonight. But wouldn't it be a nice feature to have minerd just find all of the GSDs on its own? Maybe something like this syntax: "--gc3355=ALL". Seems like a natural compliment to the auto tune feature. Also, the competition (like cgminer) finds all the units simply enough. And I think bfgminer supports a similar "ALL" syntax (although I could be misremembering). This feature is just recently added, the command is --gc3355-detect. |
|
|
|
No problem. Also, remember it is normal to see a number of HW errors while the autotune is ongoing. With the above script you can also see the individual chip frequencies it settles at and then set those via the command. That way you should see close to zero errors.
I haven't got autotune enabled anymore, autotune already finished and I'm using the frequencies it gave me. Already got the php working, at least kind of. The information appears a bit scattered and it gives me 700+ HW errors for some chips (30 showing up on cpuminer), I'm trying to see what I can do to make it display the info in a better, easier way to read... 700 HW errors definitely isn't normal, the frequency is set waaaay too high. |
|
|
|
There's no need for something so complicated. This will work just fine: minerd -o stratum+tcp://pool.com -u USERNAME -p PASSWORD --gc3355-autotune --gc3355=`ls -m /dev/ttyACM* | sed -e 's/, /,/g' | tr -d '\n'` --freq=1200
That is indeed elegant, thanks. Not needed anymore in v0.9f Replace --gc3355=... with --gc3355-detect and it will detect all GC3355 devices automatically. |
|
|
|
|
Serial string is added to display when built from the last commit.
|
|
|
|
BTW, just like bfgminer it is now possible the set the frequency on the fly with cpuminer-gc3355 using the API. {"set":"frequency", "devices":{"ttyACM0":{"chips":[825,850,875,900,850]}}}I thought I'd mention it, since it is a feature of the Hashra controla. |
|
|
|
Weird, on 0.9e just noticed this message before the screen shutdown, spelling may be off: SIGSEGV Received Cleanup then the screen shut down. Reboot and everything is fine, but what's that about?  I've updated the binaries once again (still v0.9e), this should fix the crash. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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 |
|
|
|
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? |
|
|
|
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. |
|
|
|
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/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:  |
|
|
|
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-workAdd --log Here is an hours worth of log: http://pastebin.com/BghRt9LXFWIW 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,
pauseThe 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-workAdd --log Here is an hours worth of log: http://pastebin.com/BghRt9LXFWIW 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,
pauseThe 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. |
|
|
|
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? |
|
|
|
|
Show Posts
