Topic: [ANN] TeamRedMiner - Optimized Win/Linux AMD GPU Miner for lyra2z and phi2 - page 32. (Read 85791 times)

I do not have a rig itself. I have running 4x Sapphire RX580 8Gb on a conventional PC, under W10 (in my case it is mandatory).

My numbers are not very different from yours. Slightly less than 5mhs in PHI2 (pickaxe pool). Tuning with OverdriveNTool: Core 1220/910, memory 300/800, fan 576/2280. Hwinfo GPU chip power wattage, 90w each approx.

I do not see much difference in performance/stability between the beta version and the stable ones.

Regards!

Hi keksik,

You might want to try running linux on your rig.  Polaris hashrates for lyra2z/phi2 under linux tend to be better than under windows due to limitations of the windows drivers.
Getting your clocks/voltages configured right under linux can be a challenge.  Most users usually just bios mod them so they are correct right off the bat with no need for tuning inside of linux.

7x vega 56 reference cards rig. 1408/875 1100/875

lyra2z 40mhs 1200w from wall
phi2 65mhs 1150w from wall

lyra2z acm mining at the moment could be more profitable than xmr mining, but i had some wierd stuff with acm mining so i am sticking with xmr.

my cards
core is for all cards 1200/900mV, mem is or each cards below:

1 XTR 8G Hynix 2200 H5GQ8H24MJR
2 XTR 8G Hynix 75,4 2225 H5GQ8H24MJR
3 GIGABYTE RX 580 GAMING 4 GB  Hynix 76.1 2000 H5GC4H24AJR
4 XFX RX 580 GTS XXX 8 GB Samsung 73.8 2025 K4G80325FB
5 GIGABYTE RX 580 GAMING 8 GB Hynix 74.4 2200 H5GC8H24MJR
6 GIGABYTE RX 580 GAMING 8 GB Hynix 78.2 2200 H5GC8H24MJR
7 GIGABYTE RX 580 GAMING 4 GB Hynix 73.9 2000 H5GC4H24AJR
8 GIGABYTE RX 580 GAMING 4 GB Hynix 71,5 2000 H5GC4H24AJR
9 GIGABYTE RX 580 GAMING 4 GB Hynix 75.8 2000 H5GC4H24AJR
10 GIGABYTE RX 580 GAMING 4 GB Hynix 77.2 1975 H5GC4H24AJR
11 Sapphire PULSE RX 580 8 GB Samsung 76.3 2050 K4G80325FB
12 GIGABYTE AORUS RX 580 8 GB Hynix 71,3 2100 H5GC8H24MJR

my stats for Phi2 - lux

my bat file
teamredminer.exe -a phi2 -o stratum+tcp://eu.bsod.pw:11518 -u wallet -p c=LUX -d 0,1,2,3,4,5,6,7,8,9,10,11

my results are
approx 5mhs,so for 12gpu 60.4Mhs.

my bat lyra2z
teamredminer.exe -a lyra2z -o stratum+tcp://eu.lyra2z.com:4555 -u PEgBKYxM2Njd47dxkbMFR7eHMacTuMDCbf.12rig -p c=ACM -d 0,1,2,3,4,5,6,7,8,9,10,11

my results are
approx 3-3.2mhs per card,so for 12gpu 38.17Mhs.

anyone got better results? if yes,please share your setup.thx

Thank you for the explanation. I think 0.3.6 is performing a little better with this, but maybe it's too early to tell after only running the miner for 4 hours. I would appreciate any improvement you can make in this area. Do you have any suggestions of how I can automatically convert my GPU power into BTC other than Nicehack?

Hi! I’m guessing you’re talking about CNv8? Awesome if we keep the questions for CNv8 in the separate ann thread in the future, but no worries this time:

Nicehash mining is a little problematic with CN. Calculating a round of hashes for CN takes > 1 sec. For other hash functions numbers in a few ms are more common. So, CN has a much higher probability of your hashes being stale when the gpu job completes. For e.g. direct xmr mining, with a long block time, pools are generally nice about accepting shares for both the current and the previous pool job, so it doesn’t matter much if you got a new job 0.5 secs before you found a share.

For nicehash, this isn’t true. They can throw you around between client orders every 5 secs and are generally more picky with stale shares. A better way to handle nicehash is to abort ongoing gpu work when a new job comes in and start on the new job instead. This means you will throw away precious time on the gpu instead though whenever a job switch occurs, so it’s not 100% sure you’ll be better off anyway.

