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

SPLIT THREADS ERROR-

I just captured this:


750ti FTW Rig with error

The anomalous "GPU #11" represents one of the threads, but generally the output only displays GPUs #0-5.  As you can see, the acceptance rate while mining Quark with v45 is still good.       --scryptr

I began mining Scrypt with CudaMiner.  The images are of a single instance (per machine) of CCminer mining Quark.  The algo being mined is output to the screen in blue.        --scryptr       (P.S.  I edited for clarity)

Cool.

What algorithm? Scrypt?

CUDAMINER--

When I began mining Scrypt with CudaMiner, I picked up the trick of mining with two instances of the miner running simultaneously.  The results were a slightly improved total hash rate.  Also, if one instance of the miner crashed, the other would pick up the slack until I could set things right.

The "gputhreads" option is promising.  However, I tried the "-d 0,0,1,1,2,2,3,3,4,4,5,5" switch in CCminer v45 and it apparently does start two threads per gpu.  Mining Quark, I receive "does not validate on CPU" errors, but also have a higher hash rate and 99%+ acceptance rate on my 6x750ti FTW rig.  The hash rate is currently 36.8Mh/s for the rig.

My GTX 960 SSC gets about 9.5Mh/s with "-d 0,0".  The threads run about 1/2 the total hash rate with greater variance than a single thread.  You can tell the threads are running concurrently.  The performance with the "-d" switch appears more stable than when using the "-g" switch currently.

If the "gputhreads" switch is de-bugged, and allows for better control of the miner, I am all for it.         --scryptr


750ti FTW Rig


960 SSC Card

1. disable the 750ti cards in device manager. (only works on 960,970,980)
2. The head@git is broken. use release 45 exe file and run x11 with -g 4 -i 10. or other settings (no more than 4 cards)

Meassure the hashrate on a pool over time.

The g parameter is not compatible with the -d switch, but I will fix it.

Not very stable with invalid hashes(the invalid hashes will not be submitted to the pool), but you should get higher average rates.

agreed. I tried using -d 0 -g 2 and two cards are running.

The -d 0 -g 2 does not work. It is piggy backing a second card.

Stop all your cards and then run the bat. Look at Precision or Afterburner and you will see two cards are actually running. Device 0 and some other random card. I even tried -d 0 -g 3 and I had 3 cards running. So the increase in hash is actually coming from other cards running along with device 0. I do not thing this is how it works for cgminer/sgminer.

how are you going to implement the developer fee? time based pool switch?

I agree with the developper fee.
This is more fair than a fixed amount for small miners ...
You can made it switchable in the source code and force it in the binary releases (I am using the binary releases and I will be happy to contribute for 2% for your work.)

The problem is that the 750ti is out of resources.

I will fix it so that it will give a boost and no validation errors on all the maxwell cards. I just need to reduce the constmem/sharedmem usage and reduce threads per block for the kernals.

I think I will recode the -g parameter to support the -d parameter.

just give me some more time. This will be the biggest boost in hashrates in months..

For a 35% boost I think it is time to include a small developer fee of 2%. What do you think guys?

I will keep the sourcecode opensource and linux compatible.

Some tests...

A test machine with one 970 and one 750ti, Ubuntu 14.04, ccminer 45, quark algo, compiled with both 50/52 capability
default config (without -d and -g parameters): no performance increase and validate errors
-d 0 -g 2 (only 970 runs): 35% performance increase, no errors
-d 1 -g 2 (only 750ti runs): no performance increase and validate errors

With -d 0,0 you get hashrate statistics per thread and not per gpu, also I think my fork need to add some threadsyncronization calls and changed gpuconfig(more sharedmem/less level1cache) to avoid invalid hashes.

I want the -g option like in sgminer, but the current implementation (beta) is not working 100%. Tests have shown that 2 threads can boost performance up to 25% on the highend cards. 960/970/980. on most algorithms.

-g is useless and will make your fork buggy...

you just have to use -d0,0 to run 2 threads on the same gpu... beware to the cudaDeviceReset() in this case...

fully optimized ccminer and sgminer ...

now THAT is what i would like to see happen in ONE miner ...

#crysx

Yes. Can you make another screenshot of quark running on your watercooled rig (release 45)? I want to upgrade the title to  20MHASH ccminer modded NVIDIA Maxwell kernals on the front page of the thread.

hmmm ... nice wolf ...

how can we get the miner? ...

pm me please mate ...

#crysx

@chris, I was thinking of using linux mint 17.1 on a boot HDD on each headless rig, which is 5x 750ti and 6x 750ti, respectively.  I would Teamviewr or VNC in from a lone Windows 7 machine (daily driver, if you will) to do all the compiling, etc.  Although I did just get 2x gtx 980s at a firesale price.

just dont want to be using 9 month old miners with kopiemtu and losing out on some ROI.  Although I have gotten pretty familiar with the command line and ssh in general

with all the work he has been doing - he probably asleep and taking a rest ...

#crysx

Still alive, sp_?

that was the main consensus for us to move to a well known distro and work it from there ... the plus side is simply that when you are finished with the machine - sell it as a basic workstation ... 6 of our machines are going to ebay very shortly as we changed from amd to nvidia ...

our workers run fedora 19 x64 - with the latest ccminer from sp ( its one of the best forks out there ) - and run really well ... one machine with two gogabyte 750ti oc lp cards for testing and recompiling also has two hard drives for booting and compile / testing in fedora 20 x64 as well as fedora 19 x64 ...

in any case - we only have 4 workers left with amd cards - which we keep running with sgminer and wolf's bins and optimizations ...

all of the workers that are nvidia are ALL 750ti oc ( mostly lp with the exceptions of 2 workers ) ...

this means that when an update comes through - we can test on the dev machine and if it tests fine - roll out ( just via a copy using rsync ) to the rest of the machines and reboot the farm ...

if we were to use windows and teamviewer / vnc - we would be taking more than 3 times as long to complete this - as all the systems are linux based - headless - and only require ssh to log in work on them ...

we started with one test machine and have expanded over time ... so from the forefront - the last thing that i intended was to complicate things by using windows - and it DOES complicate the setup ( as opposed to linux ) no matter how anyone puts it ...

to speed things up and run autonomously - the moment the headless workers start - they mine ... all of them ...

and maintenance is a simple affair with linux ...

how were you looking at creating your build? ...

#crysx