Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 1029. (Read 2347601 times)
ccminger.....sounds kinda dirty
Remember. People who donatate more than 0.1 BTC will recieve my private spreadcoinminer with sourcecode (linux compatible)
ccminer spreadcoin (sp-mod) release 9 is (10-20)% faster than the opensource version
ccminer spreadcoin (sp-mod) release 9 is (10-20)% faster than the opensource version
From my side +50-65 k/hash for 750Ti's and 200k/hash for 970 with built 56. Good work sp... )))
More is coming... If you want a higher hashrate, Please donate some beers.
7.05 MHASH per 750ti.
With djm34's changes we perhaps get 7,5MHASH per 750ti ??
It appears the miner continues to load the gpus when the network is down. Is this the expected behavior?
No. please help me fix it.
It appears the miner continues to load the gpus when the network is down. Is this the expected behavior?
From my side +50-65 k/hash for 750Ti's and 200k/hash for 970 with built 56. Good work sp... )))
How's the power consumption on 980ti , compared to 970 ?
Release 56 has finally made be break 100 mh/s on quark. Virtual beers for everyone!
The 980ti is looking strong.
Feature Request: When launching CCminer with no intensity, "-i" parameter (default), show default threads in launch display as (DEFAULT), as if they had been specified. Should be simple to implement. I am having difficulty adjusting intensity with each new build and algo.
+1
I think there is a bug in my getwork implementation of neoscrypt.
The other forks use a data_size of 80
Code:
static bool work_decode(const json_t *val, struct work *work)
{
int data_size, midstate_size;
switch (opt_algo) {
case ALGO_NEO:
data_size = 84;
break;
The other forks use a data_size of 80
Feature Request: When launching CCminer with no intensity, "-i" parameter (default), show default threads in launch display as (DEFAULT), as if they had been specified. Should be simple to implement. I am having difficulty adjusting intensity with each new build and algo.
I second this request! I'm also having issues with crashing while mining neoscrypt. It'll work fine only if i start mining after a fresh boot, but if the computer has been running for any length of time or i'm switching from another algo it crashes out shortly after starting (about long enough for me to read initial output)
I am getting this error with new version:
Code:
Cuda error in func 'scanhash_quark' at line 177 : cannot set while device is act
ive in this process.
SEGMENTATION FAULTS--
I am experiencing occasional segmentation faults on my Linux rigs, mining Quark. The faults result in a core dump, and require manual restart. They happen after 36-48hrs of use. This is with build 861.
Other results, the 750ti rig runs faster, 100kh/s per card, as previously reported. My 970 rig does not run at 16Mh/s per card, but at 14Mh/s per card, with no overclocking on my Linux box.
My Win 8 rig, mining Lyra2, is stable (so far) with release dot 56. Release dot 55 would lock up on short notice. I quit mining Lyra2 for half a week because of this.
Feature Request: When launching CCminer with no intensity, "-i" parameter (default), show default threads in launch display as (DEFAULT), as if they had been specified. Should be simple to implement. I am having difficulty adjusting intensity with each new build and algo. Donation is promised.
Thank You! --scryptr
I am experiencing occasional segmentation faults on my Linux rigs, mining Quark. The faults result in a core dump, and require manual restart. They happen after 36-48hrs of use. This is with build 861.
Other results, the 750ti rig runs faster, 100kh/s per card, as previously reported. My 970 rig does not run at 16Mh/s per card, but at 14Mh/s per card, with no overclocking on my Linux box.
My Win 8 rig, mining Lyra2, is stable (so far) with release dot 56. Release dot 55 would lock up on short notice. I quit mining Lyra2 for half a week because of this.
Feature Request: When launching CCminer with no intensity, "-i" parameter (default), show default threads in launch display as (DEFAULT), as if they had been specified. Should be simple to implement. I am having difficulty adjusting intensity with each new build and algo. Donation is promised.
Thank You! --scryptr
Release 56 has finally made be break 100 mh/s on quark. Virtual beers for everyone!
interesting. i'm on the 865 build. seems like its not only c11 algo. my oc settings are about +100 MHz on the GPU and none on the MEM
there is definitely some sort of memory leak going on with GPU 0 in a multi-rig system, at least after quitting mining, compiling a new miner, and restarting mining with the newest miner.
on c11 algo, GPU 0 will only display 1/3 the hashrate of other good cards in the system, but it looks like the card is crashed b/c my temp monitor for card 0 shows a very low temp as it's not mining anything. i've verified this on two different rigs now using the same procedure. on the third rig, I rebooted after a new miner compilation, and so far the reboot seems to have fixed this.
on c11 algo, GPU 0 will only display 1/3 the hashrate of other good cards in the system, but it looks like the card is crashed b/c my temp monitor for card 0 shows a very low temp as it's not mining anything. i've verified this on two different rigs now using the same procedure. on the third rig, I rebooted after a new miner compilation, and so far the reboot seems to have fixed this.
Funny you mention that. I had noticed one of my cards hashing quark at about 1/3 of the expected rate.
Restarting ccminer fixed it. It may have happened another time but not enough to show a pattern.
Breaking news: As I write this I just noticed one of my rigs hashing quark slowly. Both cards were hashing at
about 1/2 the usual. Killing ccminer did not work. It failed to connect to the pool with endless retry
messages but no error.
I rebooted and it's back to normal.
there is definitely some sort of memory leak going on with GPU 0 in a multi-rig system, at least after quitting mining, compiling a new miner, and restarting mining with the newest miner.
on c11 algo, GPU 0 will only display 1/3 the hashrate of other good cards in the system, but it looks like the card is crashed b/c my temp monitor for card 0 shows a very low temp as it's not mining anything. i've verified this on two different rigs now using the same procedure. on the third rig, I rebooted after a new miner compilation, and so far the reboot seems to have fixed this.
on c11 algo, GPU 0 will only display 1/3 the hashrate of other good cards in the system, but it looks like the card is crashed b/c my temp monitor for card 0 shows a very low temp as it's not mining anything. i've verified this on two different rigs now using the same procedure. on the third rig, I rebooted after a new miner compilation, and so far the reboot seems to have fixed this.
@sp_ , how does the c11 algo compare with quark algo power-wise? safe to keep the 750ti overclocked ~ +100 MHz?
The cards are identical yes. The temp is between 60-65 degrees of Celsius. I think the hash drops on some of the cards when I connect through the Teamviewer...
Of course, GPU0 has a display attached, Doh!
I'm getting 6680 on 750ti, GPU OC +100, temp below 60C. Reported clock speed is a saw tooth,
slow rise to 1420 then sudden drop to 1375. I think that's throttling.
I've noticed the default intensity is too high for some cards/algos. Ive also noticed some odd behaviour
with intensity. Quark would initially run with -i 23.5. The next time i started it it failed at -i 23.5 but
ran at 23. Then 23 failed and I lowered it to 22.5. 970 + 780ti.
The preceding was on a Windows machine while I was playing with the intensity parm. When it failed
the error was out of memory. I left it at that but days later after an unrelated reboot I gave it another
try and it worked. The default intensity issues seem to be caused by my degraded system.
I have now seen similar behaviour on Linux and with different algos. I had a profit switch script that had
beed running for a day or so then on one switch, out of memory. Any attempt to start ccminer after that
resulted in the out of memory error. A reboot fixed it.
In both cases it appears to be gradual degradation leading me to suspect a slow memory leak. I don't think
this is a new issue in 1.5.55. Instead it has likely been around for a while but has only become apparent
because of an increase in pool switches following the SAK price crash. I suspect every ccminer kill is
leaking a little mem.
If anyone sees out of memory errors try rebooting.
Jump to: