i am using GTX 1050 4g
You need a GPU with more than 4 GB.
So most other cards will work? ...
As long as 4GB RAM is available for processing?
#crysx
Topic: ccminer 1.2.0/sgminer 0.1.3 for MTP: Fastest MTP miner for nvidia cards (Read 4614 times)
October 18, 2020, 01:57:36 AM
You need a GPU with more than 4 GB.
So most other cards will work? ...
As long as 4GB RAM is available for processing?
#crysx
August 27, 2020, 12:17:51 PM
i am using GTX 1050 4g
You need a GPU with more than 4 GB.
August 27, 2020, 04:24:51 AM
Hi,
Below are the error from my log file. FYI i am using GTX 1050 4g(This is my spare GPU solely use for mining purpose only), using the latest GPU drivers(Also tried rollback many previous drivers up to drivers released in 2019) and Win10 are also updated as well. And i'm mining from a 6 core laptop with 20gb of ram.
*** ccminer 1.3.0-djm34 for nVidia GPUs by djm34 ***
Built with VC++ 2015 and nVidia CUDA SDK 10.1
Originally based on Christian Buchner and Christian H. project based on tpruvot 1.8.4 release
Include algos from alexis78, djm34, sp, tsiv and klausT.
*** News (07/06/2018): MTP algo for ZCoin
MTP algo based on krnlx kernel
BTC donation address: 1NENYmxwZGHsKFmyjTc5WferTn5VTFb7Ze (djm34)
ZCoin donation address: aChWVb8CpgajadpLmiwDZvZaKizQgHxfh5 (djm34)
[2020-07-26 14:58:00] POOL 0: 178.63.61.138:55486 USER xxxxxxxxxxxxxxWALLETxxxxxxxxxxxxxx.F6QDXC9 -s 30
[2020-07-26 14:58:00] Starting on stratum+tcp://178.63.61.138:55486
[2020-07-26 14:58:00] NVML GPU monitoring enabled.
[2020-07-26 14:58:00] NVAPI GPU monitoring enabled.
[2020-07-26 14:58:00] 1 miner thread started, using 'mtp' algorithm.
[2020-07-26 14:58:04] MESSAGE FROM SERVER: Welcome to the European Zcoin stratum.
[2020-07-26 14:58:04] Stratum difficulty set to 0.03125
[2020-07-26 14:58:05] MESSAGE FROM SERVER: Optimizing difficulty may take several minutes.
[2020-07-26 14:58:11] GPU #0: Intensity set to 19.5625, 819200 cuda threads number of multiproc 5
cudaErrorInvalidValue
Sleep 3000 msec
Appreciate any kind soul help. Thks
Below are the error from my log file. FYI i am using GTX 1050 4g(This is my spare GPU solely use for mining purpose only), using the latest GPU drivers(Also tried rollback many previous drivers up to drivers released in 2019) and Win10 are also updated as well. And i'm mining from a 6 core laptop with 20gb of ram.
*** ccminer 1.3.0-djm34 for nVidia GPUs by djm34 ***
Built with VC++ 2015 and nVidia CUDA SDK 10.1
Originally based on Christian Buchner and Christian H. project based on tpruvot 1.8.4 release
Include algos from alexis78, djm34, sp, tsiv and klausT.
*** News (07/06/2018): MTP algo for ZCoin
MTP algo based on krnlx kernel
BTC donation address: 1NENYmxwZGHsKFmyjTc5WferTn5VTFb7Ze (djm34)
ZCoin donation address: aChWVb8CpgajadpLmiwDZvZaKizQgHxfh5 (djm34)
[2020-07-26 14:58:00] POOL 0: 178.63.61.138:55486 USER xxxxxxxxxxxxxxWALLETxxxxxxxxxxxxxx.F6QDXC9 -s 30
[2020-07-26 14:58:00] Starting on stratum+tcp://178.63.61.138:55486
[2020-07-26 14:58:00] NVML GPU monitoring enabled.
[2020-07-26 14:58:00] NVAPI GPU monitoring enabled.
[2020-07-26 14:58:00] 1 miner thread started, using 'mtp' algorithm.
[2020-07-26 14:58:04] MESSAGE FROM SERVER: Welcome to the European Zcoin stratum.
[2020-07-26 14:58:04] Stratum difficulty set to 0.03125
[2020-07-26 14:58:05] MESSAGE FROM SERVER: Optimizing difficulty may take several minutes.
[2020-07-26 14:58:11] GPU #0: Intensity set to 19.5625, 819200 cuda threads number of multiproc 5
cudaErrorInvalidValue
Sleep 3000 msec
Appreciate any kind soul help. Thks
February 15, 2020, 12:28:04 PM
Since no ones luck is that good.
False assumption. Just because you didn't ever win the loterry it doesn't mean no one has.
There is a whole branch of math that can tell you exactly the odds of what happened.
As long as the miner submits valid shares at a normal rate (pooled mining) you're in the game, just unlucky.
February 15, 2020, 11:49:18 AM
I have been trying your version of CCMiner for a bit now. Normally I use Trex as many do, but thought it does not hurt to give it a try. I won't know too much for an hour or 2 while the switch stabilizes and hash levels. I do have some questions though, so I figured maybe I should ask here if that is alright.
I mine with a partner (my oldest nephew) and he is in a different part of the country. The last 3 days we have been solo mining Zcoin at 2Miners.com. We jump around like most miners do I suppose, but for Zcoin we always comeback to 2Miners. Anyway, this question is specific to solo mining Zcoin and Luck. In a nutshell, my partner has found 3 blocks in these 3 days, and I have not found any. I am actually hashing higher with about 60Mh/s and he is about 45Mh/s. Since no ones luck is that good, with less to work with. I am trying to figure it out. Our equipment is the same, he just has less GPUs then me. We use the same mining software (Minerstat) with as I said, the same hardware. The single difference I can think of is networking. He is on super fast full fiber optic at 250 Mb/s up and down. I am on 100 Mb/s down and only 10 Mb/s up. Since sending shares is what a miner does, his share must move like lightning and my like a slow freight train. I think this is the reason. What is your thoughts.
This other question I hope is right up your alley. Would you know if there is any possibility of integrating multiple GPUs where mining software sees multiple GPUs cores as if a single entity. My though here is if that were possible, there should be a great advantage solo mining as the processing time per share should be divisible by the number of GPUs in the cluster, not considering difficulty level changes. I admit, this is out of my somewhat shallow experience in shared computing using data/task parallelism, but if it were possible, I would have to think it may actually be quit significant in all of mining as well, not just solo mining.
That's about it. Thanks for providing and working to improve your version of CCMiner to us miners.
-Rodger
I mine with a partner (my oldest nephew) and he is in a different part of the country. The last 3 days we have been solo mining Zcoin at 2Miners.com. We jump around like most miners do I suppose, but for Zcoin we always comeback to 2Miners. Anyway, this question is specific to solo mining Zcoin and Luck. In a nutshell, my partner has found 3 blocks in these 3 days, and I have not found any. I am actually hashing higher with about 60Mh/s and he is about 45Mh/s. Since no ones luck is that good, with less to work with. I am trying to figure it out. Our equipment is the same, he just has less GPUs then me. We use the same mining software (Minerstat) with as I said, the same hardware. The single difference I can think of is networking. He is on super fast full fiber optic at 250 Mb/s up and down. I am on 100 Mb/s down and only 10 Mb/s up. Since sending shares is what a miner does, his share must move like lightning and my like a slow freight train. I think this is the reason. What is your thoughts.
This other question I hope is right up your alley. Would you know if there is any possibility of integrating multiple GPUs where mining software sees multiple GPUs cores as if a single entity. My though here is if that were possible, there should be a great advantage solo mining as the processing time per share should be divisible by the number of GPUs in the cluster, not considering difficulty level changes. I admit, this is out of my somewhat shallow experience in shared computing using data/task parallelism, but if it were possible, I would have to think it may actually be quit significant in all of mining as well, not just solo mining.
That's about it. Thanks for providing and working to improve your version of CCMiner to us miners.
-Rodger
100mb/s is good for mining i not think it different about 100-250/mb in this case is not about internet speed maybe you try other port(or choose sever to near you) in 2miners.com
mining need network stable go to check how long ping to sent to server and it have reject or not.
i hope this can help you.
January 11, 2020, 06:45:11 PM
I have been trying your version of CCMiner for a bit now. Normally I use Trex as many do, but thought it does not hurt to give it a try. I won't know too much for an hour or 2 while the switch stabilizes and hash levels. I do have some questions though, so I figured maybe I should ask here if that is alright.
I mine with a partner (my oldest nephew) and he is in a different part of the country. The last 3 days we have been solo mining Zcoin at 2Miners.com. We jump around like most miners do I suppose, but for Zcoin we always comeback to 2Miners. Anyway, this question is specific to solo mining Zcoin and Luck. In a nutshell, my partner has found 3 blocks in these 3 days, and I have not found any. I am actually hashing higher with about 60Mh/s and he is about 45Mh/s. Since no ones luck is that good, with less to work with. I am trying to figure it out. Our equipment is the same, he just has less GPUs then me. We use the same mining software (Minerstat) with as I said, the same hardware. The single difference I can think of is networking. He is on super fast full fiber optic at 250 Mb/s up and down. I am on 100 Mb/s down and only 10 Mb/s up. Since sending shares is what a miner does, his share must move like lightning and my like a slow freight train. I think this is the reason. What is your thoughts.
This other question I hope is right up your alley. Would you know if there is any possibility of integrating multiple GPUs where mining software sees multiple GPUs cores as if a single entity. My though here is if that were possible, there should be a great advantage solo mining as the processing time per share should be divisible by the number of GPUs in the cluster, not considering difficulty level changes. I admit, this is out of my somewhat shallow experience in shared computing using data/task parallelism, but if it were possible, I would have to think it may actually be quit significant in all of mining as well, not just solo mining.
That's about it. Thanks for providing and working to improve your version of CCMiner to us miners.
-Rodger
I mine with a partner (my oldest nephew) and he is in a different part of the country. The last 3 days we have been solo mining Zcoin at 2Miners.com. We jump around like most miners do I suppose, but for Zcoin we always comeback to 2Miners. Anyway, this question is specific to solo mining Zcoin and Luck. In a nutshell, my partner has found 3 blocks in these 3 days, and I have not found any. I am actually hashing higher with about 60Mh/s and he is about 45Mh/s. Since no ones luck is that good, with less to work with. I am trying to figure it out. Our equipment is the same, he just has less GPUs then me. We use the same mining software (Minerstat) with as I said, the same hardware. The single difference I can think of is networking. He is on super fast full fiber optic at 250 Mb/s up and down. I am on 100 Mb/s down and only 10 Mb/s up. Since sending shares is what a miner does, his share must move like lightning and my like a slow freight train. I think this is the reason. What is your thoughts.
This other question I hope is right up your alley. Would you know if there is any possibility of integrating multiple GPUs where mining software sees multiple GPUs cores as if a single entity. My though here is if that were possible, there should be a great advantage solo mining as the processing time per share should be divisible by the number of GPUs in the cluster, not considering difficulty level changes. I admit, this is out of my somewhat shallow experience in shared computing using data/task parallelism, but if it were possible, I would have to think it may actually be quit significant in all of mining as well, not just solo mining.
That's about it. Thanks for providing and working to improve your version of CCMiner to us miners.
-Rodger
January 08, 2020, 05:40:37 PM
im on ubuntu 16.04, 6x 1080ti, ccminer 1.3.1, nvidia driver 440.44 and seeing 100% cpu (i5 quad)
edit:
I sorta fixed it for now by setting --cpu-affinity=0x1
no hit on hash rate
edit:
I sorta fixed it for now by setting --cpu-affinity=0x1
no hit on hash rate
January 07, 2020, 08:14:32 AM
Edit: perhaps the following can be ignored for now as I was using v1.2.3. I'll upgrade to
v1.3.1 and see how it goes.
---
I had 2 instances of ccminer-1.2.3 being killed by the kernel.
The only message to the console is "Killed".
The first time on Windows with a gtx 1070, the second was on Linux with a 1080ti.
There is a possibility that ccminer is a victim of the OOM killer. I have experience
where the process denied memory was not the source of the leak. Considering
the two incidents occurred on different OSes makes that unlikely. The only
other common application is Firefox so that is the only plausible cause of the leak
assuming ccminer was in fact a victim.
The only other common factor is both were using Pascal GPUs with sm6.1 but this doesn't look
like a GPU issue to me (I'm certainly not a Cuda expert)
The problem is very intermittant (only happened to me twice) and isn't realated to session length.
I have had sessions run for over 24 hours on both systems but one of the two incidents happened
after only 14 minutes run time. That is not a s low leak.
There appears to be a trigger that requires a rare set of circumstances, but once triggered memory is
exhausted quickly.
It would be reasonable to conclude the memory issue is related to code specific to MTP. I haven't seen
this with any other forks of ccminer I've used.
The infrequent nature of the problem and lack of precise coonnection between the trigger event and the
termination of the process make it virtually impossible to troubleshoot.
Then again the infrequent nature makes the problem less serious. But I thought I'd document what I could
just in case my analysis leads to some inspiration.
Edit Nov 7:
I have seen one instance of "killed" on v1.3.1 Linux.
I now suspect the trigger may not be ccminer, but another application that pushes mem over the edge.
I also suspect the edge is close because of the 45-49 GB VM used by ccminer.
The amount of VM apparently used greatly exceeds the amount of VM in my system: 16G RAM + 2 GB swap file.
Edit Nov 11:
Another revision. I have seen the problem with v1.3.1 on Windows, no console error message but a pop-up
saying essentially the same thing.
The high VM usage seems to be a non-issue as it is also observed using tpruvot fork with different algo.
Current speculation is an intermittant leak, likely in conditional code related to MTP.
v1.3.1 and see how it goes.
---
I had 2 instances of ccminer-1.2.3 being killed by the kernel.
The only message to the console is "Killed".
The first time on Windows with a gtx 1070, the second was on Linux with a 1080ti.
There is a possibility that ccminer is a victim of the OOM killer. I have experience
where the process denied memory was not the source of the leak. Considering
the two incidents occurred on different OSes makes that unlikely. The only
other common application is Firefox so that is the only plausible cause of the leak
assuming ccminer was in fact a victim.
The only other common factor is both were using Pascal GPUs with sm6.1 but this doesn't look
like a GPU issue to me (I'm certainly not a Cuda expert)
The problem is very intermittant (only happened to me twice) and isn't realated to session length.
I have had sessions run for over 24 hours on both systems but one of the two incidents happened
after only 14 minutes run time. That is not a s low leak.
There appears to be a trigger that requires a rare set of circumstances, but once triggered memory is
exhausted quickly.
It would be reasonable to conclude the memory issue is related to code specific to MTP. I haven't seen
this with any other forks of ccminer I've used.
The infrequent nature of the problem and lack of precise coonnection between the trigger event and the
termination of the process make it virtually impossible to troubleshoot.
Then again the infrequent nature makes the problem less serious. But I thought I'd document what I could
just in case my analysis leads to some inspiration.
Edit Nov 7:
I have seen one instance of "killed" on v1.3.1 Linux.
I now suspect the trigger may not be ccminer, but another application that pushes mem over the edge.
I also suspect the edge is close because of the 45-49 GB VM used by ccminer.
The amount of VM apparently used greatly exceeds the amount of VM in my system: 16G RAM + 2 GB swap file.
Edit Nov 11:
Another revision. I have seen the problem with v1.3.1 on Windows, no console error message but a pop-up
saying essentially the same thing.
The high VM usage seems to be a non-issue as it is also observed using tpruvot fork with different algo.
Current speculation is an intermittant leak, likely in conditional code related to MTP.
sorry for the delay in replying (haven't checked that post in a while).
'Killed' usually means that the program was killed by the system as the system was running out of memory (ie: memory leak).
These problem have been addressed recently, using the most recent release on github should solve that issue.
2Gb of swap file might be a bit tight, on mtp, each gpu requires at least 4.5Gb of swap per gpu.
The high VM usage is a consequence of 2 nvidia drivers releases which were released around that time (roughly), you need to upgrade to the most recent drivers where this issue hasn't been noticed.
October 31, 2019, 02:15:50 AM
Edit: perhaps the following can be ignored for now as I was using v1.2.3. I'll upgrade to
v1.3.1 and see how it goes.
---
I had 2 instances of ccminer-1.2.3 being killed by the kernel.
The only message to the console is "Killed".
The first time on Windows with a gtx 1070, the second was on Linux with a 1080ti.
There is a possibility that ccminer is a victim of the OOM killer. I have experience
where the process denied memory was not the source of the leak. Considering
the two incidents occurred on different OSes makes that unlikely. The only
other common application is Firefox so that is the only plausible cause of the leak
assuming ccminer was in fact a victim.
The only other common factor is both were using Pascal GPUs with sm6.1 but this doesn't look
like a GPU issue to me (I'm certainly not a Cuda expert)
The problem is very intermittant (only happened to me twice) and isn't realated to session length.
I have had sessions run for over 24 hours on both systems but one of the two incidents happened
after only 14 minutes run time. That is not a s low leak.
There appears to be a trigger that requires a rare set of circumstances, but once triggered memory is
exhausted quickly.
It would be reasonable to conclude the memory issue is related to code specific to MTP. I haven't seen
this with any other forks of ccminer I've used.
The infrequent nature of the problem and lack of precise coonnection between the trigger event and the
termination of the process make it virtually impossible to troubleshoot.
Then again the infrequent nature makes the problem less serious. But I thought I'd document what I could
just in case my analysis leads to some inspiration.
Edit Nov 7:
I have seen one instance of "killed" on v1.3.1 Linux.
I now suspect the trigger may not be ccminer, but another application that pushes mem over the edge.
I also suspect the edge is close because of the 45-49 GB VM used by ccminer.
The amount of VM apparently used greatly exceeds the amount of VM in my system: 16G RAM + 2 GB swap file.
Edit Nov 11:
Another revision. I have seen the problem with v1.3.1 on Windows, no console error message but a pop-up
saying essentially the same thing.
The high VM usage seems to be a non-issue as it is also observed using tpruvot fork with different algo.
Current speculation is an intermittant leak, likely in conditional code related to MTP.
v1.3.1 and see how it goes.
---
I had 2 instances of ccminer-1.2.3 being killed by the kernel.
The only message to the console is "Killed".
The first time on Windows with a gtx 1070, the second was on Linux with a 1080ti.
There is a possibility that ccminer is a victim of the OOM killer. I have experience
where the process denied memory was not the source of the leak. Considering
the two incidents occurred on different OSes makes that unlikely. The only
other common application is Firefox so that is the only plausible cause of the leak
assuming ccminer was in fact a victim.
The only other common factor is both were using Pascal GPUs with sm6.1 but this doesn't look
like a GPU issue to me (I'm certainly not a Cuda expert)
The problem is very intermittant (only happened to me twice) and isn't realated to session length.
I have had sessions run for over 24 hours on both systems but one of the two incidents happened
after only 14 minutes run time. That is not a s low leak.
There appears to be a trigger that requires a rare set of circumstances, but once triggered memory is
exhausted quickly.
It would be reasonable to conclude the memory issue is related to code specific to MTP. I haven't seen
this with any other forks of ccminer I've used.
The infrequent nature of the problem and lack of precise coonnection between the trigger event and the
termination of the process make it virtually impossible to troubleshoot.
Then again the infrequent nature makes the problem less serious. But I thought I'd document what I could
just in case my analysis leads to some inspiration.
Edit Nov 7:
I have seen one instance of "killed" on v1.3.1 Linux.
I now suspect the trigger may not be ccminer, but another application that pushes mem over the edge.
I also suspect the edge is close because of the 45-49 GB VM used by ccminer.
The amount of VM apparently used greatly exceeds the amount of VM in my system: 16G RAM + 2 GB swap file.
Edit Nov 11:
Another revision. I have seen the problem with v1.3.1 on Windows, no console error message but a pop-up
saying essentially the same thing.
The high VM usage seems to be a non-issue as it is also observed using tpruvot fork with different algo.
Current speculation is an intermittant leak, likely in conditional code related to MTP.
October 17, 2019, 04:11:46 AM
The stratum crash noted above is fixed in v1.2.3, and the 1080ti hashes fine and
submits valid shares. Thanks.
Edit2: Nevermind the following, the 970 ony has 4 GB mem.
But ccminer exits on GTX970. Makefile has compute 5.2 so I assume Maxwell is supported.
I tried setting a lower intensity but it always reported the same intensity and threads. Not sure if it's
related to the crash or a seperate issue.
Anything I can do to help?
Edit: tried the Windows version, same problem. It looks like Maxwell isn't supported after all.
yes indeed that problem has been fixed in the latest version.submits valid shares. Thanks.
Edit2: Nevermind the following, the 970 ony has 4 GB mem.
But ccminer exits on GTX970. Makefile has compute 5.2 so I assume Maxwell is supported.
Code:
[2019-10-08 14:02:32] Starting on stratum+tcp://mtp.mine.zergpool.com:3000
[2019-10-08 14:02:32] 1 miner thread started, using 'mtp' algorithm.
[2019-10-08 14:02:37] Stratum difficulty set to 0.119207
[2019-10-08 14:02:37] GPU #1: Intensity set to 21.0156, 2129920 cuda threads number of multiproc 13
cudaErrorInvalidValue
[2019-10-08 14:02:32] 1 miner thread started, using 'mtp' algorithm.
[2019-10-08 14:02:37] Stratum difficulty set to 0.119207
[2019-10-08 14:02:37] GPU #1: Intensity set to 21.0156, 2129920 cuda threads number of multiproc 13
cudaErrorInvalidValue
I tried setting a lower intensity but it always reported the same intensity and threads. Not sure if it's
related to the crash or a seperate issue.
Anything I can do to help?
Edit: tried the Windows version, same problem. It looks like Maxwell isn't supported after all.
Maxwell is supported as long as there are more than 4Gb of vram. So could in principle concerns some titan model (and stuff like that).
However performance aren't stellar, and cheaper Pascal/Turing model will most likely beat these one.
October 08, 2019, 09:44:46 PM
Any plans to optimize for rtx cards?
October 08, 2019, 02:29:57 PM
The stratum crash noted above is fixed in v1.2.3, and the 1080ti hashes fine and
submits valid shares. Thanks.
Edit2: Nevermind the following, the 970 ony has 4 GB mem.
But ccminer exits on GTX970. Makefile has compute 5.2 so I assume Maxwell is supported.
I tried setting a lower intensity but it always reported the same intensity and threads. Not sure if it's
related to the crash or a seperate issue.
Anything I can do to help?
Edit: tried the Windows version, same problem. It looks like Maxwell isn't supported after all.
submits valid shares. Thanks.
Edit2: Nevermind the following, the 970 ony has 4 GB mem.
But ccminer exits on GTX970. Makefile has compute 5.2 so I assume Maxwell is supported.
Code:
[2019-10-08 14:02:32] Starting on stratum+tcp://mtp.mine.zergpool.com:3000
[2019-10-08 14:02:32] 1 miner thread started, using 'mtp' algorithm.
[2019-10-08 14:02:37] Stratum difficulty set to 0.119207
[2019-10-08 14:02:37] GPU #1: Intensity set to 21.0156, 2129920 cuda threads number of multiproc 13
cudaErrorInvalidValue
[2019-10-08 14:02:32] 1 miner thread started, using 'mtp' algorithm.
[2019-10-08 14:02:37] Stratum difficulty set to 0.119207
[2019-10-08 14:02:37] GPU #1: Intensity set to 21.0156, 2129920 cuda threads number of multiproc 13
cudaErrorInvalidValue
I tried setting a lower intensity but it always reported the same intensity and threads. Not sure if it's
related to the crash or a seperate issue.
Anything I can do to help?
Edit: tried the Windows version, same problem. It looks like Maxwell isn't supported after all.
September 15, 2019, 12:11:25 PM
I'm having a hell of a problem getting ccminer to work.
CPU: Ryzen7 1700
OS: Ubuntu 18.04
Cuda: 9.1 from repo
GPUs: GTX-1080ti, GTX-970
Source: https://github.com/zcoinofficial/ccminer/archive/1.2.2.tar.gz
Makefile: compute 5.2, 6.1 (removed 7.5)
There's nothing unusual with my setup, it works fine for other ccminer forks.
ccminer-1.2.2 segfaults on stratum thread startup. It looks like the URL wasn't set.
Previous versions have other problems.
CPU: Ryzen7 1700
OS: Ubuntu 18.04
Cuda: 9.1 from repo
GPUs: GTX-1080ti, GTX-970
Source: https://github.com/zcoinofficial/ccminer/archive/1.2.2.tar.gz
Makefile: compute 5.2, 6.1 (removed 7.5)
There's nothing unusual with my setup, it works fine for other ccminer forks.
ccminer-1.2.2 segfaults on stratum thread startup. It looks like the URL wasn't set.
Previous versions have other problems.
Code:
(gdb) run
Starting program: /home/coin/miners/ccminer-mtp-djm34/ccminer-1.2.2/ccminer -a mtp -o stratum+tcp://mtp.mine.zergpool.com:3000 -u [...] -p [...]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
*** ccminer 1.2.2-djm34 for nVidia GPUs by djm34 ***
Built with the nVidia CUDA Toolkit 9.1
Originally based on Christian Buchner and Christian H. project based on tpruvot 1.8.4 release
Include algos from alexis78, djm34, sp, tsiv and klausT.
*** News (07/06/2018): MTP algo for ZCoin
MTP algo based on krnlx kernel
BTC donation address: 1NENYmxwZGHsKFmyjTc5WferTn5VTFb7Ze (djm34)
ZCoin donation address: aChWVb8CpgajadpLmiwDZvZaKizQgHxfh5 (djm34)
[New Thread 0x7fffea522700 (LWP 14291)]
[2019-09-14 22:31:56] POOL 0: mtp.mine.zergpool.com:3000 USER [...] -s 30
[New Thread 0x7fffe9d21700 (LWP 14292)]
[New Thread 0x7fffe9520700 (LWP 14293)]
[New Thread 0x7fffe8d1f700 (LWP 14294)]
Thread 4 "ccminer" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe9520700 (LWP 14293)]
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
120 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory.
(gdb) bt
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1 0x00007ffff69479ae in __GI___strdup (
s=0x48) at strdup.c:41
#2 0x0000555555578a6f in stratum_thread (userdata=)
at ccminer.cpp:4011
#3 0x00007ffff793e6db in start_thread (arg=0x7fffe9520700)
at pthread_create.c:463
#4 0x00007ffff69cb88f in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Starting program: /home/coin/miners/ccminer-mtp-djm34/ccminer-1.2.2/ccminer -a mtp -o stratum+tcp://mtp.mine.zergpool.com:3000 -u [...] -p [...]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
*** ccminer 1.2.2-djm34 for nVidia GPUs by djm34 ***
Built with the nVidia CUDA Toolkit 9.1
Originally based on Christian Buchner and Christian H. project based on tpruvot 1.8.4 release
Include algos from alexis78, djm34, sp, tsiv and klausT.
*** News (07/06/2018): MTP algo for ZCoin
MTP algo based on krnlx kernel
BTC donation address: 1NENYmxwZGHsKFmyjTc5WferTn5VTFb7Ze (djm34)
ZCoin donation address: aChWVb8CpgajadpLmiwDZvZaKizQgHxfh5 (djm34)
[New Thread 0x7fffea522700 (LWP 14291)]
[2019-09-14 22:31:56] POOL 0: mtp.mine.zergpool.com:3000 USER [...] -s 30
[New Thread 0x7fffe9d21700 (LWP 14292)]
[New Thread 0x7fffe9520700 (LWP 14293)]
[New Thread 0x7fffe8d1f700 (LWP 14294)]
Thread 4 "ccminer" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe9520700 (LWP 14293)]
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
120 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory.
(gdb) bt
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1 0x00007ffff69479ae in __GI___strdup (
s=0x48
#2 0x0000555555578a6f in stratum_thread (userdata=
at ccminer.cpp:4011
#3 0x00007ffff793e6db in start_thread (arg=0x7fffe9520700)
at pthread_create.c:463
#4 0x00007ffff69cb88f in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
September 11, 2019, 01:46:31 PM
win 7 for nvidia is very slow not win 10 how come ?
According to my personal observations, windows 7 work with miners much better than windows 10. For example, grimm mining, the makeup of my 6 gigabyte video cards is not enough for mining on windows 10, and on windows 7 everything works fine. Windows 7 consumes less video memory. August 23, 2019, 09:42:00 AM
current cuda version are developped around win10, also it is 64bit code which has always been slower (for some reason) on win 7
August 23, 2019, 02:38:55 AM
win 7 for nvidia is very slow not win 10 how come ?
August 14, 2019, 07:07:16 AM
new sgminer release: https://github.com/zcoinofficial/sgminer/releases/tag/0.1.3
improved connection between pool and miner in case of high latency connection
improved connection between pool and miner in case of high latency connection
August 05, 2019, 05:49:39 AM
new ccminer release: https://github.com/zcoinofficial/ccminer/releases/tag/1.2.0
* better handling of eventual packet losses when the connection to the pool is less than optimal
=> no more pool disconnect
* better handling of eventual packet losses when the connection to the pool is less than optimal
=> no more pool disconnect
July 28, 2019, 07:05:15 AM
new release https://github.com/zcoinofficial/ccminer/releases/tag/1.1.26
* rearrange how the cards are assigned to threads. this should correct the issue described here in issue #4
the previous release (not announced here) were correcting:
* correct more crash issues...
These crash were occurring when the pool stop sending data or is unable to send data.
When this happen, the stratum thread is restarted.
In case of vardiff, the last difficulty is used when the thread is restarted.
* rearrange how the cards are assigned to threads. this should correct the issue described here in issue #4
the previous release (not announced here) were correcting:
* correct more crash issues...
These crash were occurring when the pool stop sending data or is unable to send data.
When this happen, the stratum thread is restarted.
In case of vardiff, the last difficulty is used when the thread is restarted.
July 23, 2019, 05:54:49 PM
sorry no support for nicehash.
This is zcoin official miner and nicehash is not considered as crypto friendly (price dumping, I think anyone who was around, when nicehash got hacked, saw price of crypto and mining profitability increased... just saying
), hence the miner doesn't support nicehash.
Furthemore, if you do your own calculation, you should realize that mining zcoin and selling it yourself will be more profitable to you too.
Also the upcoming new platform of nicehash is not supporting mtp either...
This is zcoin official miner and nicehash is not considered as crypto friendly (price dumping, I think anyone who was around, when nicehash got hacked, saw price of crypto and mining profitability increased... just saying
), hence the miner doesn't support nicehash. Furthemore, if you do your own calculation, you should realize that mining zcoin and selling it yourself will be more profitable to you too.
Also the upcoming new platform of nicehash is not supporting mtp either...
I'm not so negative about Nicehash, they provide an open market with willing participants on both sides
with them, as brokers, in the midle taking a cut. The effects on the overall crypto market are due to the actions of
their users more than their presence. However, they do tend to act like the elephant in the room at times by
making their own rules. That attitude never seemed to hurt Microsoft despite the anti-Microsoft cults.
The main market effect of Nicehash is the same as any auto-exchange pool. It tends to hurt altoins due
to persistent dumping for BTC. But it creates opportunities at the other end where altcoin specuators can
pick them up more cheaply when the pools dump them.
But I digress.
What is this Nicehash support issue? Did they do something stupid that requires specific miner support?
Jump to: