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

Yeah, I definitely won't be able to do it with these instructions...
If anybody has step by step ones I'll try.

in the words of sp - earlier in the thread ...

-------

install Cuda 6.5

Visual studio 2013

https://github.com/sp-hash/ccminer

-------

if you want step by step instructions as such - then maybe someone here can help out with that? ...

#crysx

Do you guys know where I can find instructions to compile from github?
I have Win7 x64 on my PC. Also I have never done this (compiling) and don't have a github account.
It would be nice to try these versions between releases.

"Api bind to port 4068 failed"

If you are getting this error, it is possible that you are running two instances of ccminer simultaneously.  Or, you have another application controlling that port.  Port 4068 is the default listening port for ccminer.  You can set it to another port in the configuration, if desired, with the "-b" switch.       --scryptr

INITIAL RESULTS--

I cloned git commit #725 and ran it on my 2 rigs.  THE "...does not validate on CPU" ERRORS are GONE!  The hash rate still fluctuates.  Hash rate is printed to the screen only with the physical GPU number.  Using only "-g 4" and default intensity (no -i flag used), the 8 threads on my 2-card rig are reported at launch, as are the 24 threads on my 6 card rig.  Then the hash rate fluctuates to higher than normal values, but without error.  My 2-card 970 FTW+ rig is averaging near 35Mh/s, and my 6-card 750ti FTW rig is averaging around 60Mh/s.  Both rig's hash rates swing wildly.  

My total rate for all three machines mining on yaamp was about 80Mh/s before, mining with single threads as reported on the previous page.  This was reflected in the pool rate.  The pool rate still remains at the same level with commit #725, but the errors are gone.  The local rates total over 100Mh/s, including a steady, single-threaded, rate for my 960 SSC of about 9.4Mh/s.  The 960 SSC is somewhat like a control sample, I suppose.       --scryptr


6x750ti FTW, with build #725


2x970 FTW+, with build #725


Quark hash rate, single-threaded (before)


Quark hash rate, four-threaded (after)

NOTE: Local time is 1 hour behind times on graph.

Threads work with sgminer,  they should work here.  Dual instances (yielding two threads) worked with Scrypt and CudaMiner.  

--scryptr

Submitted another fix (merged from the klaus_T fork).

quark and x11,x13,x15,x17 should work now, but the performance is down using one thread.

quark with -g 4 is looking good.

Got it.


Will do.

Thanks!

download nvidia inspector

Use bat-file with

nvidiaInspector -restartDisplayDriver

Thank you

Klaus_t blake kernal is working but 800kb of stack and memory spills slows quark down quark 400KHASH.

On 750 ti with -g 3 and -i 22 stay "does not validate on CPU" with last build from git

Looks like klaus_t has fixed the hash in his branch. I have to check it out.

The as-compiled by sp_ release 45 is a nightmare on my rig, mining Quark

GTX 970
i7 4770
16GB
Win 8.1

Unsteady hashrate with -i 20, and most any other intensity setting crashes.

After a crash, the GPU goes into a low power mode and I have to restart the machine. I suspect that if I used an older version of Afterburner or Precision X that has the K-Boost button, I might be able to wake it up after the crash without restarting .

Either way, it is very buggy and that makes me

VIRTUAL GPUs DON'T COUNT--

I cloned from git and compiled commit #724.  In my two card rig, the only accepts are from the base GPUs (#0 and #1).  Whenever another thread is reported from a higher numbered (virtual) GPU, it is a "CPU" error.  The same is happening in my 6x750ti rig.  Both rigs have the same fluctuating higher/lower hash rates as prior, and a quick check gives slightly lower poolside results than single theaded mining.

Single-threaded results are similar to the last commit, #723.  I might try separate instances mining single-threaded concurrently, the way I used to mine with CudaMiner.  The GPUs could take it, and produced slightly more hash.  And, if one instance crashed, the other would speed up and take its place.  This reminds me of DoubleDOS and DeskMate...

--scryptr

I have fixed the errors now in quark.  (github)

-g is now working and not producing any "does not validate on the cpu"

Please test.

I will continue with the other algos

HASH RATE --

I've been mining Quark for the last few days.  This morning I reluctantly removed the gputhreads "-g 3" flag from all of my config files, and restarted my Linux rigs with "-i 23" as the only performance aid.  I now have a 2x970 FTW+ rig and the same 6x750ti FTW rig mining Quark.  My 960 SSC card is in my working computer, running on Win 7 x64.  It is running the last Windows release of v45, compiled and posted by SP_ .  The rigs are running commit 723, compiled from git locally.

RESULTS:

  2x970 FTW+  --  14.8Mh/s per card, 29.8Mh/s for the rig, 99%+ accepts, no "CPU" errors (headless rig, -i 23)
  6x750ti FTW  --  6.35Mh/s per card, 38.1Mh/s for the rig, 98%+ accepts, no "CPU"errors  (headless rig, -i 23.5)
  1x960 SSC  --  9.425Mh/s per card, total, 98%+ accepts, no "CPU" errors (driving a monitor, computer in daily use, -i 20)

My 6x 750ti FTW rig is at least 1.7Mh/s faster than with v44.  These single-threaded rates are reflected poolside with reasonable agreement.  Poolside rates always seem to fluctuate, and have done so as long as I have mined.  I am not getting any "...does not validate on CPU" errors.

I am hoping that SP_ can ferret out the bugs soon.  I am waiting for another intermediate commit before I git and compile again.       --scryptr

Is there a way to repair those problems :
Api bind to port 4068 failed
result for xxxxx does not validate on cpu

Gtx 970 X 2 ccminer 1.5.45
Thanks

sp when I download ccminer 1.6.2 x86  zip... the folder is empty.

install Cuda 6.5

Visual studio 2013

https://github.com/sp-hash/ccminer

Yes, can you help me find the bug? Benchmark mode is working..