|
I've pushed some little patches with more compact code and little speedups for quark and x11 (also less build warnings).
Sorry Sp_ for the 4 pull requests instead of one: I made them on github directly and couldn't find a way to send a single pull request with more patches (or make a single patch from multiple file edits).
|
|
|
|
hmmm. I doubt that...
I tried to use your modified kernels (cubehash, blakekeccak,bmw) and I mostly see no difference.
there are some variability in the result but on a medium/long run it goes down to the same values I get with the standard kernels...
If the values go down over time it meens that your cards are trottling, because of heat or too low voltage. On my gtx 970 the miner is mining 500KHASH faster than yours. Release 62 standard clocks: (the 980ti is clocked at 1260 on the core) well, the argument isn't really relevant, if throttling happens it happens in the same way for every kernels (slow or fast), so if a kernel is faster it will remain faster no matter of any throttling and here it isn't the case... (test was done using default clock and tdp target of 100%) If a kernel is faster it probably also draw more power, which in turn means more heat so higher chance of throttling. If an enhancement to a kernel has the same performance/watt ratio as the original, the card may throttle and bring the same performance using the same power but a lower clock speed. I'm talking general as I don't know if it's valid for this specific case. |
|
|
|
If you look in my bmw256 mod this code would not unroll:
// #pragma unroll
// for (i = 0; i<2; i++)
// Q[i + 16] = expand32_1(i + 16, M32, H, Q);
So I had to manually unroll it. And with the manual unroll I got less instructions and faster code.
That's interesting. Any idea why it's not unrolling it automatically in this case? Did you try this: for (i = 16; i<18; i++) Q = expand32_1(i, M32, H, Q); |
|
|
|
Found the bug I think. I put the reset flag in the change difficulty method in utils.cpp. Again testing something and it got commited.
That pretty much fixed the low hashrate on pool AND hashrate flooding! :-) You can revert the "prevent hashrate flooding" fix, now it's kinda reporting dry  |
|
|
|
|
I've submitted a little pull request for better gpu disabling on network failure.
Please check it on stratum as well as solo mining (which I didn't test yet).
EDIT: the first version I did some time ago didn't work on some situations, for example pool timeout instead of disconnect.
EDIT2: people please test it, there are many network types and states, I can't test them all.
|
|
|
|
edit: there was a changed pushed by pallas to bmw256, however I don't think it would break solo mining, you can probably test that with testnet
does ccminer use the gpu computed block hash for something in solo mining mode? surely cgminer derivates do not, maybe ccminer is different... |
|
|
|
News about the idle gpu issue (leading to lower hashrate on the pool).
I monitored the power usage and when it drops I get this kind of debug output:
[2015-09-03 11:27:42] sleeptime: 500 ms
[2015-09-03 11:27:42] DEBUG: job_id=5e8126d 67b xnonce2=3e000000 time=11:27:09
[2015-09-03 11:27:42] GPU #3: start=99999999 end=9a68f324 range=00cf598b
many times, leading to a sleep time of 10/15 seconds.
meanwhile, the gpus are idle.
it happens more on neoscrypt than quark or x11.
EDIT: the problem is reduced increasing scantime (and vice-versa)
from this code: (ccminer.cpp) if (have_stratum) { uint32_t sleeptime = 0; while (!work_done && time(NULL) >= (g_work_time + opt_scantime)) { usleep(100*1000); if (sleeptime > 4) { extrajob = true; break; } sleeptime++; } if (sleeptime && opt_debug && !opt_quiet) { applog(LOG_DEBUG, "sleeptime: %u ms", sleeptime * 100); } nonceptr = (uint32_t*) (((char*)work.data) + wcmplen); pthread_mutex_lock(&g_work_lock); extrajob |= work_done; if (nonceptr[0] >= end_nonce || extrajob) { work_done = false; extrajob = false; stratum_gen_work(&stratum, &g_work); } } yes, that's the part of code I'm looking into. there are some things to say: - work_done is never set to true (same for other ccminer forks...). - I'm experiencing this problem since about a week, so there must be something in the last commits. - the "shorter work leading to hashrate flooding" may be related to this, as I started experiencing the two problems at the same time. |
|
|
|
|
I've submitted a little pull request to fix the latest git.
sp_ commented a part of the code and forgot to re-enable it because it was late night :-)
EDIT: already merged, thanks
|
|
|
|
|
News about the idle gpu issue (leading to lower hashrate on the pool).
I monitored the power usage and when it drops I get this kind of debug output:
[2015-09-03 11:27:42] sleeptime: 500 ms
[2015-09-03 11:27:42] DEBUG: job_id=5e8126d 67b xnonce2=3e000000 time=11:27:09
[2015-09-03 11:27:42] GPU #3: start=99999999 end=9a68f324 range=00cf598b
many times, leading to a sleep time of 10/15 seconds.
meanwhile, the gpus are idle.
it happens more on neoscrypt than quark or x11.
EDIT: the problem is reduced increasing scantime (and vice-versa)
|
|
|
|
thanks, that fixed the crash :-) |
|
|
|
|
Latest commit:
19917 Floating point exception(core dumped) ./ccminer -a quark
Neoscrypt all invalid nonces.
EDIT: there must be something wrong with the last releases, it's been running fine for weeks, now I'm having all sorts of problems... or a weird hardware failure (unlikely).
|
|
|
|
and a little more  (the 750ti is oc at +200 mem/core, actually core matters more than mem) so the question is once again: what do you wanna do with it? :-) |
|
|
|
Hi All Being watching this thread with interest the past could of weeks & decided to move over from ageing old AMD's to Nvidia and build my first 750ti rig. which is now up and running I've got to ask tsiv how are you getting 5700 from the 750ti? mine are only doing 4600  wDragon Wrote a faster version of the lyra kernel. Magic. ah getting now 5.9MH/s (and up to 6MH/s with some stronger OC) on the 750ti... funny though that kernel doesn't perform that well on the 980 ( getting only 10.6MH getting about same as the public (kernel setting was way off) and my other private kernel is doing 15MH/s) @Djm Pls add VTC adress to your signature. @Pallas u too  ) @sp 4106e4d023060e19abdbbf2aa45dec23d40a5694f486b5dbfea656b7a92c3b74 , i was busy all week, I'll send more soon.. Miners didn't worked for some time , i have to collect more ) I have added it to my signature now, thanks! :-) |
|
|
|
|
I have the feeling that the faster hashrate reporting, and maybe other issues, are not related to the reporting itself.
It is now exiting lighting fast when I hit ctrl-C, it never was that fast, it always took some seconds. Now a blink of an eye.
It looks like the jobs sent to the gpu are computed much faster (but the hashrate is the same), maybe they are smaller.... I don't know how to check this.
|
|
|
|
There was also a cpu-load "bug" just a few CCminer editions back. The bug used a lot of CPU power, but also increased the hash rate. It is only with the most recent releases that CCminer can achieve the same or better hash rates.
I'd like to see a command line switch that would allow the miner to engage the CPU for greater hash rates. On my dedicated rigs I'd engage the CPU, and benefit from the greater hash rate. On my work computer, I'd leave it out so that my desktop would not freeze.
There was a similar switch in CudaMiner, and it was sometimes effective in mining script. If the CPU "bug" was ironed out and taught to behave well, I am sure that miners would use it when appropriate. --scryptr
I guess you are referring to the "bug" I introduced when initially submitted the improved neoscrypt kernel. I removed this: cudaSetDeviceFlags(cudaDeviceScheduleBlockingSync); Which looked to induce a little speed gain, without noticing it also produced 100% cpu load. We could add a commandline option to disable it, but personally I think the hassle and additional power usage doesn't justify less-than-one-percent hashrate gain. Still if it's optional, I see no reason not to include it (provided that what it does is well explained). BTW ethereum cudaminer has a similar option. |
|
|
|
Can you display a screenshot?
Just a lot of per thread hashrate lines, at least 10 times the normal output. I'm experiencing reduced performance on the pool as well, tried neoscrypt and x11. The power meter shows recurring short periods of lower usage. Really weird... I checked in another fix. Seems to increase the hashrate. The flooding was causing a drop in hashrate. About the excessive output: now it's improved, still more than previous versions. About hashrate and power usage: not sure it's related, maybe a hardware problem, will be watching it closely. |
|
|
|
Can you display a screenshot?
Just a lot of per thread hashrate lines, at least 10 times the normal output. I'm experiencing reduced performance on the pool as well, tried neoscrypt and x11. The power meter shows recurring short periods of lower usage. Really weird... |
|
|
|
|
crazy hashrate logging issue still not fixed for me on latest git commit (built from scratch).
|
|
|
|
|
Show Posts
