CCminer(SP-MOD) Modded GPU kernels.

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

I know someone who is using your older version because the new ones won't work solo mining.
maybe cuda build app files have changed ..because about the same time sp releases aren't working either.
I'm going to try an older version of lyra2v2  of yours djm.

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

djm  Just to make sure..what is VTC wallet port?      VERT coin  v0.10.0.0-g7744958-beta
But error is http protocol.

VERTCOIN PORTS--

According to CoinWarz, the P2P Port is 5889 and the RPC Port is 5888.  Older solo-mining guides from the N-Scrypt days have the RPC Port at 9332.   This bit of fogginess is why I never set up solomining.  I should be able to find 2-3 blocks a day solo mining.      --scryptr

Thanks scryptr .. I'm going to try both even though it's a http protocol problem. It can't connect ..but older versions do.

[fenomenhaa]

Release 64 shows less hashtare on GMC pool on lyrav2.turned back to r63(same settings)...

[sp_]

News about the idle gpu issue (leading to lower hashrate on the pool).
I monitored the power usage and when it drops I get this kind of debug output:

[2015-09-03 11:27:42] sleeptime: 500 ms
[2015-09-03 11:27:42] DEBUG: job_id=5e8126d 67b xnonce2=3e000000 time=11:27:09
[2015-09-03 11:27:42] GPU #3: start=99999999 end=9a68f324 range=00cf598b

many times, leading to a sleep time of 10/15 seconds.
meanwhile, the gpus are idle.
it happens more on neoscrypt than quark or x11.

EDIT: the problem is reduced increasing scantime (and vice-versa)

from this code: (ccminer.cpp)

      if (have_stratum)
      {
         uint32_t sleeptime = 0;
         while (!work_done && time(NULL) >= (g_work_time + opt_scantime))
         {
            usleep(100*1000);
            if (sleeptime > 4) {
               extrajob = true;
               break;
            }
            sleeptime++;
         }
         if (sleeptime && opt_debug && !opt_quiet)
         {
            applog(LOG_DEBUG, "sleeptime: %u ms", sleeptime * 100);
         }
            nonceptr = (uint32_t*) (((char*)work.data) + wcmplen);
         pthread_mutex_lock(&g_work_lock);
         extrajob |= work_done;
         if (nonceptr[0] >= end_nonce || extrajob) {
            work_done = false;
            extrajob = false;
            stratum_gen_work(&stratum, &g_work);
         }
      }

[pallas]

News about the idle gpu issue (leading to lower hashrate on the pool).
I monitored the power usage and when it drops I get this kind of debug output:

[2015-09-03 11:27:42] sleeptime: 500 ms
[2015-09-03 11:27:42] DEBUG: job_id=5e8126d 67b xnonce2=3e000000 time=11:27:09
[2015-09-03 11:27:42] GPU #3: start=99999999 end=9a68f324 range=00cf598b

many times, leading to a sleep time of 10/15 seconds.
meanwhile, the gpus are idle.
it happens more on neoscrypt than quark or x11.

EDIT: the problem is reduced increasing scantime (and vice-versa)

from this code: (ccminer.cpp)

      if (have_stratum)
      {
         uint32_t sleeptime = 0;
         while (!work_done && time(NULL) >= (g_work_time + opt_scantime))
         {
            usleep(100*1000);
            if (sleeptime > 4) {
               extrajob = true;
               break;
            }
            sleeptime++;
         }
         if (sleeptime && opt_debug && !opt_quiet)
         {
            applog(LOG_DEBUG, "sleeptime: %u ms", sleeptime * 100);
         }
            nonceptr = (uint32_t*) (((char*)work.data) + wcmplen);
         pthread_mutex_lock(&g_work_lock);
         extrajob |= work_done;
         if (nonceptr[0] >= end_nonce || extrajob) {
            work_done = false;
            extrajob = false;
            stratum_gen_work(&stratum, &g_work);
         }
      }

