CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 963.

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: hashbrown9000 on August 30, 2015, 01:15:43 AM

linux guys, check out the kopiemtu thread on litecoin.org. i solved the overclocking multiple cards issue around page 60-65 or so. i run driver 346.59 and cuda 6.5

I finally got OC and fan control on a second card. I initially tried a dummy plug but that didn't work.
However, with the dummy plug still connected to the second card I was able to get coolbits to
work by doing the following:

nvidia-xconfig -a

edit xorg.conf to add the following to each screen section:

Option "AllowEmptyInitialConfiguration" "True"
Option "Coolbits" "12"

This is essentially the same procedure referenced by hashbrown,, without the detailed explanation.
He states a monitor needs to be connected for the initial config so I think the dummy plug was useful.
It still works after removing the plug.

Thanks.

Schleicher

hero member

Activity: 675

Merit: 514

Quote from: sp_ on September 03, 2015, 11:09:46 AM

Quote from: Schleicher on September 03, 2015, 10:56:10 AM

ccminer actually crashed:

Quote

Unhandled exception at 0x00C99824 in ccminer.exe: Stack cookie instrumentation code detected a stack-based buffer overrun.

same crash if you run ccminer with a paramater that is not recognized.. like

ccminer --not-implemented

crash. Doesn't exit properly on windows.

Without --no-gbt it crashes too:

Code:

[2015-09-03 18:18:28] 1 miner thread started, using 'quark' algorithm.
[2015-09-03 18:18:28] Binding thread 0 to cpu 0 (mask 1)
[2015-09-03 18:19:37] GPU #0: GeForce GTX 970, 14004
[2015-09-03 18:20:49] GPU #0: GeForce GTX 970, 13897
[2015-09-03 18:22:16] GPU #0: GeForce GTX 970, 13907
[2015-09-03 18:23:37] GPU #0: GeForce GTX 970, 13879
[2015-09-03 18:24:52] GPU #0: GeForce GTX 970, 13712
[2015-09-03 18:26:02] GPU #0: GeForce GTX 970, 13762
[2015-09-03 18:26:57] JSON-RPC call failed: Invalid parameter
[2015-09-03 18:26:57] submit_upstream_work json_rpc_call failed

I think it happens when ccminer is trying to send a result.

NiceHashSupport

hero member

Activity: 588

Merit: 501

Quote from: sp_ on September 03, 2015, 11:08:30 AM

Quote from: NiceHashSupport on September 03, 2015, 10:48:57 AM

If you use old/wrong principle where new diff is immediately applied, your miners will be loosing few percent of hashrate on NiceHash and causing slight rejects with share above target.

Yes and this is a problem since the threads continue to mine for a while and send results. T Nelson and Pallas have submitted some changes to make the miner exit quicker. Hopefully the next ccminer will be bether.

I do not think you understood me what I wrote, please read again.

Here is more about this: https://bitcointalksearch.org/topic/m.12165885 (with example what is wrong)

We submitted this even to official cgminer, at first, they included the patch, but later revoked as there are many pools that don't work correctly, even ckpool. And since creators of ckpool = creators of cgminer, patch will probably never be in cgminer.

But hopefully, you will not make the same mistake.

sp_

legendary

Activity: 2954

Merit: 1087

Team Black developer

Quote from: Schleicher on September 03, 2015, 10:56:10 AM

ccminer actually crashed:

Quote

Unhandled exception at 0x00C99824 in ccminer.exe: Stack cookie instrumentation code detected a stack-based buffer overrun.

same crash if you run ccminer with a paramater that is not recognized.. like

ccminer --not-implemented

crash. Doesn't exit properly on windows.

sp_

legendary

Activity: 2954

Merit: 1087

Team Black developer

Quote from: NiceHashSupport on September 03, 2015, 10:48:57 AM

If you use old/wrong principle where new diff is immediately applied, your miners will be loosing few percent of hashrate on NiceHash and causing slight rejects with share above target.

Yes and this is a problem since the threads continue to mine for a while and send results. T Nelson and Pallas have submitted some changes to make the miner exit quicker. Hopefully the next ccminer will be bether.

Schleicher

hero member

Activity: 675

Merit: 514

Quote from: tbearhere on September 03, 2015, 07:50:40 AM

Quote from: djm34 on September 03, 2015, 07:20:09 AM

Quote from: tbearhere on September 03, 2015, 06:21:08 AM

Quote from: djm34 on September 03, 2015, 05:26:20 AM

Quote from: tbearhere on September 03, 2015, 05:14:01 AM

Quote from: sp_ on September 03, 2015, 05:10:06 AM

Quote from: tbearhere on September 03, 2015, 04:59:32 AM

Quote from: tbearhere on September 01, 2015, 06:55:20 AM

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

)

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

I have tested solo mining Quarkcoin with release 64 now on my system.
Command line: ccminer -O name:password -o http://localhost:8372 -a quark --no-gbt
This happened:

ccminer actually crashed:

Quote

Unhandled exception at 0x00C99824 in ccminer.exe: Stack cookie instrumentation code detected a stack-based buffer overrun.

djm34

legendary

Activity: 1400

Merit: 1050

Quote from: kama on September 03, 2015, 10:46:03 AM

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 may be it can be mingw32 too

actually the compilation is done with nvcc not visual studio compiler and it would still be the case with mingw32 or 64 (unless you recompile cuda entirely...)

sp_

legendary

Activity: 2954

Merit: 1087

Team Black developer

Quote from: kama on September 03, 2015, 10:46:03 AM

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

x86 builds are always faster on windows. 32bit.

The latest cuda compiler (7.5 rc1) shows a drop in hashrate of 10% in 64 bit and 30% in 32 bit. (x11)

NiceHashSupport

hero member

Activity: 588

Merit: 501

Quote from: sp_ on September 03, 2015, 10:36:55 AM

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.

I hope you know that by stratum specifications, when miner receives new diff, that diff shall be used for every next job. And NOT current jobs as so many miners (even official cgminer) and many pools work wrong way.

When coding a miner, it is simply best to have another variable in job/work structure called diff. Compare each share to this diff.

When pool provides new diff, you just save this diff and apply it to every next job that arrives.

If you make it like this (by official stratum specifications), you will also reach maximum efficiency on NiceHash.

If you use old/wrong principle where new diff is immediately applied, your miners will be loosing few percent of hashrate on NiceHash and causing slight rejects with share above target.

kama

full member

Activity: 140

Merit: 100

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

sp_

legendary

Activity: 2954

Merit: 1087

Team Black developer

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.

t-nelson

member

Activity: 70

Merit: 10

Quote from: sp_ on September 03, 2015, 09:17:08 AM

Quote from: djm34 on September 03, 2015, 08:31:09 AM

Quote from: t-nelson on September 03, 2015, 08:25:25 AM

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_

legendary

Activity: 2954

Merit: 1087

Team Black developer

Quote from: djm34 on September 03, 2015, 08:31:09 AM

Quote from: t-nelson on September 03, 2015, 08:25:25 AM

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.

pallas

legendary

Activity: 2716

Merit: 1094

Black Belt Developer

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.

t-nelson

member

Activity: 70

Merit: 10

Quote from: djm34 on September 03, 2015, 08:31:09 AM

Quote from: t-nelson on September 03, 2015, 08:25:25 AM

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

djm34

legendary

Activity: 1400

Merit: 1050

Quote from: t-nelson on September 03, 2015, 08:25:25 AM

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

djm34

legendary

Activity: 1400

Merit: 1050

Quote from: tbearhere on September 03, 2015, 07:50:40 AM

Quote from: djm34 on September 03, 2015, 07:20:09 AM

Quote from: tbearhere on September 03, 2015, 06:21:08 AM

Quote from: djm34 on September 03, 2015, 05:26:20 AM

Quote from: tbearhere on September 03, 2015, 05:14:01 AM

Quote from: sp_ on September 03, 2015, 05:10:06 AM

Quote from: tbearhere on September 03, 2015, 04:59:32 AM

Quote from: tbearhere on September 01, 2015, 06:55:20 AM

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

)

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

t-nelson

member

Activity: 70

Merit: 10

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

legendary

Activity: 1400

Merit: 1050

Quote from: pallas on September 03, 2015, 07:41:30 AM

Quote from: djm34 on September 03, 2015, 07:20:09 AM

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

tbearhere

legendary

Activity: 3164

Merit: 1003

Quote from: djm34 on September 03, 2015, 07:20:09 AM

Quote from: tbearhere on September 03, 2015, 06:21:08 AM

Quote from: djm34 on September 03, 2015, 05:26:20 AM

Quote from: tbearhere on September 03, 2015, 05:14:01 AM

Quote from: sp_ on September 03, 2015, 05:10:06 AM

Quote from: tbearhere on September 03, 2015, 04:59:32 AM

Quote from: tbearhere on September 01, 2015, 06:55:20 AM

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

)

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

Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 963. (Read 2347664 times)