[ANN] sgminer v5 - optimized X11/X13/NeoScrypt/Lyra2RE/etc. kernel-switch miner

[sp_]

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.

[1714751772]

1714751772

[1714751772]

1714751772

[1714751772]

1714751772

[1714751772]

1714751772

[ivcelmik]

How can i delete DAG file at ETH miner and someone please help me with ca config file that works for AMD cards 7950

Thx in advance

[bradli]

How can i delete DAG file at ETH miner and someone please help me with ca config file that works for AMD cards 7950

Thx in advance

C:\users\user\appdata\local
in folder local you have another Ethash-delete
start ethminer to create new Dag

[ivcelmik]

How can i delete DAG file at ETH miner and someone please help me with ca config file that works for AMD cards 7950

Thx in advance

C:\users\user\appdata\local
in folder local you have another Ethash-delete
start ethminer to create new Dag

Ok i regenarate same proble can someone give me an example of bat file mining ethereum at suprnova at 170MHs with user amnd password for worker

Thx in advance

[ivcelmik]

How can i delete DAG file at ETH miner and someone please help me with ca config file that works for AMD cards 7950

Thx in advance

C:\users\user\appdata\local
in folder local you have another Ethash-delete
start ethminer to create new Dag

Ok i regenarate same proble can someone give me an example of bat file mining ethereum at suprnova at 170MHs with user amnd password for worker

Thx in advance

I get only invalid shares any ideeas beside regenerate DAG file?

[kenshirothefist]

I get only invalid shares any ideeas beside regenerate DAG file?

You're asking in the wrong thread, sgminer has nothing to do with Ethereum (try here: https://bitcointalk.org/index.php?topic=428589.0;topicseen) ... and related to his - it would be nice to get some better miner besides the clumsy ethminer for mining Eth ... it's really bad that Eth devs didn't include stratum support in Ethereum ... development of mining software and even providing better pools would be much easier if there would be stratum support directly integrated into Ethereum...

[bradli]

How can i delete DAG file at ETH miner and someone please help me with ca config file that works for AMD cards 7950

Thx in advance

C:\users\user\appdata\local
in folder local you have another Ethash-delete
start ethminer to create new Dag

Ok i regenarate same proble can someone give me an example of bat file mining ethereum at suprnova at 170MHs with user amnd password for worker

Thx in advance

I get only invalid shares any ideeas beside regenerate DAG file?

http://cryptomining-blog.com/5417-getting-started-with-ethereum-using-cpp-ethereum/

[depboy]

Anyone know how to get the best out of R9 290s on qubit?  I found this:

http://cryptomining-blog.com/4819-new-sgminer-with-optimized-quark-and-qubit-kernels/

But it doesn't have .bin files for 290/290x.

Best I'm able to get out of them currently is about 6 Mh/s which seems piss poor when you consider that 280Xs are reportedly getting 19 Mh/s.

[sp_]

Where did you get 19MHASH from? the 280x can do around 12MHASH on the 280x with this closed source miner.

1. install the latest driver 15.7.1
1. Rename the tahiti binfile to hawaii and put it in the same folder.
2. Run with sgminer with -w 64 -X 512

[depboy]

Where did you get 19MHASH from? the 280x can do around 12MHASH on the 280x with this closed source miner.

1. install the latest driver 15.7.1
1. Rename the tahiti binfile to hawaii and put it in the same folder.
2. Run with sgminer with -w 64 -X 512

All the hashrates on whattomine.com are based on a what a single 280X can do, aren't they?

I already tried renaming both tahiti and pitcairn .bins to hawaii.  One of them just plain didn't work, the other one gave me a shitty hashrate with high reject rate.  

Edit: Oops, looks like I had whattomine set up for a 750ti.  The (claimed) figure for a 280X is 16.85 Mh/s.  Still suggests I should be able to do a LOT better than 6 Mh/s on my 290s tho.

Edit 2: well whaddyaknow.  I tried again and this time it worked.  Think I tried a higher -w first time round.  Now I'm getting 12 MH/s per card.

[Pansyfaust]

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.

[MehZhure]

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.

[chrysophylax]

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.

hence the use of wolfs bins ... <broken record playing> ...

they are worth the effort and the cash to get them ... and they are stable ... very stable ...

i think wolf is back online too now - as i am ... but have no idea if he is providing the miners / bins ...

#crysx

[pallas]

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 ;-)

[MehZhure]

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.

[MehZhure]

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.

[pallas]

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.

Everybody needs a source of income, and we both know how opensource shaped computers in the years.
Actually, it's inherent in them, it's always been there. I remember a vic-20 cassette in 1984 with "public domain" software in it and a brief introduction to the term.
Even the most active opensource programmers must have their income and most of the times it's in computing as well.

[kopam]

Hey guys, was away from mining for some time and now coming back.

Can some one please tell me what is a good hashrate nowadays for 280x and 7950 - X11.

Thank you ! Appreciate  it !

[Foss]

Hey guys, was away from mining for some time and now coming back.

Can some one please tell me what is a good hashrate nowadays for 280x and 7950 - X11.

Thank you ! Appreciate  it !

--xintensity 128 -w 64 --vectors 1 -g 2 --lookup-gap 2 -s 0 --expiry 10 --queue 0 --gpu-engine 1100,1100 --gpu-memclock 1500,1500 --gpu-powertune 20 --gpu-fan 58,58

[MaxDZ8]

There's no need to CPU-sync for JHA/Quark use an append/consume buffer. This is especially the case if you don't pipeline work.
Have two atomics and a buffer, filling it with from head and tail depending on what path you need to follow.
Then dispatch both and have them branch-out when the count is exhausted, this will naturally produce N-1 fully coherent wavefronts with no sync required.

As a side note: DirectCompute11 even has helpers to do this in API, DispatchIndirect allowing to save the branch-out... in theory, under certain circumstances, maybe. Have you tried OpenCL pipes?