yes, that's the part of code I'm looking into.
there are some things to say:
- work_done is never set to true (same for other ccminer forks...).
- I'm experiencing this problem since about a week, so there must be something in the last commits.
- the "shorter work leading to hashrate flooding" may be related to this, as I started experiencing the two problems at the same time.

[sp_]

yes, that's the part of code I'm looking into.
there are some things to say:
- work_done is never set to true (same for other ccminer forks...).
- I'm experiencing this problem since about a week, so there must be something in the last commits.
- the "shorter work leading to hashrate flooding" may be related to this, as I started experiencing the two problems at the same time.

yeah, the hastrate flooding is related. The miner is mining ok for 50-100 accepts and then the trouble starts (duplicate shares). If you solve it, you also solve the lyrav2 hashrate with 2 threads per gpu. (-g 2 -i 19.2) Boosts (lyra2v2) on the 750ti to 5MHASH and gtx 970 to 10MHASH.

Perhaps look for a bufferoverflow bug on the stack...

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

djm  Just to make sure..what is VTC wallet port?      VERT coin  v0.10.0.0-g7744958-beta
But error is http protocol.

VERTCOIN PORTS--

According to CoinWarz, the P2P Port is 5889 and the RPC Port is 5888.  Older solo-mining guides from the N-Scrypt days have the RPC Port at 9332.   This bit of fogginess is why I never set up solomining.  I should be able to find 2-3 blocks a day solo mining.      --scryptr

Thanks scryptr .. I'm going to try both even though it's a http protocol problem. It can't connect ..but older versions do.

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

I know someone who is using your older version because the new ones won't work solo mining.
maybe cuda build app files have changed ..because about the same time sp releases aren't working either.
I'm going to try an older version of lyra2v2  of yours djm.

older ? there are 4 releases which are mostly bug correction (and compatibility issues) and none of these changes are related to solo mining.
all are there, and all are working: https://github.com/djm34/ccminer-lyra/releases

regarding solo mining, I don't know what is the default vtc port, I use a custom config file to define which port are used and some other settings.
(make sure as well, that you are using the latest wallet...  )

also I am using --api-bind 0 (as it becomes problematic when there are several instances) and obviously don't use the same port for api-bind and the wallet

edit: there was a changed pushed by pallas to bmw256, however I don't think it would break solo mining, you can probably test that with testnet

[pallas]

edit: there was a changed pushed by pallas to bmw256, however I don't think it would break solo mining, you can probably test that with testnet

does ccminer use the gpu computed block hash for something in solo mining mode?
surely cgminer derivates do not, maybe ccminer is different...

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

I know someone who is using your older version because the new ones won't work solo mining.
maybe cuda build app files have changed ..because about the same time sp releases aren't working either.
I'm going to try an older version of lyra2v2  of yours djm.

older ? there are 4 releases which are mostly bug correction (and compatibility issues) and none of these changes are related to solo mining.
all are there, and all are working: https://github.com/djm34/ccminer-lyra/releases

regarding solo mining, I don't know what is the default vtc port, I use a custom config file to define which port are used and some other settings.
(make sure as well, that you are using the latest wallet...  )

also I am using --api-bind 0 (as it becomes problematic when there are several instances) and obviously don't use the same port for api-bind and the wallet

edit: there was a changed pushed by pallas to bmw256, however I don't think it would break solo mining, you can probably test that with testnet

Ok thank you djm. The other person had to use your version before ver4 to make it work.
But still something happened , related?, to solo mining about the time your oldest version was released I think. Will try your oldest tomorrow.
But to clarify ... sp r43 solo mining a coin works....now with exactly the same bat file and using r55 or r60 or r62 it won't work.
Will try again tomorrow. thx

[djm34]

edit: there was a changed pushed by pallas to bmw256, however I don't think it would break solo mining, you can probably test that with testnet

does ccminer use the gpu computed block hash for something in solo mining mode?
surely cgminer derivates do not, maybe ccminer is different...

no, it just sends the nonce, when it finds one

[t-nelson]

I'm seeing regression in pool-side hash rates as well.

ypool.ca, X11 algo, git at 562f049 with 7a47e66 reverted.

Some fun new (to me) log messages like this:

Code:

[2015-09-03 07:11:42] accepted: 4950/4995 (99.10%), 5218 kH/s yes!
[2015-09-03 07:11:46] GPU #0: GeForce GTX 960, 5224 Temp= 60C Fan= 10%
[2015-09-03 07:11:54] accepted: 4951/4996 (99.10%), 5224 kH/s yes!
[2015-09-03 07:12:00] GPU #0: GeForce GTX 960, 5224 Temp= 60C Fan=  8%
[2015-09-03 07:12:08] nonce ee4b0e00 was already sent 115 seconds ago
[2015-09-03 07:12:10] nonce b6f40e00 was already sent 115 seconds ago
[2015-09-03 07:12:13] nonce 672b0d00 was already sent 115 seconds ago
[2015-09-03 07:12:15] GPU #0: GeForce GTX 960, 5224 Temp= 60C Fan=  6%
[2015-09-03 07:12:20] nonce d34d0700 was already sent 115 seconds ago
[2015-09-03 07:12:23] nonce 9fae0c00 was already sent 115 seconds ago
[2015-09-03 07:12:29] GPU #0: GeForce GTX 960, 5222 Temp= 60C Fan=  5%
[2015-09-03 07:12:29] nonce 223a0300 was already sent 115 seconds ago
[2015-09-03 07:12:33] stratum connection reset
[2015-09-03 07:12:33] mine.xpool.ca:2000 x11 block 330186
[2015-09-03 07:12:34] accepted: 4952/4997 (99.10%), 5223 kH/s yes!
[2015-09-03 07:12:36] GPU #0: GeForce GTX 960, 5224 Temp= 64C Fan=  5%

The drop off is pretty apparent.



I think I'll look into a component-izing refactor as my next contribution.  There are too many globals being tickled all over the show to have confidence that any changes (outside the kernels) aren't going to have side effects.

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

I know someone who is using your older version because the new ones won't work solo mining.
maybe cuda build app files have changed ..because about the same time sp releases aren't working either.
I'm going to try an older version of lyra2v2  of yours djm.

older ? there are 4 releases which are mostly bug correction (and compatibility issues) and none of these changes are related to solo mining.
all are there, and all are working: https://github.com/djm34/ccminer-lyra/releases

regarding solo mining, I don't know what is the default vtc port, I use a custom config file to define which port are used and some other settings.
(make sure as well, that you are using the latest wallet...  )

also I am using --api-bind 0 (as it becomes problematic when there are several instances) and obviously don't use the same port for api-bind and the wallet

edit: there was a changed pushed by pallas to bmw256, however I don't think it would break solo mining, you can probably test that with testnet

Ok thank you djm. The other person had to use your version before ver4 to make it work.
But still something happened , related?, to solo mining about the time your oldest version was released I think. Will try your oldest tomorrow.
But to clarify ... sp r43 solo mining a coin works....now with exactly the same bat file and using r55 or r60 or r62 it won't work.
Will try again tomorrow. thx

sorry but nothing happened at all... (looks to me at some placebo effect...)

[djm34]

I'm seeing regression in pool-side hash rates as well.

ypool.ca, X11 algo, git at 562f049 with 7a47e66 reverted.

Some fun new (to me) log messages like this:

Code:

