CCminer(SP-MOD) Modded GPU kernels.

[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.

[scryptr]

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.

     

Hmmmmm... that may explain why my slower rig slows down to a crawl and then dies.  I found it barely hashing after restarting it at good speed 5 hours ago.  Should I not use the intensity flag?       --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   )

Let me know when the 980 hits 600kh/s.  

I haven't finished yet to clean the code... Is this what you get with your private kernel ?

Ok here what I am thinking regarding the public release of the nvidia miner for neoscrypt:
Pledge for the bounty will have to be sent to that BTC address: 18UZRrybgjmR4M53Aca4Q8YBguqErZ5qaP

The miner will be publicly released once 5btc has been reached.

It looks like a lot, but it isn't much if everyone participate. Now if only a bunch of people allows to reach that amount or if only a few donates, then the miner will be released privately only to those who pledge.
I think it is fair this way, it is a crowd funding project, which means everyone has to participate and give a tiny bit, it may also protect coin value...
(I'll make a new thread when I was a minute)
 

[Amph]

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   )

Let me know when the 980 hits 600kh/s.  

you beat amd with your own miner on neoscrypt?

[sp_]

Hmmmmm... that may explain why my slower rig slows down to a crawl and then dies.  I found it barely hashing after restarting it at good speed 5 hours ago.  Should I not use the intensity flag?       --scryptr

No this must be something else. My miners run without the intensity flag. The head on github is untested on linux, so there might be some issues.