CCminer(SP-MOD) Modded GPU kernels.

[italeffect]

Getting 19,130 kh/s on a 6 x EVGA 750ti OC rig with the new version (x11). Very nice!

I am seeing "does not validate on CPU" messages, one every 2-3 minutes or so.

Thanks

[italeffect]

also, what's the default -i value when one is not specified? I've been testing a few so far and 18.4 seems to be the best of those I've tried so far.

[Epsylon3]

Lyra2RE +12% on the 750ti in my private kernal.
1,4MHASH@980 standard clocks
Just a start

groestl ?

No, Blake and lyra32

Lyra TPB was wrong, i tested 128 when i imported it, but maybe the cpu load was limiting the benefits, 160 seems to give more than 10% on both 750 and 970.

[scryptr]

also, what's the default -i value when one is not specified? I've been testing a few so far and 18.4 seems to be the best of those I've tried so far.

The default "-i" value varies per algorithm.  For x11, it is currently 20.  There is a listing by the author, tpruvot:

https://docs.google.com/spreadsheets/d/1dI1Cc3JhhsA-UdIRlndvQ9huX8FmoJT2TXFDB0wdp54/edit#gid=1086083191

For x11, I get good results with "-i 20.5".       --scryptr

[sp_]

Lyra TPB was wrong, i tested 128 when i imported it, but maybe the cpu load was limiting the benefits, 160 seems to give more than 10% on both 750 and 970.

yes. Klaus checked in TPB of 160. I sublitted some more changes@github. 12% faster on a rig with 980,970 and 2 750ti's

[sp_]

also, what's the default -i value when one is not specified? I've been testing a few so far and 18.4 seems to be the best of those I've tried so far.

The default "-i" value varies per algorithm.  For x11, it is currently 20.  There is a listing by the author, tpruvot:
https://docs.google.com/spreadsheets/d/1dI1Cc3JhhsA-UdIRlndvQ9huX8FmoJT2TXFDB0wdp54/edit#gid=1086083191
For x11, I get good results with "-i 20.5".       --scryptr

But -i 20.5 sometimes crash on a rig with 6 cards. (out of memory)

[djm34]

Lyra TPB was wrong, i tested 128 when i imported it, but maybe the cpu load was limiting the benefits, 160 seems to give more than 10% on both 750 and 970.

yes. Klaus checked in TPB of 160. I sublitted some more changes@github. 12% faster on a rig with 980,970 and 2 750ti's

it has no influence on the 780ti though, may-be trying to adjust the #number of register would help, I haven't tried though... but I already tried at 128 and 256, made no difference

[Epsylon3]

look like you finally fixed your CRLF commits remains the TAB ones (damn Visual Studio)

[sp_]

My donators want me to optimize quark. so I will try.

[chrysophylax]

Hamsterwheel payment plan-

This sounds interesting.  I have two 6-card 750ti rigs.  DJM34, I'd be willing to point them to your payment address for a crack at running alpha/beta neoscrypt kernels.  My rigs are Ubuntu 14.04.1, 64 bit.  Post something if you are interested.

--scryptr

i think its a good plan ... i do it as its easy ...

and not just to test - but also as a donation just for the great effort that these guys are doing ...

i wish i had all these guys' talent under my umbrella - what a team we could make ...

and i would pay well ... after all - what the hell are we mining for?



#crysx

[chrysophylax]

also, what's the default -i value when one is not specified? I've been testing a few so far and 18.4 seems to be the best of those I've tried so far.

The default "-i" value varies per algorithm.  For x11, it is currently 20.  There is a listing by the author, tpruvot:
https://docs.google.com/spreadsheets/d/1dI1Cc3JhhsA-UdIRlndvQ9huX8FmoJT2TXFDB0wdp54/edit#gid=1086083191
For x11, I get good results with "-i 20.5".       --scryptr

But -i 20.5 sometimes crash on a rig with 6 cards. (out of memory)

im testing this right this minute ...

lets see how long the rig lasts ...

#crysx

[djm34]

Hamsterwheel payment plan-

This sounds interesting.  I have two 6-card 750ti rigs.  DJM34, I'd be willing to point them to your payment address for a crack at running alpha/beta neoscrypt kernels.  My rigs are Ubuntu 14.04.1, 64 bit.  Post something if you are interested.

