[ANN] TeamRedMiner - Old Thread

[alucard20724]

New release v0.3.4 posted!

This version now includes cryptonight v8 support!
Also better reporting of GPU hashrates and reporting of submitted/accepted/rejected shares.
Please note that we have changed how we report GPU hashrates.  Hashrates reported by the miner are now the full GPU hashrates.  Previously hashrates reported were after dev fee deduction.

Since we expect a lot of questions and comments about cryptonight v8, we have created a new thread for it here.
Please post any cryptonight v8 related comments and questions in that thread.

are there parameters to be added to phi2?  cause it would appear that 0.3.4 has killed the hashrate for phi2

That is surprising really, we haven't touched those kernels at all, should be exactly the same. On my Windows box, running the v0.3.2 vs 0.3.4 for a few mins with a 580+560+Vega 64, I get the following:

v0.3.2

[2018-10-30 13:10:12] Stats GPU 0 - phi2: 4.919Mh/s (4.320Mh/s)
[2018-10-30 13:10:12] Stats GPU 1 - phi2: 2.034Mh/s (1.834Mh/s)
[2018-10-30 13:10:12] Stats GPU 2 - phi2: 9.880Mh/s (8.948Mh/s)
[2018-10-30 13:10:12] Stats Total - phi2: 16.832Mh/s (15.103Mh/s)


vs

v0.3.4

[2018-10-30 13:05:52] Stats GPU 0 - phi2: 5.076Mh/s, avg 5.073Mh/s, pool 5.089Mh/s 27/0
[2018-10-30 13:05:52] Stats GPU 1 - phi2: 2.087Mh/s, avg 2.114Mh/s, pool 1.926Mh/s 8/0
[2018-10-30 13:05:52] Stats GPU 2 - phi2: 10.18Mh/s, avg 10.18Mh/s, pool 12.08Mh/s 55/0
[2018-10-30 13:05:52] Stats Total - phi2: 17.34Mh/s, avg 17.36Mh/s, pool 19.10Mh/s


In v0.3.2 we displayed the net user hashrate (3% dev fee subtracted), this has changed in 0.3.4, we now display the raw hashrate. Adjusting for that change: 17.36 * 0.97 = 16.84, close enough to 16.832. So, I don't see a regression bug on my Windows box at least.

Can you give a quick description of your setup (os/driver/gpus) and what you're seeing?

Cheers, K

i think the problem was on my end... i lost network connectivity while benchmarking systems because one system locked up the network.  I'll worry about it on the next release.

[1715480333]

1715480333

[1715480333]

1715480333

[1715480333]

1715480333

[todxx]

New release versions 0.3.5 posted!

The most relevant change in this release for lyra2z and phi2 is that the GPU initialization has been changed to be sequential by default.  This is to prevent problems that occur on some slower CPUs (such as celerons).
To make the miner perform a faster parallel init like in v0.3.4, use the option --init_style=3.

You can read the full changes in the main post, but the rest are mostly bug fixes for CNv8 related issues.

[peteris-apse]

good to know. wont bother updating minig soft for phi2. but on vega rig and cnv8 teamredminer kicks strong! power drain went down for liek few % and hashrate seems much higher - 12800 before 13800 now. Bet lets see ho stable this new miner is!

[kerney666]

good to know. wont bother updating minig soft for phi2. but on vega rig and cnv8 teamredminer kicks strong! power drain went down for liek few % and hashrate seems much higher - 12800 before 13800 now. Bet lets see ho stable this new miner is!

Hi!

For the sake of transparency: there is no increased hashrate for phi2 between the versions. The higher hashrate is because we are now presenting the raw hashrate _before_ dev fee, previously we thought we'd be helpful and show the net user hashrate after dev fee was excluded.

However, we grew tired of seeing our displayed numbers being compared to other miners with another 3% removed, so we changed it into the more standard way with the CNv8 release.

[du44]

Hello dear developers! I've installed this miner and it works perfectly stable, provides good hashrate. But dev fee is bearish... Please reduce it to 1-1.5% for cn8 and 1.5-2% for other algos. You will see - a lot of people will begun to use your miner, it's very important for community

[GreyGhost_rc]

Hello dear developers! I've installed this miner and it works perfectly stable, provides good hashrate. But dev fee is bearish... Please reduce it to 1-1.5% for cn8 and 1.5-2% for other algos. You will see - a lot of people will begun to use your miner, it's very important for community

You sure you don't want it for free? The dev fee is vindicated. Be glad they are putting in all the effort. Joh...

[sp_]

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

Code:

