CCminer(SP-MOD) Modded GPU kernels.

[myagui]

@djm34:
I think the logic proposed was that some trusted party/escrow was holding the bounty, so that any dev could come up and claim it with a working faster version. Was not so much about trusting the dev, as it was about allowing multiple devs to compete for the collected funds.

Personally, I'm not sure it is a great idea, since it brings even more developer competition into the table, instead of focusing on collaboration. I dunno, maybe I'm just a dreamer...  

Edit: I stand by my suggestion from the other day. I thought it would at least garner some comments, but I take it that it was not interesting in other people's views. Oh well... 

[scryptr]

- Regarding developer work -

We should simply have a trusted escrow BTC address where we donate money to for a CERTAIN algo.

Once the dev thinks the escrow is worth grabbing he makes his work/code available as open source.
If it never reaches the threshold the dev thinks it's worth, then the escrow guy will refund the donators.

I would bet that a few btc would come together for each release.



This escrow model should be in BTC !!!
For smaller coins a % fee is utterly devastating to the coin itself cuz one guy (the miner dev) can dump below market price forever.


- EXAMPLE -

eg. djm tells us that his lyra2v2 miner does 6 MH
public miner does 4.5 MH

We open up a unique BTC escrow address where everyone can "donate" to.
Everyone can follow the BTC amount in a block explorer.

Once the dev feels comfortable to release the code he will do so,
if not so be it, someone else will probably grab the escrow soon enough.

INTERESTING--

Although DJM34 had a personal fund when he was developing Neoscrypt for Cuda.  Bottom line is, I donate when a coder does a good job and contributes to the code base.  I never left a coder out, even when the code was absorbed by another coder...

Donate when a good job is done, and make sure not to leave out a contributor.

The escrow fund is a good idea, but is less secure than a direct donation when the job is done.  DJM34's crowd funding effort seemed to work, the fund was near 2 BTC when he released his code.  If a coder out there has the talent to really increase CCminer capacity, a "prize pool" might be a good idea.

--scryptr

[Slava_K]

Commit 1004 - quark is broken... Lyra2v2 on pool side is stable! But hashrate is 2 times slower...

[scryptr]

RELEASE dot 64--

Quark mines at 10.7Mh/s on my Win 7 box with the GTX 960 SSC.  I've enabled "cpu-priority" of 5, and set "cpu-mining" as true.  I also increased the intensity to 24.3, which was too high for previous versions.

These are initial results, I haven't been mining for several hours yet.  The desktop is a little slow, there is noticable lag as I type this.  But CCminer started right up, the initial accepted hash was over 10.7Mh/s, an improvement of ~100kh/s.

I'll compile the release for Linux and try my other rigs out later.  I still haven't maxed out the intensity setting yet on my Win 7, GTX 960 SSC box.       --scryptr


EDIT:  I bumped the intensity up to 24.5, and went out to  the store.  I came home to ~500 accepts and a 95% accept rate at 10.85Mh/s.  I think I am at the intensity limit, but I haven't tried.  My other rigs are running release dot 62 and getting 99% plus acceptance rates.       --scryptr

[Vita1ico]

.64 Quark 11.2 Mh\s .(+400 kH\s).
Nice release . Option 35% cpu disabled . The additional load on the cpu increases from 0.8 to 4.2 GHs . Increases the growth of consumption watt cpu.

[scryptr]

OVERCLOCKING--

After reducing my intensity setting to 24.3, and overclocking +90core/+90mem, I was also able to achieve 11Mh/s.  I will allow my GTX 960 SSC to run overnight, and will adjust the clock settings more in the morning.

Any load on the computer (browsing, other applications) affects the hash rate.  I'll check more tomorrow.

--scryptr

[chrysophylax]

@djm34:
I think the logic proposed was that some trusted party/escrow was holding the bounty, so that any dev could come up and claim it with a working faster version. Was not so much about trusting the dev, as it was about allowing multiple devs to compete for the collected funds.

Personally, I'm not sure it is a great idea, since it brings even more developer competition into the table, instead of focusing on collaboration. I dunno, maybe I'm just a dreamer...  

Edit: I stand by my suggestion from the other day. I thought it would at least garner some comments, but I take it that it was not interesting in other people's views. Oh well... 

hence myagui - why i am now sitting back - watching - reading - absorbing - planning - and doing ...

a few more days and i will have it all ready ... it is taking much more time than i expected ...

then when thats done - to implement the second half of the donation links - and find a dev that is willing to help ( yes - that means getting paid also ) with the multipools that i need done ...

the third is to implement thefarm ... but im leaving that till all the rest is done first ...

great ideas floating about - with some that could well be a good way to go ... but im just going to move forward with what im implementing and hope ( yes - i said it - hope ) that it will attract a few more players into the crypto donation scene ...

without us miners - there is no need for the developers to worry about the mining software ... and without the developers - us miners couldnt run as well as we do ... so we feed and need from each other ... i believe we all need to work together somehow - and when we find that way - it will be well worth the effort ...