--scryptr

i think its a good plan ... i do it as its easy ...

and not just to test - but also as a donation just for the great effort that these guys are doing ...

i wish i had all these guys' talent under my umbrella - what a team we could make ...

and i would pay well ... after all - what the hell are we mining for?



#crysx

sorry forgot to answer...
well why not..., I will let you know when I have something...

[chrysophylax]

Hamsterwheel payment plan-

This sounds interesting.  I have two 6-card 750ti rigs.  DJM34, I'd be willing to point them to your payment address for a crack at running alpha/beta neoscrypt kernels.  My rigs are Ubuntu 14.04.1, 64 bit.  Post something if you are interested.

--scryptr

i think its a good plan ... i do it as its easy ...

and not just to test - but also as a donation just for the great effort that these guys are doing ...

i wish i had all these guys' talent under my umbrella - what a team we could make ...

and i would pay well ... after all - what the hell are we mining for?



#crysx

sorry forgot to answer...
well why not..., I will let you know when I have something...

all good mate ...

its all a matter of time and work ... we all do what we need to do ...

my farm is about to go down in the next couple of days as im doing an 'upgrade' if you want to call it that ...

ALL the amd cards are being pulled and sold - being replaced with nvidia ones ( Gigabyte 750ti OC low profile cards - at the moment ) ...

this means i can have about 3-4 times the amount of cards running with the SAME power draw ... which is quite high for me at the moment ...

so cuda/nvidia/ccminer - x11/neoscrypt/etc - optimization is something i am VERY interested in ...

the two machines that are running the nvidia cards ( one has 5 cards - the other has 6 ) are running very smooth with the -i 20.5 parameter ...

i really look forward to what you guys can come out with ... Wolf0 upped my farm to about 75% what it was with his optimizations running sgminer ...

im waiting in sheer anticipation as to what sort of leaps that can be taken using ccminer/cuda and the 750ti OC boards ...

#crysx

[djm34]

with ccminer-sp, I get rather incessant drop in gpu usage (meaning it goes right to 0 for a very short period then go back to 100% as well as incessant "reset connection".

[Epsylon3]

why do you ask on sp thread about features i made, check my last commits

[djm34]

why do you ask on sp thread about features i made, check my last commits

as it was asked sometimes ago... it would be a lot easier if everything was moved to one thread (ie the original cuda/ccminer thread).
also I as I use sp release and didn't see any post regarding this issue on your thread, I assumed it could be a problem with sp commit...

by the way, would be good if you could point me to the solution to the problem as there is no obvious things linked to that in the commit comments, so I can update manually, because I don't want to recompile again everything as I need to compile for at least 3 compute versions...

[Epsylon3]

the disconnection only happens on buggy pools which sometimes resend the same job (like Hashharder blake and hashlink lyra2)

Hashharder was banning the miner after some duplicated share submits, its why i made that first, hashlink seems to only give some rejects without bans.

I was about doing an optional flag for that, but the main reason is i reset the connection on duplicates to force ask a new job.

https://github.com/tpruvot/ccminer/commit/f08bd79a6eb544ca4e8224f707bb1a016b94dabb

[djm34]

the disconnection only happens on buggy pools which sometimes resend the same job (like Hashharder blake and hashlink lyra2)

Hashharder was banning the miner after some duplicated share submits, its why i made that first, hashlink seems to only give some rejects without bans.

I was about doing an optional flag for that, but the main reason is i reset the connection on duplicates to force ask a new job.

https://github.com/tpruvot/ccminer/commit/f08bd79a6eb544ca4e8224f707bb1a016b94dabb

it also happens on suprnova (less often than verters (hashharder) though)

[sp_]

This happens if you mine with a high intensity. It was fixed by submitting two shares instead of one share. X11,x13,x14,x15 should be fine. Lyra2 is not, since the implementation only find one share.

[djm34]

This happens if you mine with a high intensity. It was fixed by submitting two shares instead of one share. X11,x13,x14,x15 should be fine. Lyra2 is not, since the implementation only find one share.

considering the throughput is much smaller than x11 (or should be) the chance of finding several share in one gpu round is rather small
Is there a way to not use the intensity but just the throughtput (even if it is more user friendly, I find that a bit cryptic)