[2015-09-03 07:11:42] accepted: 4950/4995 (99.10%), 5218 kH/s yes!
[2015-09-03 07:11:46] GPU #0: GeForce GTX 960, 5224 Temp= 60C Fan= 10%
[2015-09-03 07:11:54] accepted: 4951/4996 (99.10%), 5224 kH/s yes!
[2015-09-03 07:12:00] GPU #0: GeForce GTX 960, 5224 Temp= 60C Fan=  8%
[2015-09-03 07:12:08] nonce ee4b0e00 was already sent 115 seconds ago
[2015-09-03 07:12:10] nonce b6f40e00 was already sent 115 seconds ago
[2015-09-03 07:12:13] nonce 672b0d00 was already sent 115 seconds ago
[2015-09-03 07:12:15] GPU #0: GeForce GTX 960, 5224 Temp= 60C Fan=  6%
[2015-09-03 07:12:20] nonce d34d0700 was already sent 115 seconds ago
[2015-09-03 07:12:23] nonce 9fae0c00 was already sent 115 seconds ago
[2015-09-03 07:12:29] GPU #0: GeForce GTX 960, 5222 Temp= 60C Fan=  5%
[2015-09-03 07:12:29] nonce 223a0300 was already sent 115 seconds ago
[2015-09-03 07:12:33] stratum connection reset
[2015-09-03 07:12:33] mine.xpool.ca:2000 x11 block 330186
[2015-09-03 07:12:34] accepted: 4952/4997 (99.10%), 5223 kH/s yes!
[2015-09-03 07:12:36] GPU #0: GeForce GTX 960, 5224 Temp= 64C Fan=  5%

The drop off is pretty apparent.



I think I'll look into a component-izing refactor as my next contribution.  There are too many globals being tickled all over the show to have confidence that any changes (outside the kernels) aren't going to have side effects.

my 50cents:  the miners may find several nonce per loop, and I would bet that it restart mining at the nonce of the 1st one even when it finds a second one, which means it finds it again, in the next iteration.

there never been any real duplicate problem (may-be zrc but it a bit special on itself), just some screw up in the miner...

[t-nelson]

I'm seeing regression in pool-side hash rates as well.

ypool.ca, X11 algo, git at 562f049 with 7a47e66 reverted.

Some fun new (to me) log messages like this:

-- SNIP --

The drop off is pretty apparent.

-- SNIP --

I think I'll look into a component-izing refactor as my next contribution.  There are too many globals being tickled all over the show to have confidence that any changes (outside the kernels) aren't going to have side effects.

my 50cents:  the miners may find several nonce per loop, and I would bet that it restart mining at the nonce of the 1st one even when it finds a second one, which means it finds it again, in the next iteration.

there never been any real duplicate problem (may-be zrc but it a bit special on itself), just some screws up in the miner...

That seems like a reasonable analysis.  I just looked in the code and noticed that those "nonce already sent" logs are gated by

Code:

!opt_quiet

, which I have been using most of the time up until it broke in the last couple days.

I also just noticed one of the CPU miners on the same pool had a stratum timeout at the same time ccminer did, so my issues may be entirely pool-side.  I'll keep an eye on it...

[pallas]