time to start implementing ways - then see which ones work ... AND make sure that the work put into all this - is not a waste of time for any of us ... ALL things here depend on the cooperation of one another and so far - we seem to be too worried about 'how much' we are all getting out of it ... even though that is an important factor - the fact remains that we ARE working with each other in this - by way of developing ( devs ) and test ( community ) and donations ( miners ) ... so if we can streamline this and get more people involved - especially the 'big' players while the 'small' players work together to become a 'bigger player amalgamate' - the we will all be getting something in the end ... with the feeling of satisfaction for helping one another as well as coin ...

back to work for me ... then sleep ...

keep up the great work devs ...

#crysx

[chrysophylax]

OVERCLOCKING--

After reducing my intensity setting to 24.3, and overclocking +90core/+90mem, I was also able to achieve 11Mh/s.  I will allow my GTX 960 SSC to run overnight, and will adjust the clock settings more in the morning.

Any load on the computer (browsing, other applications) affects the hash rate.  I'll check more tomorrow.

--scryptr

nice figures ...

i will be looking more in depth with thefarm at the latest commit next week with thefarm ...

too much on in the next few days unfortunately for me ...

#crysx

[pallas]

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

[Cryptozillah]

Release 61 still fastest for Quark on my 750Ti rigs (Win8.1)

[sp_]

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

revert this commit:

https://github.com/sp-hash/ccminer/commit/7a47e66fadc788fc2ec3e6b88c2e01277e1c30c9

I commented out the max64 < minmax check's to debug the lyra2v2 problems. and accedently checked it in. Got late last night..

       /* on start, max64 should not be 0,
        *    before hashrate is computed */
   
      /*
       if (max64 < minmax) {
          switch (opt_algo) {
          case ALGO_KECCAK:

[pallas]

revert this commit:

https://github.com/sp-hash/ccminer/commit/7a47e66fadc788fc2ec3e6b88c2e01277e1c30c9

I commented out the max64 < minmax check's to debug the lyra2v2 problems. and accedently checked it in. Got late last night..

       /* on start, max64 should not be 0,
        *    before hashrate is computed */
   
      /*
       if (max64 < minmax) {
          switch (opt_algo) {
          case ALGO_KECCAK:

thanks, that fixed the crash :-)

[tbearhere]

 sp  could you please put the http protocol back in the source code. I can't wallet mine. And djm lyra2v2 is the same. thx    

Well I still can't wallet mine with latest versions.  http protocol failed.

[bensam1231]

@djm34:
I think the logic proposed was that some trusted party/escrow was holding the bounty, so that any dev could come up and claim it with a working faster version. Was not so much about trusting the dev, as it was about allowing multiple devs to compete for the collected funds.

Personally, I'm not sure it is a great idea, since it brings even more developer competition into the table, instead of focusing on collaboration. I dunno, maybe I'm just a dreamer...  

Edit: I stand by my suggestion from the other day. I thought it would at least garner some comments, but I take it that it was not interesting in other people's views. Oh well... 

Considering there really isn't any competition or collaboration, either would be preferable.

Also with what he suggested, there was no target before the 'funds' would be released to whoever was trying to claim them. IE anyone could offer a tiny improvement and then claim them.

% based miner still is the best method.

[sp_]

 sp  could you please put the http protocol back in the source code. I can't wallet mine. And djm lyra2v2 is the same. thx    

Well I still can't wallet mine with latest versions.  http protocol failed.

Does it work in the 1.6.6 fork by tvpruvot?

[tbearhere]

 sp  could you please put the http protocol back in the source code. I can't wallet mine. And djm lyra2v2 is the same. thx    

Well I still can't wallet mine with latest versions.  http protocol failed.

Does it work in the 1.6.6 fork by tvpruvot?

I don't know sp . Do you mean 1.5.64   ?
EDIT: With r64  no it doesn't work.....r43 works.

[djm34]

  sp  could you please put the http protocol back in the source code. I can't wallet mine. And djm lyra2v2 is the same. thx   

Well I still can't wallet mine with latest versions.  http protocol failed.

Does it work in the 1.6.6 fork by tvpruvot?

I don't know sp . Do you mean 1.5.64   ?

my version works with solomining (and was tested with...) so it is probably on your hand (wrong rpc port, username or password)

[tbearhere]

  sp  could you please put the http protocol back in the source code. I can't wallet mine. And djm lyra2v2 is the same. thx   

Well I still can't wallet mine with latest versions.  http protocol failed.

Does it work in the 1.6.6 fork by tvpruvot?

I don't know sp . Do you mean 1.5.64   ?

my version works with solomining (and was tested with...) so it is probably on your hand (wrong rpc port, username or password)

r43 works  but 50 on up doesn't. I don't get it. Should I leave out the dll files in the new releases ?

[sp_]

Download the latest from the tpruvot forrk:

https://github.com/tpruvot/ccminer/releases


does it work to solomine?

[tbearhere]

Download the latest from the tpruvot forrk:

https://github.com/tpruvot/ccminer/releases


does it work to solomine?

Ok I'll try ....thats what I'm trying to do is solomine.

EDIT: They won't download.