The efficiency of 970s looks even better when you consider it takes three rigs of 750ti's to get
the same hash rate as one rig of 970's. Add the cost of two more CPUs, motherboards, drams,
hard drives (or other boot devices), psus and cases, and the power they consume.

I don't know euro pricing but I can guess the power overhead of each rig to be 100W.
That would make 3(360+100) W for the 3 750ti rigs and 960+100 W for the 970 rig.
The 750ti rigs would have a higher total hash rate of 103140 KH/s vs the 970s at 97200.

3 x 6 x 750ti: 74.7 KH/W
1 x 6 x 970:    91.7 KH/W

Smaller cards have a higher cost and power overhead due to lower density while bigger cards
have a steeper price curve. The 970 looks to be in the sweet spot. The 970 can also compete
on space with the availability of an LP version.

Epsylon3/tpruvot still builds for compute 3.0 & 3.5 last time I checked. Or you could compile ccminer yourself.

You can still mine it, you just don't want to mine something else and convert to it.

I think a name in red means they are short of that coin for payouts, at least that's what pops up
when I hover over it. I've also seen the block number in red, don't know what that means other
that it's probably not a good thing.

Thanks for that explanation, the fee structure always puzzled me.

I don't disagree with your attempts to discourage overmining small coins by creating disincentives but
I don't think a fee (that I assume goes to yaamp) is the correct way. Wouldn't it be more appropriate
to redistribute the disincentive fee to other coins/algos as an incentive to mine those more?
Putting an 8% fee in your pocket seems like profiteering.

Thank you for factoring out rentals from the fee formula and good job getting the site back up. Do you intend
to bring back some of the other algos/coins or are you going to keep the pool smaller?

Your site states a fee for auto-exchanging to BTC. Does this fee apply to auto-exchanges to other coins or just BTC?

Thanks and keep up the good work.

Are any power efficiency inprovements expected with the R93 series to compete with Maxwell?
Looks like a pair 0f 970s will give a lot more hash, a little higher TDP for nearly the same price
as the 980ti.

You can run ccminer.exe directly from a command prompt. A bat file is useful for simplifying its launch by
specifying the path to the executable and the parameters of your favorite pool. You can call the bat file anything
you want.

If you see files like ccminer50.exe this just means it's a custom build to support a specific compute version.
The 750ti is compute 5.0. You don't have to worry about this unless you want to mine on an older card.
All ccminer-1.5.* support compute 5.0 and above.

The pool paramaters depend on the pool. Many use your BTC (or altcoin) address as a username and some also
allow a worker to be specified. Check with your pool for those details.

Are they built the same? IIRC 32 bit builds perform better than 64, and cuda 6.5 performs better
than 7. Also are they generating code for the same compute versions? Do you get the same results
with the pre-built binaries?

CapnBDL,

I think you quoted the wrong conversation, but no matter.

The point I was trying to make to you is that you should moderate your expectations regarding new
algos that have similar names as existing ones. They may not be as similar as they may seem and may
require significant development to implement. It's more like a new feature than a bug fix.

That's curious. AFAIK changing the target architecture only affects the CPU code, not the Cuda code. If 64 works
but 32 doesn't there must be something messed up with your 32 bit environment, and it seems it's been that way
for a while.

No compatible hardware error is a driver installation issue. The cuda package include drivers but
they can, and should, be skipped during cuda installation. You probably already have a newer driver
that will get overwritten. In fact you can install cuda and compile ccminer without any GPU HW.

The compile problems and driver error are either not related or may have the same root cause.
If you have a compatible Nvidia GPU in your system and the driver install fails you should try
to fix that before trying anything with cuda.

Keep in mind I am also a newbie when it comes to compiling on Windows. If the procedure I posted
doesn't work I'm as lost as anyone.

I think a lot of these tweaks to algos are done intentionally to break compatibility with current miners,
particularly ASIC miners.

That was fast. You only really need ccminer.exe. You can delete the rest of the tree.

Edit: For the really addventurous you can also compile in a VM. The only difference is don't
install the drivers with cuda. Probably shouln't do that in any case if you already have
newer drivers already iinstalled. I do that on a linux host because that system has the fastest cpu.

I did succesfully compile ccminer on Centos 7 with Cuda 7 as a test but never actually ran it.
Given Epsylon3's recent post about cuda 7 I'd wait a while for that part of the upgrade. Your
experience with Centos 7 should be identical to Fedora, it's based on F19 IIRC.

