or just mine at nicehash. They pay around 0.45BTC per GHASH now..
0.29 right now. What the hell is happening with quark coins? Time to investigate... Here are a few quark coins with how much BTC worth of coins are getting mined each day with current prices: BitQuark (BTQ) ~0.01 BTC; MonetaryUnit (MUE) ~0.031 BTC; QuarkCoin (QRK) ~0.057 BTC; Dimecoin (DIME) ~0.11 BTC; SecureCoin (SRC) ~1.51 BTC; SharkCoin (SAK) ~65 BTC. Sharkcoin started blowing up since early May, its price increased close to 10x and now the nethashrate is around 120-150 gh/s. Make of the numbers what you will. Ps: I feel like I forgot at least one relevant coin but can't figure out which. I presume those numbers are btc/GH/s/d. They seem way off compared with a week ago on yaamp and what is currently reported on miningpoolhub (SRC .32, QRK .22). And I have no idea about SAK except that I can't find anywhere to trade it.
|
|
|
Another thing, in mining Lyra2 my GTX 960 cards mine more slowly than a 750ti. I don't understand it. I think there may have been another post on this 10-20 pages back, but this thread is getting long. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) --scryptr It seems lyra2 is memory bound. Unless the 960 has more memory I wouldn't expect a big increase, but I wouldn't expect a decrease either.
|
|
|
Hi guys, not sure where to post this. I've published an issue on github about it : https://github.com/cbuchner1/ccminer/issues/311.5.53(sp-mod) does not submit anything. I have tried several pools, it doesnt say reject, it just says nothing. It goes on and on showing me a hashrate, but nothing is ever submitted. I've googled this a lot, but to no avail. Anyone had this issue before ? I'm on RedHat, CUDA 7.0, nVidia GRID K2, compute 3.0 (is support for 3.0 dropped in this version ?) You need to enable compute 3.0 in Makefile.am. There is some discussion on how to do this earlier in this thread. I have no 3.0 cards but I can confirm it works on 3.5. Also stick with cuda 6.5 for now. FYI this isn't the kind of problem that warrants a ticket. Besides the fact that you ticketed the wrong fork SP is focussed on 5.0 and above and unlikely to respond to a problem affecting other compute versions, even a legitimate problem. However, you're in the right place now. Be sure to post your results. Edit: Ooops, cuda 6.5 not available on Redhat 7
|
|
|
Thanks, Joblo, but my goal wasn't to setup my rig to auto-switch algo's, rather to know which was more profitable for reference. Yes, I know that. The page I pointed to lists the algo normalization factors so you can compare the profitability among all the aglos. Now if only the pool would come back up.
|
|
|
Testing Release_53
x13 algo: error; " Cuda error in func 'quark_blake512_cpu_setBlock_80' at line 714 : an illegal instruction was encountered. "
I made no changes to previous setup being used with switches; -i 18.9 -r 5 -R 10 --cpu-priority 2 -a x13 required a graphics driver reinstall or reboot.
x11 algo: error " Cuda error in func 'quark_blake512_cpu_setBlock_80_multi' at line 706 : an illegal instruction was encountered. "
Again, no changes from previous switches; -g 2 -i 18.3 -r 5 -R 10 --cpu-priority 2 -a x11 required graphics driver reinstall or reboot.
OK...that's all the testing I can do today. Am going back to 51.
later-
That looks like a problem with the ccminer executable. Try recompiling or redownloading as appropriate.
|
|
|
970 (GV-N970WF3OC-4GD - 250w OC edition instead of 145w): stock - 2.75 mh/s at 187W oc - 3.0 mh/s at 208W (+185/0 - 1501mhz)
I had assumed the 970 TDP would be within the 145W Nvidia spec except if OCed. It seems that assumption was way off. I didn't find an actual TDP spec for this card, just PSU and connector reqs. Is it really 250W? This changes the balance of power (bad pun) and makes me wonder about the 980 rated at 165W.
|
|
|
sorry if I get offended easily but some comments around (not necessarily yours) sounds like that if it isn't in sp release it is crap... (or not optimized or whatever...)
If gave you that impression it was not my intent. There are several reasons the focus is on SP. First it's his thread about his release. It's also the most popular fork at the moment and the center of most of the discussion. It is also my impression that it is the most complete open source version of ccminer and that optimizations, new kernels, etc, written by other devs will be merged by SP. If there are other open source forks that have advantages over SP's I am not aware of them. Even if there are I don't think it would be fair to SP to hijack his thread to discuss another fork of ccminer at length. However, I do take notice when SP posts that he has imported code from another dev. And I do visit the gits of these devs to see what else they are up to.
|
|
|
I don't get some of you guys who are deeming closed source miners being unfair.
Fee doesn't necessarily mean closed source.
For the record I'm not against a fee of some sort but I do prefer open source. The problem with combining the two is, as wolf0 pointed out, that anyone can code out the fee. Actually, that's not the actual biggest problem. Most people simply would be too lazy to figure out how to remove it if they don't know already, and some people would even support it. The real problem with a GPL'd miner is that anyone can edit it out and then redistribute it. Yikes, even worse distribute with their own fee replacing the dev's. That's really low.
|
|
|
I don't get some of you guys who are deeming closed source miners being unfair.
Fee doesn't necessarily mean closed source.
For the record I'm not against a fee of some sort but I do prefer open source. The problem with combining the two is, as wolf0 pointed out, that anyone can code out the fee.
|
|
|
An alternative funding scheme I would like to propose is that coin devs get more involved in funding open source development.
They are already doing it, that's how you got: lyra2re, coinshield, yescrypt (Yglobalboost), pluck, ziftr,creditcurrency and others True, a coin that is first to use an algorithm needs to have a functioning miner but the coin devs don't seem very interested in optimized miners. Their fear of ASICs, and to a lesser extent GPUs means they choose algos that are particularly difficult to optimize, which in turn means only the most talented coders can implement those optimizations. I'm not suggesting coin devs lead the charge to ASICS but they should try to keep open source miners at optimum to discourage the development of private kernels and ASICs which tilt the playing field. That's funny in and of itself because a optimized miner is essentially the equivalent of what ASICs brought to market for sha256 and then scrypt. It makes all other tech irrelevant when it starts spreading. Initially it doesn't make a big impact, but with enough bulk it pushes everything else down. It's the same thing. Not quite. Everyone has a CPU, many have a GPU, few have an ASIC miner. As you go up the ladder you shrink the user base. Optimizing the lower end slows that arms race. Whether it can stop it can be argued but 1 1/2 years later there is still no x11 ASIC AFAIK.
|
|
|
Yaamp tries to pick the most profitable coin per algo, points miners there, then auto-exchanges to BTC. Sounds great.
But how profitable is each algo at the time vs ... mining basic LTC for exchange, or, just mining BTC?
About a year ago, another algo mining exchanger site, Wafflepool, went down for the count. That site had a running profitability comparison showing estimated value add for this or that algo vs LTC or BTC. I'm sure it was not so accurate, but it could give miners a sense that ... X11 might be better today, or Scrypt-N, etc.
I'd like to see a profitability percentage vs LTC or BTC added in a column beside supported algo's on Yaamp. It's helpful to know the more profitable algo both for setting up one's rig's, and also for watching the exchanges and / or rig rentals scene. .
http://yaamp.com/site/multialgo
|
|
|
An alternative funding scheme I would like to propose is that coin devs get more involved in funding open source development.
They are already doing it, that's how you got: lyra2re, coinshield, yescrypt (Yglobalboost), pluck, ziftr,creditcurrency and others True, a coin that is first to use an algorithm needs to have a functioning miner but the coin devs don't seem very interested in optimized miners. Their fear of ASICs, and to a lesser extent GPUs means they choose algos that are particularly difficult to optimize, which in turn means only the most talented coders can implement those optimizations. I'm not suggesting coin devs lead the charge to ASICS but they should try to keep open source miners at optimum to discourage the development of private kernels and ASICs which tilt the playing field.
|
|
|
I don't think the next kernals will be Opensource. I try my best to keep high standards, but you have quality coders like djm34 and wolf0 who push the standards.. The current quark implementation is good, but djm34 hash pushed it more than 10% faster after a few afternoons of work. Take a look at the neoscrypt kernal. It is really good... 300% faster than the opencl is insane...
I added another 50% by rewriting the blake implementation. but the sp-mod is only 7% faster than the djm34 mod.
and the Wolf0.. He is good. He is like me when I was 20..
Many have interpreted this as meaning you will go closed source. To me it looks more like you think you won't be able to compete with the devs of private kernels in the next round of optimizations for Pascal. I hope this is just a temporary lack of confidence because your contribution to Maxwell has been invaluable and would be equally welcomed on Pascal. The problem with miner development is it's extremely competitive. If I build a better miner it is in my selfish interest to keep it to myself. I can mine at higher efficiency while facing less competition from other miners. If I give it away I lose my competitive advantage. If I sell it I still lose my mining advantage but I can still profit from my work. Open source miner developers should be commended for their generosity. Not only do they forgo profit for themselves they make the mining environment better for everyone. Their continued presence also keeps the closed source devs honest. An alternative funding scheme I would like to propose is that coin devs and rental services get more involved in funding open source development. Coin devs would have an interest in keeping the mining environment for their coin fair. An elitest environment where only those who pay get good mining performance would be seen as unfair and would discourage many miners. Rental services like Nicehash would also have an interest in promoting more efficient miners to their users. In both cases there is no incentive to keep better miners secret. I would like to give a shout out to chrysophylax who is a coin dev, farm operator and major donator to open source ccminer. If other coin devs would get similarly involved it might be enough to get some of the closed source miners opened.
|
|
|
To yaamp:
What's up with SAK? I was mining quark when SAK went live and got a share of the first block (1773850) but then it just vanished from my earnings. The pool shows the block as matured. Where did my share go?
|
|
|
are you really getting 10,000 MH on quark out of a 970 ?? or did I read this wrong..
I only get 10,000 KH per card how are you getting double ??
GIMMIE !!
You should be getting around 16,000 KH/s quark on a 970. I'm not sure what could cause that sort of deficit. That seems too much for throttling. The old version of ccminer might do it but I assume that's not the case. An incorrectly compiled ccminer, omitting compute 5.0 & 5.2, might do it. The CPU or GPU bogged down by other processes is also a possibility. Do you have any other cards, how do they hash?
|
|
|
I'm having trouble compiling on linux (ubuntu 15.04): nvcc -gencode=arch=compute_52,code=\"sm_52,compute_52\" -gencode=arch=compute_50,code=\"sm_50,compute_50\" -I/usr/local/cuda/include -I. --ptxas-options="-v" --maxrregcount=128 -o heavy/heavy.o -c heavy/heavy.cu nvcc fatal : Unsupported gpu architecture 'compute_52' Makefile:2048: recipe for target 'heavy/heavy.o' failed make[2]: *** [heavy/heavy.o] Error 1
You need the version of cuda 6.5 that supports 9xx cards. https://developer.nvidia.com/cuda-downloads-geforce-gtx9xxIf you don't have any 9xx cards you can remove compute_52 from Makefile.am. Edit: assuming Linux, edit project properties on windows. Note the "+" was removed from the compute_50 line. #nvcc_ARCH = -gencode=arch=compute_52,code=\"sm_52,compute_52\" nvcc_ARCH = -gencode=arch=compute_50,code=\"sm_50,compute_50\" #nvcc_ARCH += -gencode=arch=compute_35,code=\"sm_35,compute_35\" #nvcc_ARCH += -gencode=arch=compute_30,code=\"sm_30,compute_30\"
You can also run 9xx cards with only compute_50 but presumably at lower performance. Is it a new thing? I compiled 1.5.51 without any problem. And since my rig only has 750 Ti, I shouldn't even need compute 5.2 for now. Thanks for giving me the line to change. It works. Yes, fairly new. Since most people have 9xx cards now it only makes sense. The Windows binaries have had compute 5.2 for a while, you would only run into problems if you tried to compile.
|
|
|
I'm having trouble compiling on linux (ubuntu 15.04): nvcc -gencode=arch=compute_52,code=\"sm_52,compute_52\" -gencode=arch=compute_50,code=\"sm_50,compute_50\" -I/usr/local/cuda/include -I. --ptxas-options="-v" --maxrregcount=128 -o heavy/heavy.o -c heavy/heavy.cu nvcc fatal : Unsupported gpu architecture 'compute_52' Makefile:2048: recipe for target 'heavy/heavy.o' failed make[2]: *** [heavy/heavy.o] Error 1
You need the version of cuda 6.5 that supports 9xx cards. https://developer.nvidia.com/cuda-downloads-geforce-gtx9xxIf you don't have any 9xx cards you can remove compute_52 from Makefile.am. Edit: assuming Linux, edit project properties on windows. Note the "+" was removed from the compute_50 line. #nvcc_ARCH = -gencode=arch=compute_52,code=\"sm_52,compute_52\" nvcc_ARCH = -gencode=arch=compute_50,code=\"sm_50,compute_50\" #nvcc_ARCH += -gencode=arch=compute_35,code=\"sm_35,compute_35\" #nvcc_ARCH += -gencode=arch=compute_30,code=\"sm_30,compute_30\"
You can also run 9xx cards with only compute_50 but presumably at lower performance.
|
|
|
In my example the 970 only has one 8pin connector instead of a 6+8. Same watts, less areas for delivery.
My 970 has 2x6 pin PCIe connections which is the same as 1x8 which is enough for the rated power with headroom for OCing. Some 980s (165W) have only 2x6. That shouldn't cause problems for the connectors unless they are defective. The only real benefit I see with connector overkill is offloading the PCIe bus, a good idea in multi GPU rigs. As far as areas of delivery there are only 2, the bus on one corner of the card, and the connector cluster at the opposite corner. Adding pins to the connector cluster doesn't create more areas of delivery, it only increases the capacity of the cluster area. Adding more areas requires power connectors at different locations on the card, but that would complicate cable management and airflow. Anyway it looks like your problem is fixed and I don't expect your connectors to melt, but don't sue me.
|
|
|
Just a fyi guys. More power plugs on the card does not mean the card will use anymore or any less power. That is determined by the core voltage. You want more auxiliary connector as it gives you more methods to supply power to the card. You can always use a four pin molex connector/adapter. I just bought a 970 Asus strix for instance and despite it only.having a eight pin power adapter it uses more power then a different brand 970 that has a eight+six adapter. This means more voltage is being drawn through.the eight pin then should be and as a.result its.triggering over voltage.protection on my psu. I'll have to change it with a dumber psu.later tonight which should be fine.
This happens at stock clocks after moving tdp over 100 which immediately triggers it. I haven't even tried over locking it yet. I am debating on sending them back for a.different model as even if I use a different psu its stressing the connector more.then it should. Having seen melted connectorrs with my 290s while mining scrypt (psus fault) its a good idea to errr on caution. This applies.to.750s as well.
Tldr more power connectors the better.
The card is rated at 145W, the 8 pin can handle 150 plus 75 from the slot. I don't think the problem is the connectors. I'm also not sure about an over-volt fault. If the card is drawing too much power it would cause a volatge drop. An over-volt might be the PSU or the mains. If you're confident about the power send the card back.
|
|
|
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. whats your take on the 980ti? ... if it seems to be the best value - then it may be worth the effort of replacing the 750ti cards ... It really depends on price and whether the price premium for the 980ti is a good tradeoff for the increased density. I don't have CAD pricing for the 980ti but the 980 has a higher cost/hash than the 750ti, 960 & 970. I expect power efficiency to be comaparable to the rest of the 9xx family
|
|
|
|