Second question, my calculations don't match yours. I find 970s to be better than 750Tis with version 51 of ccminer. As an example, here are two 6 GPUs rigs running Quark algo:
6 750Tis at 155€, 5730kH, 60W 450W PSU 43€ hashrate 34380, power usage 360W, price 973€. 35.33kH/€, 95.5kH/W
6 970 at 365€, 16200kH, 160W 1200W PSU 275€ hashrate 97200, power usage 960W, price 2465€. 39.43kH/€, 101.25kH/W
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.
|
|
|
Any chance there's a modded version of ccminer valid for x64 systems and humble (60$) videocards like mine? ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) Epsylon3/tpruvot still builds for compute 3.0 & 3.5 last time I checked. Or you could compile ccminer yourself.
|
|
|
I guess it's easy to see, I'm kinda new to yaamp, so excuse me for dumb questions. Here's one now...
When a coin name shows in red, what does that mean?
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. I see...well being short for payout means I won't be getting paid for a while. At least it doesn't mean it's no good anymore. Gotta mine something else. Darn! You can still mine it, you just don't want to mine something else and convert to it.
|
|
|
I guess it's easy to see, I'm kinda new to yaamp, so excuse me for dumb questions. Here's one now...
When a coin name shows in red, what does that mean?
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.
|
|
|
some explanation for the mining fees: each algo has their own fees. they're based on the underlying coins for each algo. fees are higher when there arent high difficulty coins to mine. the idea is to not overkill coins with too much hashpower and we try to limit the hashpower on these poor little coins. for example, the x15 fees are quite high because we're already mining 50% of the html5 coin's blocks, which is enough. so fees are based on the total hashrate and the sum of all coin's difficulty. here is the formula we use:
fees = log(total_hashrate / sum(coin_difficulty)) + 0.5
the change we just made is that the hashpower sent to rental is not used anymore in the above formula. that has an impact mostly on the quark algo. the idea is that since that hashpower is not used for mining coins, there's no reason to limit anything.
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.
|
|
|
Wow that's very nice. Before i make any conclusions, i'm going to wait until the new R93** series come out, but this is "for now" a winner.. Definitely for those with electricity costs. In my case, it's all about power. But as always, 750EUR, i can buy 2x 290x for that price. (keeping in mind that i don't have any electricity costs..). For 200EUR less, i would consider buying a few of those.. None the less, very nice ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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.
|
|
|
Sry for noob question...I'm new with nvidia cards
How do I get even start mine with ccminer 1.5.50? Where to put bat file and how to name it "ccminer or ccminer50"? I got 750 ti card. Anything else to do to run it. I want to run x11 algo
Sry again for this kind of stupid question
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.
|
|
|
I am just curious as to why v51 that should be faster for quark is considerably slower on my cards.
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?
|
|
|
You did AWESOME..!!!
I tried this a couple of months ago and was getting the same errors and I thought I was told that I needed the Full version of VS and the community version would not be compatible... I don't have that kind of money so I gave up until I saw your post. (the last time I bought VS was when VB6 came out (yea i know I am older than dirt)
anyway I ended up changing to release x64 and got it to compile just fine.. it is running and stable.
I do have exactly the same results with v50 being 400+ h/s faster than 51 and I am now trying to side by side compare the differences just to reverse engineer this and find out why it is slower...
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. As far as trying to reverse engineer this....ya really can't improve much on what sp_ has done. He, and the gang, are the best. I just test the product and let them figure it out. Just sayin.... Current code for blake mining returns the mining error... H-not-zero. Work on that. just out from left field here ... siacoin is going to be released in a few days - and works off blake2b algo ... any chance we could get that in also to mine sia? ... #crysx 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.
|
|
|
You did AWESOME..!!!
I tried this a couple of months ago and was getting the same errors and I thought I was told that I needed the Full version of VS and the community version would not be compatible... I don't have that kind of money so I gave up until I saw your post. (the last time I bought VS was when VB6 came out (yea i know I am older than dirt)
anyway I ended up changing to release x64 and got it to compile just fine.. it is running and stable.
I do have exactly the same results with v50 being 400+ h/s faster than 51 and I am now trying to side by side compare the differences just to reverse engineer this and find out why it is slower...
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.
|
|
|
Cuda 7.0 is not supported. Use cuda 6.5
no problem I dl 6.5 and tried to install... it said no compatible hardware found... i installed anyway.. now I get 41 errors when trying to compile.. I am sure I did something wrong here because if it can get messed up I will find a way to do just that. 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.
|
|
|
@sp_
I'm getting nothing. No shares are being solved. According to GPUTweak..the power % is jumping all over the scale, voltage is constant 1093mV, temp does rise as if it is working, vram usage is very low yet GPU usage would indicate it is mining, but I get no shares accepted. Did get a couple rejects /w reason...H-not-zero.
ASUS GTX750Ti DFseries 2GB /w 6pin ribbon. Ran in OC as well as stock. Just -a blake. Not a very good pool tho. Had trouble getting into, ..slow. Will look for a better pool.
edit: just tried to solo and again nothing, no connect. is port 8772 correct? Oh, when I say nothing, I mean that the .bat runs, but isn't giving much info. I did get the one above tho. Maybe that will help.
reject reason......H-not-zero
I think a lot of these tweaks to algos are done intentionally to break compatibility with current miners, particularly ASIC miners.
|
|
|
What do ya know...ccminer.exe compile worked. Next question....what do I delete now...everything in that dir or do I keep it.
Thank you again....think I'll copy those instructions and save 'em someplace.
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.
|
|
|
you suggested centos 7 from memory ... is that straightforward enough to get cuda installed and running within centos? ...
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.
|
|
|
ultimately its about building - compiling - rolling out - streamlining ... all clones of one worker ... all with linux - all with exact same hardware - all with ccminer-spmod
Hey Guys...for some of us...this stuff is all greek. ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) I made no sense of any of it and would really like to keep up with the Jones here. It would be nice to see some Win-install files, just like you had release #s before. So much love would come your way! ![Shocked](https://bitcointalk.org/Smileys/default/shocked.gif) Thanks 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. that actually would be good ... and highly beneficial jo ... i for one would like to learn how to build under windows ... hell - ill build a windows machine JUST for it ... tutor me / us please ... #crysx @joblo Yes! How much disk space do I need and will I be able to use the system while it compiles? I only have 1 and it's my mining machine, but I'd really like to learn to Windows compile. ASUS x77pro, Intel i7 3770, 16GB, 256 SSD, 1TB SSHD, 1TB HD, 2 TB NAS, Win8.1 pro, CUDA6.5 (have 7 too but not running). None of the HDs are completely empty tho, but I have combined space of ~.75 TB available on computer and ~1 TB on NAS. Running mine equipment is one S3+, three r-Box110s, two 1.3Mh Fury/Zeus, five RedFury USB sticks, three Gridseed duals, and I vid card mine (naturally) as well. I think that's it. What else do I need to D/L, and install for Windows compiling? Thanks much joblo 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. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 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
|
|
|
in this case - i did do clean - and that is part of the compile / installation script ... when i took sp's suggestion of copying back the previous makefile from the older v51 compile - the compilation went through without issue ...
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.
|
|
|
ultimately its about building - compiling - rolling out - streamlining ... all clones of one worker ... all with linux - all with exact same hardware - all with ccminer-spmod
Hey Guys...for some of us...this stuff is all greek. ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) I made no sense of any of it and would really like to keep up with the Jones here. It would be nice to see some Win-install files, just like you had release #s before. So much love would come your way! ![Shocked](https://bitcointalk.org/Smileys/default/shocked.gif) Thanks 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.
|
|
|
ultimately its about building - compiling - rolling out - streamlining ... all clones of one worker ... all with linux - all with exact same hardware - all with ccminer-spmod ( and sgminer at the moment for the current amd cards ) ...
i guess we will need to wait and see if any of these plans come to light ... im on this full time and daily now - so time is not an issue any more ...
edit - the compile still bombs ... but i am tired and need sleep - so maybe im doing something wrong ... tomorrow will work on it further ...
#crysx
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.
|
|
|
Anyone using some 960s? What are you getting for Quark/X11/Neo?
I assume ccminer doesn't scale and needs to be tailored to each cards gen.
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.
|
|
|
hi all ...
has anyone any issues with compiling since sp introduced compute_52 into the makefile? ...
sp - the compile crashes with - nvcc fatal : Unsupported gpu architecture 'compute_52' - since you introduced the compute_52 arch into git ...
even if you comment out the option in the makefile - the compilation bombs out with - config.status: error: cannot find input file: `Makefile.in' ...
could you 'fix' this please? ...
#crysx
Guess you missed this post.... https://bitcointalk.org/index.php?topic=826901.msg11475406#msg11475406If you only have 750s you don't need compute_52. As SP pointed out compute_52 will give better performance on 9xx cards. tanx jo ... i understand ... BUT - when the latest git clone was made and a compile got underway - the compile bombed out ... editing the Makefile.am and removing that part for compute_52 did nothing more than create more errors concerning a missing Makefile.in ... i have written a very simple script for the compilation of ccminer-spmod for our systems ... simple but effective - in that it automates the entire process from cloning to compilation to installation and rebooting of the system to mine with the new miner without manual intervention for each of the machines in the farm ... unfortunately - when there is an issue with the compilation ( as this has currently ) the process is broken ... which means manual intervention - and i REALLY dont like manual intervention ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) ... as per sp's advice - the compilation finishes successfully when the 'older' Makefile.am replaces the new one ( that is still currently in git ) and the latest ccminer gets compiled ... but that takes intervention on my part for EVERY miner in the farm - and that is a major pain ... so whether we need compute_52 or not - it exists currently in the Makefile.am when you clone and thus compilation crashes ... this was not an issue prior to the latest change - which made everything run automatically ... and im a lazy guy - that likes automation ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) ... #crysx 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: nvcc_ARCH = -gencode=arch=compute_50,code=\"sm_50,compute_50\" #nvcc_ARCH += -gencode=arch=compute_52,code=\"sm_52,compute_52\" #nvcc_ARCH += -gencode=arch=compute_35,code=\"sm_35,compute_35\" #nvcc_ARCH += -gencode=arch=compute_30,code=\"sm_30,compute_30\"
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.
|
|
|
|