CCminer(SP-MOD) Modded GPU kernels.

[K1773R]

Just rolled back to release 21, 6% CPU usage against 44% of release 22.

There's release 23 already: https://bitcointalk.org/index.php?topic=826901.msg9976879#msg9976879

does it work with mono?

No idea, and I won't get my hopes up for it ^^" But it works over the network, so another windoze pc or virtualbox with windoze should work.

winblows is no option

Aahw. Well seeing you're a Legendary and you've managed to stick with the game for so long, you'll probably have deeprooted ideals in which Windoze doesn't fit ^^"
Well, I'm sorry to say, but I'm just an autodidact when it comes to programming, IRL I'm an ISP technician, so don't expect that much from me
(/me should've just sticked with java, but no, C# just had to be more powerful )

il try it later with mono if only basic things are used it should be fine.

[Bombadil]

il try it later with mono if only basic things are used it should be fine.

Here's a test-version compiled, if you need it (note, this is not a release ^^"): https://mega.co.nz/#!wZdETYQa!ct5DpGhJ_ZpqdmFGGRLalEhcy8YsKfufDsxmA2eBOUg
There's nothing in rig overview, I know

[scryptr]

Fixed slow cpu. X11,x13,x14,x15,x17, nist, quark. Lyra is still a bit slow but faster than build 22


The 23nd public beta(windows executable) is available here: (29-12-2014)

http://www.filedropper.com/ccminer23

The sourcecode is available here:

https://github.com/sp-hash/ccminer

Post your stats here. Card name/gpu clock/memclock

SP_BUILD23 --

I have some initial results.  First, the following photo has tpruvot's v. 1.5.2-git, a build that has recent improvements but is not the absolute bleeding edge, though I consider it stable:



Second, today's sp_ v23, a version I consider bleeding edge and hope is also stable:



Both results were taken from my slower 6-750ti rig, today.  I am building ccminer sp_ v23 on my faster rig as I post this.

EDIT:  Here is a snap of my faster 6-750ti rig:



--scryptr

[djm34]

some progress on neoscrypt:
750ti: 81kh/s 110kh/s 107kh/s
780ti: 165kh/s 182kh/s 193kh/s
980:   290kh/s 299kh/s 335kh/s
(still doesn't scale right   )

[scryptr]

some progress on neoscrypt:
750ti: 81kh/s 110kh/s 107kh/s
780ti: 165kh/s 182kh/s 193kh/s
980:   290kh/s 299kh/s 335kh/s
(still doesn't scale right   )

DJM34 --

Please explain what you mean by scaling?  Should it reach the same ratio between card models as scrypt?

I.E:      [scrypt kh/s 750ti] / [scrypt kh/s 780ti]  =  [neoscrypt kh/s 750ti] / [neoscrypt kh/s 780ti]

and so forth between other model levels.

Actually, CBuchner said his released "Killer Groestl" code was supposed to be deliberately difficult to port to AMD.  Perhaps this code is in a similar vein.       --scryptr

[djm34]

some progress on neoscrypt:
750ti: 81kh/s 110kh/s 107kh/s
780ti: 165kh/s 182kh/s 193kh/s
980:   290kh/s 299kh/s 335kh/s
(still doesn't scale right   )

DJM34 --

Please explain what you mean by scaling?  Should it reach the same ratio between card models as scrypt?

I was expecting something different... but actually it looks like sp_ x11 in terms of scaling

I.E:      [scrypt kh/s 750ti] / [scrypt kh/s 780ti]  =  [neoscrypt kh/s 750ti] / [neoscrypt kh/s 780ti]

and so forth between other model levels.

Actually, CBuchner said his released "Killer Groestl" code was supposed to be deliberately difficult to port to AMD.  Perhaps this code is in a similar vein.       --scryptr

not sure what you mean here...

[scryptr]

DJM34 --

Perhaps the original author of neoscrypt code meant for it to be difficult to port to nVidia.

I guess, since this is ccminer code, x11 would be more appropriate for a comparison.  Does the scaling refer to relative hash power of nVidia models?       --scryptr

[scryptr]

DJM34 --

Perhaps the original author of neoscrypt code meant for it to be difficult to port to nVidia.

I guess, since this is ccminer code, x11 would be more appropriate for a comparison.  Does the scaling refer to relative hash power of nVidia models?       --scryptr

No, I didn't make it hard to port to Nvidia, I optimized it for GCN cards, though.

Thanks for the answer.  I look forward to seeing neoscrypt on nVidia.  It's difficult to keep my 280x rig in shape, the algo-switching sgminer 5.x crashed on switching and even single algorithm mining is rough.  I think one of my 280x cards is ready for warranty service.  I get about 6.6mh/s per card at my current tweak for x11.       --scryptr

[djm34]

DJM34 --

Perhaps the original author of neoscrypt code meant for it to be difficult to port to nVidia.

? still not sure why you are saying that...  
and actually doesn't seem to be the case, actually the 980 already beats the 290x/public kernel... (which is around 300kh/s)

[chrysophylax]

DJM34 --

Perhaps the original author of neoscrypt code meant for it to be difficult to port to nVidia.

I guess, since this is ccminer code, x11 would be more appropriate for a comparison.  Does the scaling refer to relative hash power of nVidia models?       --scryptr

No, I didn't make it hard to port to Nvidia, I optimized it for GCN cards, though.

Thanks for the answer.  I look forward to seeing neoscrypt on nVidia.  It's difficult to keep my 280x rig in shape, the algo-switching sgminer 5.x crashed on switching and even single algorithm mining is rough.  I think one of my 280x cards is ready for warranty service.  I get about 6.6mh/s per card at my current tweak for x11.       --scryptr

agreed ... i have a about 9 of my cards for warranty and 6 to throw out ( purchased via ebay - which ill never do again as gigabyte have a 3year warranty on their cards ) ...

for some reason it the AMD cards that seem to have the most issues with failing ...

#crysx

[scryptr]

DJM34 --

Perhaps the original author of neoscrypt code meant for it to be difficult to port to nVidia.

? still not sure why you are saying that...  
and actually doesn't seem to be the case, actually the 980 already beats the 290x/public kernel... (which is around 300kh/s)

Wolf0 answered for you.  I thought that the code for neoscrypt may have been obfuscated deliberately in order to hinder its porting to Cuda code, perhaps in response to CBuchner's release of difficult-to-port "Killer Groestl".  I'm wondering why development for nVidia is behind, but I am not slighting your efforts.

What I asked originally, though, was what the "scaling" referred to, a proportional scale of nVidia model kh/s rate / nVidia model kh/s rate, or perhaps nVidia model rate / AMD model rate.  Or something else, like iterations within the code.  I don't know, I look at the code and wish I understood it better.       --scryptr

[djm34]

DJM34 --

Perhaps the original author of neoscrypt code meant for it to be difficult to port to nVidia.

? still not sure why you are saying that...  
and actually doesn't seem to be the case, actually the 980 already beats the 290x/public kernel... (which is around 300kh/s)

Wolf0 answered for you.  I thought that the code for neoscrypt may have been obfuscated deliberately in order to hinder its porting to Cuda code, perhaps in response to CBuchner's release of difficult-to-port "Killer Groestl".  I'm wondering why development for nVidia is behind, but I am not slighting your efforts.

because there is no bounty and no deadline  (and paid project or project which are profitable to me have the priority... ).

actually regarding the code, I could have chosen the original code over Wolf0, so there is nothing obfuscated for nvidia, it is just a choice I made (and I was interested too to import those vector type to cuda, as I was already thinking about it since quite some time)

[chrysophylax]

DJM34 --

Perhaps the original author of neoscrypt code meant for it to be difficult to port to nVidia.

? still not sure why you are saying that... 
and actually doesn't seem to be the case, actually the 980 already beats the 290x/public kernel... (which is around 300kh/s)

Wolf0 answered for you.  I thought that the code for neoscrypt may have been obfuscated deliberately in order to hinder its porting to Cuda code, perhaps in response to CBuchner's release of difficult-to-port "Killer Groestl".  I'm wondering why development for nVidia is behind, but I am not slighting your efforts.

because there is no bounty  (and paid project or project which are profitable have the priority... )

in that case - what would it take to 'work' on this project to make it worth its weight in gold?

i would be happily pointing my miners to 'donate' for such a project ...

or is there something that could be done in private that would benefit the contributors 'first' before a public release of such optimized code?

#crysx

[djm34]

DJM34 --

Perhaps the original author of neoscrypt code meant for it to be difficult to port to nVidia.

? still not sure why you are saying that... 
and actually doesn't seem to be the case, actually the 980 already beats the 290x/public kernel... (which is around 300kh/s)

Wolf0 answered for you.  I thought that the code for neoscrypt may have been obfuscated deliberately in order to hinder its porting to Cuda code, perhaps in response to CBuchner's release of difficult-to-port "Killer Groestl".  I'm wondering why development for nVidia is behind, but I am not slighting your efforts.

because there is no bounty  (and paid project or project which are profitable have the priority... )

in that case - what would it take to 'work' on this project to make it worth its weight in gold?

i would be happily pointing my miners to 'donate' for such a project ...

or is there something that could be done in private that would benefit the contributors 'first' before a public release of such optimized code?

#crysx

I am wondering actually... how I will proceed.
1st solution one bounty address for public release, when the amount requested is reached the miner is released for everybody
2st a bounty address for private release once the amount is reached those who pledge for the private miner, gets the miner.
well it is always possible to contact me and propose something...

[scryptr]

DJM34 --

Perhaps the original author of neoscrypt code meant for it to be difficult to port to nVidia.

? still not sure why you are saying that...  
and actually doesn't seem to be the case, actually the 980 already beats the 290x/public kernel... (which is around 300kh/s)

Wolf0 answered for you.  I thought that the code for neoscrypt may have been obfuscated deliberately in order to hinder its porting to Cuda code, perhaps in response to CBuchner's release of difficult-to-port "Killer Groestl".  I'm wondering why development for nVidia is behind, but I am not slighting your efforts.

because there is no bounty   (and paid project or project which are profitable have the priority... )

in that case - what would it take to 'work' on this project to make it worth its weight in gold?

i would be happily pointing my miners to 'donate' for such a project ...

or is there something that could be done in private that would benefit the contributors 'first' before a public release of such optimized code?

#crysx

I am wondering actually... how I will proceed.
1st solution one bounty address for public release, when the amount requested is reached the miner is released for everybody
2st a bounty address for private release once the amount is reached those who pledge for the private miner, gets the miner.
well it is always possible to contact me and propose something...

My two-bits worth --

Public miner!  I would contribute, by hamster-wheel mining, or by dipping into my wallet.  There are hot-rod coders, and there are careful coders, but if the code is not shared, it doesn't get the best wax job.       --scryptr

EDIT: We could perhaps agree on how long my nVidia rigs should mine with your code, pre-release, pointed at your address.  I could agree to keep the code confidential.       --scryptr

[scryptr]

SP_ Build 23 --

I compiled and ran sp_ build 23 today, starting a run at about 1615hrs.  At 2115hrs I noticed it had crashed on my slower rig.  However, my faster rig is running build 23 steadily at the same improved hashing rate as yesterday with build 22, and as earlier today with build 23.
 
I have since restarted build 23 on my slower rig.  It is running ok, but both rigs are headless.  I guess I need to start looking at ccmonitor by KBomba.       --scryptr

[maxim000]

good day

23-th version automaticly change -f multiplier to 0.67 even thouse it is set in 1.0 in bat file - it`s normal ?
so my hash rate in pool significantly lose





also one of two my farms on 750Ti crashe after half hour working

[sp_]

good day
23-th version automaticly change -f multiplier to 0.67 even thouse it is set in 1.0 in bat file - it`s normal ?
so my hash rate in pool significantly lose
also one of two my farms on 750Ti crashe after half hour working

Thanks for finding this, this might be the bug we are looking for. Some pools report a drop in performance.

The crashes are known, and can be fixed by a failover script like this one:

https://github.com/KBomba/failover-ccminer-bat

[maxim000]

The crashes are known, and can be fixed by a failover script like this one:

https://github.com/KBomba/failover-ccminer-bat

thanks !

Thanks for finding this, this might be the bug we are looking for. Some pools report a drop in performance.

it happens often when pool stratum difficulty increase too mach and too quickly, for examle from 0.03 to 4 for one step.
I`m saw it frequently on stratum+tcp://src.coinmine.pl:6020

i think good idea to fix this value if it strict appear in bat file


upd.  also this bag appear in previous versions, compiled by http://cryptomining-blog.com/ , for example from http://cryptomining-blog.com/4085-updated-windows-binary-of-the-ccminer-1-5-2-git-fork-by-sp-for-maxwell/

[sp_]

DJM34 --
Please explain what you mean by scaling?  Should it reach the same ratio between card models as scrypt?

I was expecting something different... but actually it looks like sp_ x11 in terms of scaling

The problem with the 750ti cards is that they use so little power. When you optimize the code, the card sometimes downclock itself automaticly and the hashrate will drop.
This is why I have reduced the number of threads in many of the hashing functions. In BMW f.ex I only use 32 threads. On 970/980 on the other hand, more threads increase the performance.