Rejected shares have nothing to do with cpuminer-gc3355, proof:
As I said before, it's 50% you, 50% the pool you're on.
On that basis I switched pool to same as you, and after 11 hours I have these stats: CPUminer v1.0a (11 hours)
Pool: multi.ghash.io (16 diff)
A:24635 R:371 H:13 (1.5% rejects)Screenshot (CPUMiner): http://i.snag.gy/PLW9h.jpgScreenshot (Pool): http://i.snag.gy/vgZcR.jpg1.5% rejects is nothing to worry about I suppose, just wondering why you get 0 rejects. Most likely related to the quality and speed of your internet connection. |
|
|
|
So since any frequency is allowed now and not just 25Mhz steps, does autotune initially start with 25mhz steps and then fine tune it from that point down to something like 5mhz steps?
That would practically be impossible to manage, because for example 825 and 838 MHz are not equivalent, by that I mean that if 838 MHz is stable, there is no guarantee that 825 would also be stable. The commands are calculated from different PLL dividers and that can affect stability, by contrast if you use the same frequency stepping, it's almost 100% certain that a lower frequency will be stable if the current one is. What? You wouldn't like a challenge like that? J/k Makes sense. But if they use different pll dividers would it be possible to create 2 autotune functions - each confined within its own pll divider? That's kind of like the code I like to tinker with but unfortunately I don't know the language cpuminer is in and learning it takes more time than I have right now  That would mean autotune would take much much longer, because it would have to test all (or a selected set) of the frequencies with differing PLL dividers each time it stepped up or down. Cpuminer is written in the most basic language available to man, C. Most of the modern languages today are written in C.  |
|
|
|
Rejected shares have nothing to do with cpuminer-gc3355, proof:  As I said before, it's 50% you, 50% the pool you're on. Anyone who can break my personal record? I think the first time Ghash.io isn't getting DDoS'd. |
|
|
|
So since any frequency is allowed now and not just 25Mhz steps, does autotune initially start with 25mhz steps and then fine tune it from that point down to something like 5mhz steps?
That would practically be impossible to manage, because for example 825 and 838 MHz are not equivalent, by that I mean that if 838 MHz is stable, there is no guarantee that 825 would also be stable. The commands are calculated from different PLL dividers and that can affect stability, by contrast if you use the same frequency stepping, it's almost 100% certain that a lower frequency will be stable if the current one is. |
|
|
|
I've been using auto-tune on a test rig for a few days and it's been rock solid. Thanks so much to Sandor for all the hard work. This is really shaping up to be the best mining software for GSDs out there. As I understand it, I can harvest the auto-tune results of per chip frequency values from the API. I can use toxic0n's PHP script to do that. But it looks like the frequency specification is on a per device node basis. I suspect that the dev nodes can change when rebooting, or if you add or remove GSDs. It seems to me that in order to really make auto-tune useful, you need to be able to specify the frequencies on a per serial number basis, not per device node. And as cool as toxic0n's script is, I think that cpuminer should output the results of auto-tune so that it can be easily used for future launches. So here's the features that I'd like to see to round out auto-tune: - Add something in the main GUI indicating the status of auto tune. It would be nice to have an idea of how far it has to go without using the --debug option and scanning the log output.
- Add the option to specify the frequency by GSD serial number so that it will always work for known units, regardless of the order of device discovery.
- When quitting cpuminer and autotune is done, output the command line options that could be used in subsequent launches. Ideally this would be the serial number based frequency specification.
Sandor, thanks in advance for thinking about these features. Thanks for the suggestions. The JSON array has the dev node as key, but serial string is included as one of the values, so you can compare against that. |
|
|
|
Error on make: make all-recursive
make[1]: Entering directory `/home/sandor_kicks_ass/cpuminer-gc3355'
Making all in compat
make[2]: Entering directory `/home/sandor_kicks_ass/cpuminer-gc3355/compat'
make[3]: Entering directory `/home/sandor_kicks_ass/cpuminer-gc3355/compat'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/sandor_kicks_ass/cpuminer-gc3355/compat'
make[2]: Leaving directory `/home/sandor_kicks_ass/cpuminer-gc3355/compat'
make[2]: Entering directory `/home/sandor_kicks_ass/cpuminer-gc3355'
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -pthread -fno-strict-aliasing -O2 -MT minerd-cpu-miner.o -MD -MP -MF .deps/minerd-cpu-miner.Tpo -c -o minerd-cpu-miner.o `test -f 'cpu-miner.c' || echo './'`cpu-miner.c
cpu-miner.c: In function ‘api_parse_get’:
cpu-miner.c:1468:124: error: expected ‘)’ before ‘;’ token
cpu-miner.c:1470:4: error: expected ‘;’ before ‘}’ token
cpu-miner.c: In function ‘api_request_handler’:
cpu-miner.c:1621:7: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
make[2]: *** [minerd-cpu-miner.o] Error 1
make[2]: Leaving directory `/home/sandor_kicks_ass/cpuminer-gc3355'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/sandor_kicks_ass/cpuminer-gc3355'
make: *** [all] Error 2
Think it's here...missing a closing ')': https://github.com/siklon/cpuminer-gc3355/commit/020c54c4cc425a61bd017186520a06b91f128c13Thanks, fixed. |
|
|
|
Is 24 hours really enough for auto-tune to do its work? I thought it could take a while to figure out the optimal clocks.
If it takes over 24 hours to achieve best results, I'm not interested. That would mean every pool change, software update, reboot, power blip, etc would require it to start from scratch. That doesn't work for me. My understanding is that the auto tune feature maximizes the frequency for the hardware, and that that is unrelated to pool changes. You can use the API to obtain the frequency values after auto-tune is done and use those to create the command line for any subsequent runs. In fact, this person coded a PHP script to do that: https://bitcointalk.org/index.php?topic=482352.msg6603449#msg6603449Note that in order to tell when auto-tune is done, you should use the --debug option. API now has autotune status for each chip. 0 = autotune off 1 = autotune running -1 = autotune stopped So it will be easy to save the resulting frequencies when autotune finished. |
|
|
|
I see that you added support for any freq....do you still recommend only using increments of 25 even though we can do anything now?
Personally I get better results with 25 MHz increments, but for the G-Blade apparently the magical number is 838. |
|
|
|
For maximum performance, try the latest binaries from dropbox. 2-5Kh/s per miner can be gained overall. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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.jpgCrash info from Windows: 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. |
|
|
|
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.jpgCrash info from Windows: 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? |
|
|
|
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. |
|
|
|
I'll let it keep running for a while but methinks autotune is not working in this build. An hour and all the cores still at baseline... Lets see what happens overnight.
EDIT: The exact second I post this, boom: [2014-05-08 23:32:41] 0@1: Set GC3355 core frequency to 875Mhz
Disregard.
--debug to keep track of how much steps are left before it changes the frequency. |
|
|
|
Can you try the latest commit, I think I just fixed that. |
|
|
|
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.
Still curious about the cores not restarting until cold booted. Here is another example: [2014-05-08 22:08:11] 0: Dispatching new work to GC3355 cores (0x4be11c) [2014-05-08 22:08:11] 2: Dispatching new work to GC3355 cores (0x4be11c) [2014-05-08 22:08:12] 1: Dispatching new work to GC3355 cores (0x4be11c) [2014-05-08 22:08:14] 0@0: Work_id differs (004b5f34 != 004be11c) [2014-05-08 22:08:30] 0@0: Work_id differs (004b5f34 != 004be11c) Except they never come back, this is ~10 minutes after starting and I am still getting old work id messages. In fact, this is right after all three units restarted, reset frequencies, and got new work dispatched. For reference, this is with .9g and using the no refresh option as well, watching blocks, work_id differs, and work dispatch, just never a share makes it through. Tried without --no-refresh? Sounds like there is a loose connection somewhere, as instead of the work_id, it's sending back garbage. |
|
|
|
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.
Thanks, tried this with 0.9g but it says: minerd-gc3355: unrecognised option `--no-refresh'
Try `minerd --help' for more information.I did a little update while I was uploading v0.9g, redownloading the binaries should fix it. |
|
|
|
|
Show Posts