I can post a very rough draft outline which might get you going if you're resourcefull, but be patient.
I don't have specific numbers for disk space but vs_comunity seems to insist on it being on the
system partition although it states "accross all drives" in its requirements. It is probably better to put cuda on that
drive as well. Probably 10 GB combined but that might not take into account temporary bloat during installation.
The ccminer files can be on another drive. How much space
you require depends on how many compute versions are coded and how many old compiles you
leave lying around. Your PC will be usable while compiling unless you are running other CPU intensive stuff.
You can easily be mining while compiling.

Disclaimer: Use at your own risk. I am not responsible for any loss or damage to your computer or your sanity.

1. need at least 20 GB disk space

2. download vs_community, cudatools

3. install vs_community

4. install cuda

5. download and unpack ccminer

6. open ccminer.sln

7. verify release, 32

8. change config to customize compute version
   project->properties->configuration properties->cuda c/c++->device
   select code generation, edit

9 build solution

10 find ccminer.exe in release dir

clean or distclean? If you modify config files you need to do a distclean. Otherwise there must be an error
in Makefile.am. A diff of the files may make the error more apparent.

A little quotation error corrected.

If you mean precompiled Windows binaries, they are still produced and available on the release page as
posted by SP. If you want to compile your own Windows binaries it not too difficult but very long and I might
be able to help. I've gone through it a couple of times and it can be done with all freeware, except for the OS of course.

In short you need Visual Studio Community and Cuda Tools, cminer source and lots of disk space. ccminer.sln is
the configuration file and you double click on it to open the "Solution" in VS. You can edit the properties to add
compute versions (similar to what Linux folks do with makefiles). Then Build Solution. Eventually if everything
works you should find a release directory with a freshly minted ccminer.exe file in it.

I can write up a better tutorial if you like but it will take some time.

Hardware shouldn't be an issue except for the CPU and GPU. There is no technical need, though you may have other reasons,
to have all the HW identical. Even the CPU and GPU differences can be ovecome in many cases. Different GPU generations
can be supported with a single compile as discussed in the part that I snipped. And differences in CPU extensions can be worked
around by specifying the arcitecture that works on the least capable CPU. Not really a good idea for CPU critical progs.

Software, of course, has to be the same.

I don't know if there is any benefit to having matching GPUs in the same rig. I tend to mix bigger and smaller cards as it's
easier on power supplies (I'm less likely to need a new bigger one) and heat dissipation especially on Linux where fan control
is usually limited to only one card.

Regarding your compile problems, and assuming they are related to the compute version setting in the makefile, the syntax
is pretty straightforward if you understand the difference between = and +=. Any C programmer would not have to think twice
but you've said many times you are not a coder so I'll offer the following.

= is a direct variable assignment. There must be exactly one of these for the compute version.
+= will add to the existing variable. There may be any number of these or none and they must be
after the direct assignment.
# is a comment. Those lines are not read by the compiler.

If you are compiling for only one compute version you only need the direct assignment of that version.
If you are compiling for multiple compute versions you need one direct assignment followed by as many
add assignments as needed to specify all the desired compute versions.

I took a close look at the code I posted and it should have worked for you as is. I also took another look
at your problem description, the part about Makefile.in. AFAIK that file is not part of the clone but created
by the compile process (either autogen or configure, not sure which). The point is did you do a make distclean
before attempting the second compile with the modified Makefile.am? I sometimes delete the tree and re-expand
the tarball if I'm having a bad compile day. You may want to reclone and edit (or replace) Makefile.am before doing
anything else.

I'm not sure what you mean by ccminer scaling and I have no data for the 960 but
I did observe fairly linear hash rate vs cuda count scaling among the 750ti, 970 & 980
in quark & X11. Don't know about neo and I do know that lyra2 doesn't scale linearly
(as was graciously pointed out to me).

I'm satisfied with using the default ccminer parms. It works on all my cards, including
compute 3.5,  and produces hash rates comparable to test results posted by others.

I see. You want the default makefile to work for your process. So compute_50 should be the default with others
being optional requiring manual intervention. Ex:


Or you could just install the supported cuda version and your process should work
with the existing default makefile.

I'm curious whether you do seperate compiles for each system or just one central
compile. If your environment is homogeneous you could compile once and distruibute
the executable to all rigs. This would simplify your process in the event manual intervention
(ie editting makefile) is needed. With a central compile there is less incentive to optimize
for only the arch you need, Ie less need to modify the makefile.

It wasn't my intent to mess up your process with my query. I was just wondering if there
was a technical reason for not including the compute_52 option, even in commented form.

Since compute_52 support doesn't exist in the default cuda version it makes sense not to enable
it by default in the makefile.