We have abort support but have not enabled it yet. Bottom line is that nicehash is problematic, we support mining there but you will take a hit in your poolside hashrate compared to normal/direct coin mining.

I am getting a lot of shares rejected on Nicehack with the message "Error code: 2 - Job not found"

What version are you currently running, and which algo are you targeting? We released 0.3.6 an hour ago, but I'm not sure it will solve your problem.

which version are you talking about, because version 3.6 was just released.

i have Vega 56 with ~1500 core clock ~935 mv, mem clock is 910 mhz and 925 mv. Latency is around 75-100 ms, will wait for new version to initialize problem.

The shares stats are found/accepted/rejected shares. It also seems we have an issue, and in all the examples I've seen it's with nanopool. The nrs should add up such as found = accepted+rejected, but you have a significant number of shares missing. I'm guessing there is something with either how we submit or how nanopool responds (or doesn't respond) to some shares.

Overall, I think you have a too high reject ratio, yes. Do you have a high latency to the EU stratum for nanopool?

We are missing the standard cpu verification feature in our miner, we will add it shortly. That means we can separate hw/mem errors, right now I can't say if this is "normal" network latency or if your mem clocks are too high or voltage too low .

Ok dev, i understand your position, tnank you for detailed answer, i'll cointinue use this miner anyway.
I can't understand situation with shares, tell me what does mean 1st 2nd and 3rd number please. Is there too much rejects on the screenshot?

I understand fully. Unfortunately, we don't have the bandwidth to develop for the older GCN generations as well, the overhead for us is much bigger than letting a compiler generate code for a different instruction set. There are probably a good amount of those cards left, but it's also reasonable to assume that they are decreasing by the day in numbers. Sorry

I would love it if you could support Hawaii cards.

Yep, we don't even list the R9 as a supported card, so sort of expected. Vega/Polaris/Baffin are officially supported. It "should" work as its Fiji, but we would need to test and trim it for the R9s.

 

lyra2z r9 nano stock: around 3.2MHASH
cryptonight v8: broken

Hi!

Thank you for using the miner!

I really don't want to get into any prolonged argument around our choice of dev fee(s). I would like to say this though to try to paint a better picture: I don't think people understand the difference between our work and that of other miner devs working in OpenCL.

In the ongoing fpga group buy, the established consensus around the dev fee is 4%. No one complaining. Fpga bitstream work is even more tedious, but with the workflow we use it's very much a valid comparison. I can easily spend a whole day looking at a section of raw asm code trying to optimize away a single four-cycle instruction in an inner loop, many times not even knowing if it's worth it or not before I actually succeed doing so. We design and implement the kernels bottom up with as high mechanical sympathy for the hardware as possible, not in high-level code hoping the compiler will do that job well enough for us. A bigger algo can easily take month(s) before we deem it ready for release.

Not all algos will have a big upside with this approach. Many times the compilers do a fantastic job of producing good code. Those algos won't be implemented in this miner, there's no point. For the ones we do spend time on, we are expecting to see a considerable boost that clearly justifies the dev fee from the miner's bottom line perspective. Hence, you should still earn more with our miner after the dev fee, with higher hashrate, lower power draw, or both. If you don't, then I personally don't think you should use this miner.

With the higher dev fee, I also think you can expect and demand a higher level of support service. We're two devs and we're trying as hard as we can to be on the ball for all issues in our ANN threads. God knows how many PMs I've sent the last 2-3 days.

In the end, I respect everyone's free choice in this regard. If you feel that no, I have an issue with giving away 2.5-3% of my hashrate to closed source software devs, even though I might earn less in the end, no one can say you're wrong to do so, it's your choice. However, that respect has to be a two-way street.

Hence, arguing us to slash our petty income from this with -50% because it's "important to the community" isn't really a valid argument imho. If you think about it we're talking about +1.54% for you, -50% for us. In my opinion, the truly most important part for the community is to have the same quality of miners that the big private farms do, and you won't be getting that unless there is enough upside to go public. Even then, it's barely worth it, especially when taking the risk of hacked miners and ripped kernels into account. I can assure you, we're not getting rich from this. I would be way better off chasing down high-end IT consultant gigs instead. I choose to do it instead of more lucrative work because it's fun. The Claymore eth days are long gone.

Thanks, glad you took the time to take it for a spin!

Tested phi2 on a 5xR9 NANO rig. good job.