 Show Posts
|
|
Pages: [1] 2 »
|
Wolf0, I see. As I have 6x 280x I can pay to you if you give me an advice how to mine more effectively than by sgminer with quark.
You may want to consider how much that would actually be, and the time he would have to invest. Let us assume Wolf0 is able to squeeze out 0.005BTC worth of quark mining daily for each 280x (just to keep it simple). As of right now, that equates to about $1.20 a day (per card). I would expect this could be a $1,000 - $10,000 project. How many years would you need to dedicate those six 280x cards to pay Wolf0 for his work? Maybe it would be a better idea to find out how much he would charge for such a project first, and then see if you can make payment arrangements. |
|
|
|
I might release the Quark bins (and a miner able to run them) for a smaller amount of BTC... problem is that SGMiner is infected with the GPL, and I really don't want to release the host code in this case.
maybe we could update the public sgminer sources with a simple multi-kernel version of quark, than you'd sell your optimized version to use with it. that is, unless there are fine tricks in the C part ;-) There are indeed. You see, for every branch in Quark, I read 4 bytes from the GPU on the host side - also, I run both sides of the branch in parallel, then block using OpenCL events until both complete before continuing. The key to Quark is how you do the general structure - the current source is beyond stupid. While I'll explain in detail (even publicly) how it's done if you want, I loathe to have to release working source for it. If people want it, they need to at least read the description and implement it themselves. I would be interested in that description. Just saying. All right. First, it's necessary to understand WHY the original Quark is so stupid - it deals with how GPUs tend to handle branching, that is, if/else decisions. They more or less don't. It'll execute both sides of the branch - whichever result isn't needed it will toss away. This means for every branch in Quark (there are three), the stock miner executes one extra hash function that it didn't need to. Now, you certainly can't read back the whole output of the hash for every work-item - it'd be fuck slow - so the host needs to be able to execute ONLY the hash that needs to be done for a given branch, WITHOUT branching on the GPU. I thought about this for a good while, and here is what I came up with. The host may not be able to read and process every hash for every work item in a reasonable timeframe, but what if I needed to read two 32-bit integers from the GPU only, and act on them, regardless of how many work items are run? With num_branches as the number of decisions on different hashes to run in the algo, and branch_possibilities being the number of possible ways a branch can go, allocate num_branches * branch_possibilities buffers. For Quark and Animecoin, this is three branches times two possible outcomes per branch. Each buffer should be the size of your nonce times the number of global work-items, plus one. Here's how you use them. Do the first hash in Quark, Blake-512, and then zero out the LAST INDEX of the buffers for the outcomes of the first branch. Index meaning the size of your nonce. This is done for speed - the buffers can be filled with garbage, as long as that is fine. The second hash in Quark is BMW-512, and it decides whether Groestl-512 is run, or Skein is. Pass it the hash states, the two buffers for our first branch, and the number of global work items (also the size of the branch buffers minus one; can't be gotten from OpenCL device code.) Do the hash, and the decision in Quark is whether the fourth bit of the output is set. If it is, Groestl is run, IIRC, otherwise, Skein. Now, if it's set, atomically read and then increment the last index of the first branch buffer, and store the nonce in the index you read. This is a counter, and how nonces are stored as well - this is why we zeroed it. If it's NOT set, do the same for the other buffer. Now, in your host code, you simply read out both numbers, each one being the number of branches that go to each possibility, and you launch that hash's kernel with the appropriate branch nonce buffer, and the number of global work-items as the number of branches that went that way. Inside this kernel, the global ID is then used as an index into the branch nonces buffer - it'll pull out each and every nonce that is appropriate for that branch. Since we use the original global ID as not only a nonce, but an index into the hash states - the hash states may be indexed with the number you pulled out of the nonces buffer to fetch and store the state for that work. Final note for optimization - I lied. You actually need to read only ONE nonce-sized entry from a branch buffer; I said two because it makes the process easier to understand. Basic algebra - since we know the global work-item count already, all work items branch SOME way, and they can only go two ways, the number of work-items that branched, if added, will equal work-item count. i.e. GlobalWorkItems - Branch1LeftCount = Branch1RightCount. So... read only one of those entries denoting the number of nonces stored in a branch buffer (doesn't matter which), and subtract it from the amount of global work items to get the other. So, that's my technique for the overall structure of Quark. Any questions? Pallas, we're not so different. While you believe in open source and I sometimes do not, I still believe in sharing knowledge, even to my detriment. If someone's reasonbly intelligent and willing to work at it, I'll never refuse to help them learn. Hmmm. Well, that definitely changes how I think about GPU processes. I did not realize they execute both branches. Also, thanks for the detailed description. I greatly appreciate it. |
|
|
|
I might release the Quark bins (and a miner able to run them) for a smaller amount of BTC... problem is that SGMiner is infected with the GPL, and I really don't want to release the host code in this case.
maybe we could update the public sgminer sources with a simple multi-kernel version of quark, than you'd sell your optimized version to use with it. that is, unless there are fine tricks in the C part ;-) There are indeed. You see, for every branch in Quark, I read 4 bytes from the GPU on the host side - also, I run both sides of the branch in parallel, then block using OpenCL events until both complete before continuing. The key to Quark is how you do the general structure - the current source is beyond stupid. While I'll explain in detail (even publicly) how it's done if you want, I loathe to have to release working source for it. If people want it, they need to at least read the description and implement it themselves. I would be interested in that description. Just saying. |
|
|
|
So far....changing Xintensity to I-19 seems to be more stable. I also turned gpu threads- 2 and that also seems to help. Getting 7.29Mhs on 280X 1100/1500
The new kernals use more power. I have problems with many cards. With 2-3 cards per rig they work fine. I fill the extra slot's with low profile NVIDIA cards. If you put the NVIDIA cards first and run sgminer with --gpu-platform 1 then the russian miner is unable to fuck the voltage and they run stable for weeks. Even with I-19, the russian bin is still quite unstable in terms of longevity without restart. I have tried it and noticed it was unstable. I let the miner run for quite a while, and thought I was getting a great hash. I checked my pool.....the miner had stopped submitting shares hours earlier. It is definitely fast. But, it is also unreliable. All I can say is, if you run it, make sure you check it every hour, or you will end up burning several hours of electricity with no return. |
|
|
|
HI guys need help has someone tried to mine with 7x 7950 HD Ethereum on windows 10?
there is a possibility to downgrade to whatever was your OS before win10 during the first month... I suggest you push that button it takes about 5min to get back your previous OS I have to second that opinion. Win 10 is a definite no-go. Forced updates (regardless of stability), no privacy, and they steal your bandwidth. Seriously, I would avoid this disaster like the plague. |
|
|
|
Perhaps profit is the wrong goal to seek. Disestablishment of the bank-led catastrophicly bad double-or bust economy whilst protecting transaction banking for all honest productives worldwide is closer to my reason for wanting bitcoin to go well.
It is interesting you happened to mention that. I just read an article this morning on the Greek banking situation, and how people were desperately trying to get their lives back in order, but the banking restrictions are so draconian as to keep people from even paying there every day bills. The thought that occurred to me whilst reading through the article was along the lines of how a sudden "mass-adoption of crypto-currencies" throughout Greece could almost instantly render the banking restrictions null and void. Plus, it has the potential to permanently end the bank's control over the Greek citizens. |
|
|
|
|
Ah...nevermind. I figured out that you can use a conf file in the miner directory to add any specific miner settings. Originally I had the pool settings in the conf file, and multiminer cannot work with that. But, if you remove the pool settings, everything else works great.
|
|
|
|
|
And, for clarification, the sgminer can only handle 11 commandline arguments. The multiminer is trying to start it up with 21 arguments, several, of which, are nothing more than default values that do not need to be set.
|
|
|
|
|
I have been trying to run multiminer for about a week and a half now, without success. What I have discovered is, multiminer is adding a bunch of extra commandline arguments, that I do not need, and my sgminer errors out because of it. Is there a way to change what extra commandline arguments multiminer adds automatically?
|
|
|
|
Which exact sgminer build are you using if you don't mind sharing?
V4 and later. They all have the same result. |
|
|
|
I've never mined before but i am looking into it. Is it possible to make a profit mining cryptocurrencies with an average computer? I have read a decent amount about mining, and I know its not a get rich quick scheme, but are there any currencies where mining is actually profitable without ASIC or a powerful computer. If so, what currencies would you recommend to start mining?
It depends on what is required for you to get started, and what you mean by "profitable". If you already have a computer that is running 24/7, and a reasonably powerful gpu, then absolutely it is profitable. you won't get rich doing it, but you will make money. The trick is to find the sweet spot of efficiency. In other words, running your gpu at maximum possible hash may not be the most profitable. Figure out your power usage vs the amount of money you make, per day. Look for the sweet spot between minimum power usage and maximum hash rate. If you are considering setting up a gpu farm....then you have to factor in how long it will take to recover the equipment cost. if you are rich, then you can just eat the equipment cost and set it up as an extra income source. If you are not, and need to recover those costs.....then you need to seriously do some major planning. Everyone wants to get in on coin mining. Which means, if you don't go huge right off the bat, you can't ever recover your equipment costs. Why? Because as time passes, mining always becomes less and less profitable. I have already seen a few people with gpu farms talk about shutting down until it becomes profitable again...if ever. |
|
|
|
what kernel are you using MehZhure ??
I believe it is Wolf0's. So far, it has been stable for 16 hours and counting. |
|
|
|
I did some further tweaking to see what kind of speed I could safely get out of a single r9 290. So far it isn't too bad. I had to run a bit slow for a couple hours, and thought I would just see about pushing it to make up for lost time.
taking my avg stats over the last 50 mins (since I started tweaking the settings for speed, I am turning up an avg rate of 111.8%. The actual interesting part is my temps. The gpu is staying at or below 70C, and the vrms are staying at 90C. The power usage is 209.7W. So, a 16% increase over stock settings with only 8 W more power usage.
It will be interesting to see what I get from the 290x when it arrives.
But to be honest, I don't understand how this is possible. Perhaps you can share more details? Brand of the card, operating system, driver... Maybe it is already R9 290 X? :-) I have Sapphire R9 290 TriX and that's a reference 100%. But somehow your R9 290 is 11.8% faster. ?! This same card only does 7.68 MHS on Wolf0 miner. So your 9.6mhs is also quite an achievement! It is an XFX R9 290A EDBD. I am running on Win 8.1. And I am using Catalyst 15.7. The system is based on an Intel Core i7-5820K Haswell-E, and has 32GB of DDR4 RAM. Honestly, I think I just found the sweet spot that my gpu prefers. I just checked it, and it has been cranking on these settings for 17 hours without any issues. Better yet, my displayed avg was slowly catching up with what xpool was reporting (> 10 Mh/s). |
|
|
|
same worksize and xintensity that you use for 2 threads? I use 64 for each.
That is correct. 64 on both. |
|
|
|
appreciate that ...
i no longer hold any 290 or 290x cards - only gigabyte 280x oc cards now in the farm ... so it really is purely for the 'how' ... for me anyway ...
-g 3 can work well with sgminer - but i have found that ( at least with the 280x ) that a higher clock rate and a lower thread count ( -g 2 in the 280x - at 1100 gpuclock / 1500 memclock ) it worked the best ... some cards work really well at 1125 / 1500 ( or even 1125 / 1490 ) but the gigabyte ones i have cant be pushed that far - and are restricted to the driver version contained in the repo for fedora 19 x64 ...
im just too damned lazy to do implicit installs on each and every machine contained in the farm ...
as for the power usage ... you will find that with EVERY card used today ... and it all boils down to the heat ...
no matter how good your heat dissipation may be - the rule of thumb is simple ... the higher the clocks - the higher the heat generation - the higher the power ...
thefarm is a perfect example of that ... when its freezing cold ( not that i could get it that cold - but humor me and just flow ) - thefarm uses the least power yet hashes the same if not better than when its warm or hot ... adversely - the hotter thefarm - the more power it uses for about the same hashrate ...
so its got to work harder the hotter it is - which uses more power ...
anyway - bed for me ... im stuffed and babbling now ...
#crysx
That is has been my experience with electronics in general. In this case, the temperature is remaining constant, but the power usage keeps rising. Matter of fact, as of right now, the power usage has continued to creep up, and is currently sitting at 171.0W. The voltage has ticked up another notch, and the amperage has increased by about 1 amp since I last posted. |
|
|
|
Not sure the settings are going to be stable just yet. There is one weird quirk I have observed, and it is making me a bit suspicious. I have noticed it happening on three different restarts so far. The first was several hours ago, when I first ran across the settings. The power usage started out at about 150W. Over about an hour, it had crept up to about 160W. I wanted to try some different settings, so I changed the conf and restarted. This time it started at about 166W. Over about 4 hours, it crept up to about 175W. Just to see if I was losing my mind, I decided to shut down and let the system cool all the way down. Once it was sitting at 38C, I restarted. Power usage was about 166W on startup. It has been running for 36 minutes, and the power usage is now up to 169.4W. And now it is 169.5W. I just noticed both the amperage and the voltage increased by the minimum increment. And now it is 169.6W. I don't know. Something just doesn't feel quite right about it. Oh, as for the "magic number".... and this to your conf file Maybe it doesn't work for everyone, but my gpu really likes running 3 threads. |
|
|
|
|
Tweak the settings, and tweak some more. Try different bins. Tweak settings again. And again. And again. Finally, I think I found the sweet spot. My r9 290 has been stable for 4.5 hours now. The temp has stayed under 65C. The power consumption has stayed about 175W. Sgminer is reporting a hash rate > 9.6 Mh/s and my mining pool has continuously been reporting my accepted hash rate is at, or greater, than 10 Mh/s.
|
|
|
|
|
That is a bit of a bummer about the drop in profitability. That said, it isn't all bad, at least for me. This drop in profitability spurred me to switch back to xpool and do some further tweaking of my settings to try and drive up my profitability. And wow. Some of the stuff I have learned over the past few days, reading and experimenting, has helped significantly.
As of right now, my 290 has been staying at, or below, 64C. The vrm is staying at about 73C (well below the 90C I have seen in the past). And the avg power draw is currently 172W. I am showing a > 9,6 Mh/s in the sgminer display, but xpool is reporting my accepted avg hash rate to be 10.2 Mh/s. I honestly did not think this was possible with a single r9 290. Oh, and no HW errors, and 0.9% rejection over the last hour...since I started up with these most recent settings.
Looking forward to seeing what I can manage to attain with the 290x.
|
|
|
|
Well, I can't say for sure whether all the hype about the new x11 algos is definitely a thing, but I have tweaked the heck out of my settings, and am getting a really nice efficiency. When I started last week, i was getting about 4 Mh/s on my r9 290. Tried some of the bins floating around and managed to get 6 Mh/s while maintaining a stable 60C or less, with a power draw of 113W avg. I continued to tweak the settings and I finally found the sweet spot for my card.  You can see, my last round of tweaks has really squeezed the performance up. Stable at 64C, the vrm is well below my 90C limit, no HW errors, and stable at 9.6 Mh/s....going on 40 minutes now. And best of all, the avg power usage is only 155W, and my avg accepted hash rate with my pool (9.84 Mh/s) is higher than the rate I am showing. Hopefully these settings will prove to be stable over long term. |
|
|
|
|
Just an FYI for anyone running on dashminer... I am using BitDefender for my antivirus/firewall. It does NOT like the dashminer version of sgminer. I have had to make rules so BD will stop quarantining it. And once I did that, I have continued to fight with it to allow sgminer access to the internet. I decided to post this because I walked away for about 10 minutes, and when I came back, BD had locked the sgminer out of the network for the third time.
|
|
|
|
|