[2018-11-01 16:35:36] Pool lux.pickaxe.pro share accepted. (GPU2) (126/123/3)
[2018-11-01 16:35:39] Pool lux.pickaxe.pro share accepted. (GPU1) (127/124/3)
[2018-11-01 16:35:52] Pool lux.pickaxe.pro share accepted. (GPU2) (128/125/3)
[2018-11-01 16:35:53] Pool lux.pickaxe.pro share accepted. (GPU2) (129/126/3)
[2018-11-01 16:35:57] Pool lux.pickaxe.pro share accepted. (GPU0) (130/127/3)
[2018-11-01 16:36:00] Pool lux.pickaxe.pro share accepted. (GPU0) (131/128/3)
[2018-11-01 16:36:04] Pool lux.pickaxe.pro received new job. (job_id: dcd)
[2018-11-01 16:36:05] Pool lux.pickaxe.pro share accepted. (GPU0) (132/129/3)
[2018-11-01 16:36:06] Stats GPU 0 - phi2: 5.241Mh/s, avg 5.245Mh/s, pool 7.020Mh/s 27/1
[2018-11-01 16:36:06] Stats GPU 1 - phi2: 5.289Mh/s, avg 5.311Mh/s, pool 5.841Mh/s 26/0
[2018-11-01 16:36:06] Stats GPU 2 - phi2: 5.212Mh/s, avg 5.253Mh/s, pool 7.929Mh/s 27/0
[2018-11-01 16:36:06] Stats GPU 3 - phi2: 5.295Mh/s, avg 5.333Mh/s, pool 6.428Mh/s 26/1
[2018-11-01 16:36:06] Stats GPU 4 - phi2: 5.391Mh/s, avg 5.394Mh/s, pool 4.768Mh/s 23/1
[2018-11-01 16:36:06] Stats Total - phi2: 26.43Mh/s, avg 26.54Mh/s, pool 31.98Mh

[kerney666]

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

Code:

[2018-11-01 16:35:36] Pool lux.pickaxe.pro share accepted. (GPU2) (126/123/3)
[2018-11-01 16:35:39] Pool lux.pickaxe.pro share accepted. (GPU1) (127/124/3)
[2018-11-01 16:35:52] Pool lux.pickaxe.pro share accepted. (GPU2) (128/125/3)
[2018-11-01 16:35:53] Pool lux.pickaxe.pro share accepted. (GPU2) (129/126/3)
[2018-11-01 16:35:57] Pool lux.pickaxe.pro share accepted. (GPU0) (130/127/3)
[2018-11-01 16:36:00] Pool lux.pickaxe.pro share accepted. (GPU0) (131/128/3)
[2018-11-01 16:36:04] Pool lux.pickaxe.pro received new job. (job_id: dcd)
[2018-11-01 16:36:05] Pool lux.pickaxe.pro share accepted. (GPU0) (132/129/3)
[2018-11-01 16:36:06] Stats GPU 0 - phi2: 5.241Mh/s, avg 5.245Mh/s, pool 7.020Mh/s 27/1
[2018-11-01 16:36:06] Stats GPU 1 - phi2: 5.289Mh/s, avg 5.311Mh/s, pool 5.841Mh/s 26/0
[2018-11-01 16:36:06] Stats GPU 2 - phi2: 5.212Mh/s, avg 5.253Mh/s, pool 7.929Mh/s 27/0
[2018-11-01 16:36:06] Stats GPU 3 - phi2: 5.295Mh/s, avg 5.333Mh/s, pool 6.428Mh/s 26/1
[2018-11-01 16:36:06] Stats GPU 4 - phi2: 5.391Mh/s, avg 5.394Mh/s, pool 4.768Mh/s 23/1
[2018-11-01 16:36:06] Stats Total - phi2: 26.43Mh/s, avg 26.54Mh/s, pool 31.98Mh

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

[kerney666]

Hello dear developers! I've installed this miner and it works perfectly stable, provides good hashrate. But dev fee is bearish... Please reduce it to 1-1.5% for cn8 and 1.5-2% for other algos. You will see - a lot of people will begun to use your miner, it's very important for community

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.

[sp_]

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

[kerney666]

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

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.

 

[melloyellow]

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

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.

 

I would love it if you could support Hawaii cards.

[kerney666]

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

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.

 

I would love it if you could support Hawaii cards.

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

[du44]

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?

[kerney666]

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?

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 .

[trexsupport]

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.

[alucard20724]

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.

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

[kerney666]

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.

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.

[420sam]

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

[kerney666]

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

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.