I've submitted a little pull request for better gpu disabling on network failure.
Please check it on stratum as well as solo mining (which I didn't test yet).

EDIT: the first version I did some time ago didn't work on some situations, for example pool timeout instead of disconnect.

EDIT2: people please test it, there are many network types and states, I can't test them all.

[sp_]

I'm seeing regression in pool-side hash rates as well.

ypool.ca, X11 algo, git at 562f049 with 7a47e66 reverted.

Some fun new (to me) log messages like this:

Code:

[2015-09-03 07:11:42] accepted: 4950/4995 (99.10%), 5218 kH/s yes!
[2015-09-03 07:11:46] GPU #0: GeForce GTX 960, 5224 Temp= 60C Fan= 10%
[2015-09-03 07:11:54] accepted: 4951/4996 (99.10%), 5224 kH/s yes!
[2015-09-03 07:12:00] GPU #0: GeForce GTX 960, 5224 Temp= 60C Fan=  8%
[2015-09-03 07:12:08] nonce ee4b0e00 was already sent 115 seconds ago
[2015-09-03 07:12:10] nonce b6f40e00 was already sent 115 seconds ago
[2015-09-03 07:12:13] nonce 672b0d00 was already sent 115 seconds ago
[2015-09-03 07:12:15] GPU #0: GeForce GTX 960, 5224 Temp= 60C Fan=  6%
[2015-09-03 07:12:20] nonce d34d0700 was already sent 115 seconds ago
[2015-09-03 07:12:23] nonce 9fae0c00 was already sent 115 seconds ago
[2015-09-03 07:12:29] GPU #0: GeForce GTX 960, 5222 Temp= 60C Fan=  5%
[2015-09-03 07:12:29] nonce 223a0300 was already sent 115 seconds ago
[2015-09-03 07:12:33] stratum connection reset
[2015-09-03 07:12:33] mine.xpool.ca:2000 x11 block 330186
[2015-09-03 07:12:34] accepted: 4952/4997 (99.10%), 5223 kH/s yes!
[2015-09-03 07:12:36] GPU #0: GeForce GTX 960, 5224 Temp= 64C Fan=  5%

The drop off is pretty apparent.



I think I'll look into a component-izing refactor as my next contribution.  There are too many globals being tickled all over the show to have confidence that any changes (outside the kernels) aren't going to have side effects.

my 50cents:  the miners may find several nonce per loop, and I would bet that it restart mining at the nonce of the 1st one even when it finds a second one, which means it finds it again, in the next iteration.

there never been any real duplicate problem (may-be zrc but it a bit special on itself), just some screw up in the miner...

This is bug I have been tracking, the bug is not present in release 63. After a while the miner will start to work on data it worked on 2 minutes ago. causing duplicate shares) You should get the latest version of the sourcecode though, I disabled the duplicate checking because it slows down the mining. Bether to let the pool find out and reset the connection.

In release 64, Lya2v2 seems to be affected. Quark is fine.

edit: It doesn't happen on pools/coins wich is switching blocks or difficulty rapidly.

[t-nelson]

I'm seeing regression in pool-side hash rates as well.

ypool.ca, X11 algo, git at 562f049 with 7a47e66 reverted.

Some fun new (to me) log messages like this:

-- SNIP --

The drop off is pretty apparent.

-- SNIP --

I think I'll look into a component-izing refactor as my next contribution.  There are too many globals being tickled all over the show to have confidence that any changes (outside the kernels) aren't going to have side effects.

my 50cents:  the miners may find several nonce per loop, and I would bet that it restart mining at the nonce of the 1st one even when it finds a second one, which means it finds it again, in the next iteration.

there never been any real duplicate problem (may-be zrc but it a bit special on itself), just some screw up in the miner...

This is bug I have been tracking, the bug is not present in release 63. After a while the miner will start to work on data it worked on 2 minutes ago. causing duplicate shares) You should get the latest version of the sourcecode though, I disabled the duplicate checking because it slows down the mining. Bether to let the pool find out and reset the connection.

In release 64, Lya2v2 seems to be affected. Quark is fine.

edit: It doesn't happen on pools/coins wich is switching blocks or difficulty rapidly.

Yup.  I'm seeing a bunch of dupe shares now at HEAD.  It seems to start ~2min after the last difficulty adjustment, like you suggest.  https://github.com/sp-hash/ccminer/blob/windows/ccminer.cpp#L1974  is starting to look suspect...

[sp_]

Found the bug I think. I put the reset flag in the change difficulty method in utils.cpp. Again testing something and it got commited. There is a problem when the pool is changeing the difficulty rapidly. ccminer will submit shares with the old difficulty, and you get reject rates.. Try lyra2v2 on p2pool.pl 5% reject rate.

[kama]

sp_ i want to ask you something buddy

why don't you compile it with mingw64 for windows ? it is more good than visual studio's compiler because the program that compiled with mingw64 gives more good hashrate or it can be mingw32 too