Topic: ccminer 1.2.0/sgminer 0.1.3 for MTP: Fastest MTP miner for nvidia cards (Read 4627 times)

So most other cards will work? ...

As long as 4GB RAM is available for processing?

#crysx

You need a GPU with more than 4 GB.

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

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.

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.

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

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

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.

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.

yes indeed that problem has been fixed in the latest version.
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.

Any plans to optimize for rtx cards?

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.

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.

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.

current cuda version are developped around win10, also it is 64bit code which has always been slower (for some reason) on win 7

win 7 for nvidia is very slow not win 10 how come ?

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

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

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.

they require some modifications in stratum (in xtranonce I think)