[ANN] ccminer 2.3 - opensource - GPL (tpruvot)

[Epsylon3]

no, the stats are just a submit of the state after 50 shares.. nothing on start and all the threads share the same code :p there is not even a related code in ccminer able to delay 4 of the 6 cards

[1715018398]

1715018398

[1715018398]

1715018398

[m1n1ngP4d4w4n]

no, the stats are just a submit of the state after 50 shares.. nothing on start and all the threads share the same code :p there is not even a related code in ccminer able to delay 4 of the 6 cards

Okay, it doesn't change a thing indeed, well config didn't changed a thing either, can't understand this issue, when i use the debug mode the thread is started and attached to all present gpu's but randomly on one or 2 of them the threads get stuck, and i also noticed that in the order of the gpus, if for example the second one in the list get stuck (gpu #1), the others ones get stuck too. like it's "waiting" for the thread to start to start the others. Again i don't understand why it does that, especially since no other one encounter this issue....

Code:

[2017-02-10 11:59:34] accepted: 86/86 (diff 5.763), 1159.99 MH/s yes!
[2017-02-10 11:59:34] accepted: 87/87 (diff 3.501), 1160.02 MH/s yes!
[2017-02-10 11:59:37] accepted: 88/88 (diff 8.780), 1159.52 MH/s yes!
[2017-02-10 11:59:37] CTRL_C_EVENT received, exiting
[2017-02-10 11:59:37] GPU #2: Intensity set to 23.5, 12582912 cuda threads
Terminate batch job (Y/N)?

As you can see also, when you interrupt the miner, the thread unlock itself.

One unrelated question, i see that you have the ability to switchpool from extended API, how does that work, how do you write a proper config file to do that ? i looked @ the example of the repo, but there isn't switching pools in it.

[Epsylon3]

its a sample "remote api" disabled by default, even with -b which is read-only stats data..

it was made to create dynamically a pool entry and switch to it... as most pools require an user, it require a special format : stratum+tcp://user:pass@host:port

this feature require the --api-remote flag

for pool switching and failover, there is sample pools.conf in the git

[m1n1ngP4d4w4n]

its a sample "remote api" disabled by default, even with -b which is read-only stats data..

it was made to create dynamically a pool entry and switch to it... as most pools require an user, it require a special format : stratum+tcp://user:pass@host:port

this feature require the --api-remote flag

for pool switching and failover, there is sample pools.conf in the git

nice that could be a nice addition to my monitoring and fail over i will do some testings !

[Epsylon3]

ah, look like they finally found the issue, yiimp ip remains between reboots :p

[m1n1ngP4d4w4n]

ah, look like they finally found the issue, yiimp ip remains between reboots :p

Huzzah \o/

[m1n1ngP4d4w4n]

Did a few test with pool switching & failover.

Here is my config

Code:

{
	"_note": "2 pool failover & switching enabled",

	"pools": [{
		"name": "YIIMP-LBC",
		"url": "stratum+tcp://yiimp.ccminer.org:3334",
		"user": "hidden",
		"pass": "stats",
		"max-diff": 0.0,
		"scantime": 40,
		"disabled": false
	}, {
		"name": "MINE-GPU4U-LBC",
		"url": "stratum+tcp://mine.gpu4u.eu:3334",
		"user": "hidden",
		"pass": "stats",
		"max-diff": 0.0,
		"scantime": 40,
		"disabled": false
	}],

	"algo": "lbry",
	"intensity": 23.5,

	"api-bind": "127.0.0.1:4444",
	"api-remote": true,
	"statsavg": 20,

	"quiet": true,
	"debug": false
}

Everything seems to work fine. Automated pool switching (with time-limit or stratum unreachable) or manual through the API work like a charm, a bit lenghty but ok  , could you give me some infos about the pool settings like max-diff and scantime and if there are other useful ones ? Thanks.

On another note i tried to use the miner overclocking feature, but each time i try it, it reply that it can't query my current clock value (something to do with permissions) even though im running it as admin. Any ideas ?

[Epsylon3]

the warning is about pstate with nvml, fixed in the dev branch (2.0)

[m1n1ngP4d4w4n]

Ohhh i didn't knew there was a dev-branch, that explain why i was seeing ccminer 2.0 as a miner in the benchmark on yiimp. Can you share binaries ? I don't have any compiling environment on windows (and usually suck @ compiling stuff on win anyway) Thanks 

[Epsylon3]

i dont have it built on windows for now... its why its a dev branch.. dont want to publish 100 dev versions

[m1n1ngP4d4w4n]

I see no problem man, i'll wait, i'll continue to rely on my usual OC script, they work well how do you access the dev branch by the way ? i checked the github, but didn't saw any branch called dev except the "xmr-dev" thanks.

[Epsylon3]

linux one, for this reason :p

[m1n1ngP4d4w4n]

yeah that just tilted in my brain ahah 

[m1n1ngP4d4w4n]

Okay back again with my lbry issue, maybe this one will give you an idea (i've cut the log to keep it compact)

Code:

[2017-02-15 19:52:46] Adding 4194304 threads to intensity 23, 12582912 cuda threads
[2017-02-15 19:52:46] Starting on stratum+tcp://yiimp.ccminer.org:3334
[2017-02-15 19:52:46] 6 miner threads started, using 'lbry' algorithm.
[2017-02-15 19:52:46] Stratum difficulty set to 32 (0.12500)
[2017-02-15 19:52:47] GPU #5: Intensity set to 23.5, 12582912 cuda threads
[2017-02-15 19:52:47] GPU #4: Intensity set to 23.5, 12582912 cuda threads
[2017-02-15 19:52:47] GPU #2: Intensity set to 23.5, 12582912 cuda threads
[2017-02-15 19:52:48] GPU #0: Intensity set to 23.5, 12582912 cuda threads
[2017-02-15 19:52:48] GPU #3: Intensity set to 23.5, 12582912 cuda threads
[2017-02-15 19:52:50] accepted: 1/1 (diff 0.303), 287.54 MH/s yes!
[2017-02-15 19:52:50] accepted: 2/2 (diff 1.042), 276.25 MH/s yes!
[2017-02-15 19:52:50] accepted: 3/3 (diff 0.194), 281.73 MH/s yes!
[2017-02-15 19:52:50] accepted: 4/4 (diff 0.345), 283.16 MH/s yes!
[[2017-02-15 19:56:45] accepted: 52/52 (diff 1.955), 288.32 MH/s yes!
[2017-02-15 19:56:46] accepted: 53/53 (diff 2.147), 288.40 MH/s yes!
[2017-02-15 19:56:54] accepted: 54/54 (diff 1.432), 288.59 MH/s yes!
[2017-02-15 19:56:55] Switch to stratum pool 1: MINE-GPU4U-LBC
[2017-02-15 19:56:55] GPU #1: Intensity set to 23.5, 12582912 cuda threads
[2017-02-15 19:57:21] Stratum difficulty set to 32 (0.12500)
[2017-02-15 19:57:22] accepted: 1/1 (diff 0.549), 1028.46 MH/s yes!
[2017-02-15 19:57:23] accepted: 2/2 (diff 0.296), 1106.78 MH/s yes!
[2017-02-15 19:57:23] accepted: 3/3 (diff 0.219), 1219.13 MH/s yes!
[2017-02-15 19:57:24] accepted: 4/4 (diff 0.205), 1442.69 MH/s yes!
[2017-02-15 19:57:25] accepted: 5/5 (diff 0.813), 1506.71 MH/s yes!
[2017-02-15 19:58:34] accepted: 176/176 (diff 0.169), 1736.12 MH/s yes!

Im still plagued with the mining threads being stuck, and i noticed that interrupting the miner with ctrl+c free it up, so i tried this time with the switchpool API call, and guess what, it does the same. As soon as the mining process is interrupted the thread is being unlocked and i can mine @ normal speed.

Has that gave you an idea ?  

Many thanks.

[Epsylon3]

nope :p lol, and the only "possible" thread conflict i know was not implemented in 1.8.4 (the new monitor thread)

if this thread is started before the miner ones, it can lock this others.. with recent drivers... but you were not using the 2.0 so its not that

[joblo]

Interesting that you can unlock the thread without killing the entire process, or maybe I misunderstood.

It appears to be a race condition because it runs for a while before locking up. Maybe there's a marginal
synchronization issue that has become more visible. Most synchonization should be in core code, not
algo specific code, unless lbry code diverges altering some critical timing.

[Epsylon3]

nope joblo unrelated... the problem is the card or the driver state for this card which doesn't init it (locks)

"GPU #1: Intensity set to 23.5" should be with the other ones, not 4 minutes after, its made before any other "algo" work

nvidia just ignore me when i report a "very visible" bug... so for one like this.. good luck

[joblo]

nope joblo unrelated... the problem is the card or the driver state for this card which doesn't init it (locks)

GPU #1: Intensity set to 23.5 should be with the other ones, not 4 seconds after

OK, I'll shut up now.

[Epsylon3]

on pool switch a device reset is made... that can explain the start

edit: no, only on algo switch, which is not the case here..

[m1n1ngP4d4w4n]

on pool switch a device reset is made... that can explain the start

edit: no, only on algo switch, which is not the case here..

Well i checked the behavior 10 out of 10 times the locked thread is unlocked by the pool switch

so im gonna use that as monitoring action instead of killing the miner, it's more effective to get maximum hashrate but still i can't understand this bug, i tried out 10 different drivers version, always the same

Thanks for having looked into it anyway.