20-30% lower estimates. Isn't zpool using the same software as yiimp? Why are the estimates so different..?
Topic: [ANN] ccminer 2.3 - opensource - GPL (tpruvot) - page 102. (Read 500113 times)
24 hours estimates differences between zpool and yiimp.
20-30% lower estimates. Isn't zpool using the same software as yiimp? Why are the estimates so different..?
20-30% lower estimates. Isn't zpool using the same software as yiimp? Why are the estimates so different..?
Nice 
No ideas for the android app ?
No ideas for the android app ?
might give a re-try on zcoin
Do you know of any good app on android to monitor CCminer (i tried a few SG/CG miner compatible one (same API if i understood you correctly ? but they weren't very good and haven't been updated for years)
Also are you going reconsider adding Zcoin back to yiimp now that the network/wallet seems to be alot more stables ? would love to have this coin on yiimp.
Thanks
Also are you going reconsider adding Zcoin back to yiimp now that the network/wallet seems to be alot more stables ? would love to have this coin on yiimp.
Thanks
the "|" separator is made to be compatible with telnet, same protocol is used in cgminer and sgminer if you query them via sockets. I will not change that
Okay, thanks anyway.
the "|" separator is made to be compatible with telnet, same protocol is used in cgminer and sgminer if you query them via sockets. I will not change that
For people struggling with the lbry algo and card being stuck (maybe im the only one aside from that linux guy earlier but whatever), here is the solution i came up with, it's not super elegant, but it work 100% of the time.
Do a conf for the algo instead of a command line.
LBC.conf
As you can see i put in setup a pool that only last for 10sec, after it will go to the 2nd one, you can also of course add pools for failsafe mesures. Since switching pool automatically unlock the locked GPU threads, 10 sec after miner start, it will change pool, and unlock threads, work 100% of the time.
@Epsylon3 : i really wish for a json API, and also logging features, would make my monitoring more powerful and easy to make. Those | & ; separated datas are really hard to parse when you begin to drill deep into other API function like threads/hwinfo and so on. Hope my wish will be heard Thanks.
Do a conf for the algo instead of a command line.
LBC.conf
Code:
{
"_note": "2 pool failover & switching enabled",
"pools": [{
"name": "YIIMP-LBC",
"url": "stratum+tcp://yiimp.ccminer.org:3334",
"user": "mywallet",
"pass": "stats",
"max-diff": 0.0,
"scantime": 40,
"disabled": false,
"time-limit": 10
}, {
"name": "MINE-GPU4U-LBC",
"url": "stratum+tcp://mine.gpu4u.eu:3334",
"user": "mywallet",
"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
}As you can see i put in setup a pool that only last for 10sec, after it will go to the 2nd one, you can also of course add pools for failsafe mesures. Since switching pool automatically unlock the locked GPU threads, 10 sec after miner start, it will change pool, and unlock threads, work 100% of the time.
@Epsylon3 : i really wish for a json API, and also logging features, would make my monitoring more powerful and easy to make. Those | & ; separated datas are really hard to parse when you begin to drill deep into other API function like threads/hwinfo and so on. Hope my wish will be heard
Thanks. Team, I am trying to use the API, I have used the search function and found no help on this thread. I have tried -b --api-bind 0.0.0.0:4068 and also -b --api-bind=0.0.0.0:4068 I have tried with 127.0.0.1 and also without the -b. I am using ccminer 1.8.4 How do I get the api page to show up
use -b OR --api-bind= not both
Code:
--api-bind 0.0.0.0:4068
or
Code:
-b 0.0.0.0:4068
Then you can use any raw TCP tool to get the API
Code:
echo help |nc your_mining_rig_ip or localhost 4068
summary
threads
pool
histo
hwinfo
meminfo
scanlog
seturl
quit
Code:
echo summary |nc your_mining_rig_ip or localhost 4068
NAME=ccminer;VER=1.8.4;API=1.8;ALGO=myr-gr;GPUS=6;KHS=390606.38;SOLV=0;ACC=386;REJ=8;ACCMN=55.407;DIFF=377.171377;NETKHS=0;POOLS=1;WAIT=0;UPTIME=418;TS=1487402397
there you go.
nc is netcat, it's a tcp raw tool, it exist on linux, and there are windows port also
Team, I am trying to use the API, I have used the search function and found no help on this thread. I have tried -b --api-bind 0.0.0.0:4068 and also -b --api-bind=0.0.0.0:4068 I have tried with 127.0.0.1 and also without the -b. I am using ccminer 1.8.4 How do I get the api page to show up
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..
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.
Hi. I have the same problem and a couple of days ago i "discovered" that doing a
Code:
strace -f -p $PIDofMiner
Hummm very interesting indeed ! Happy to know im not alone in the world lol
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..
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.
Hi. I have the same problem and a couple of days ago i "discovered" that doing a
Code:
strace -f -p $PIDofMiner
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..
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.
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..
edit: no, only on algo switch, which is not the case here..
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
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.
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
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
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.
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.
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
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
Okay back again with my lbry issue, maybe this one will give you an idea (i've cut the log to keep it compact)
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.
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.
yeah that just tilted in my brain ahah
linux one, for this reason :p
Jump to: