[ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More

[0xcosmos]

I ran into the same problem - but I also confirmed (using amdmemtweak --current) that the settings weren't actually being applied.  I could only get it to work a single time after each machine power-cycle.  Tried the gui version (including the original and xl versions) and had the same issue.

Then i finally figured out there was some conflict while also running HWInfo64.  So maybe try a full power cycle, make sure you don't run any hardware monitoring apps (hwinfo, gpu-z, etc) and try the cli again - and use the '--current' option after to make sure your settings actually get applied as expected.

oh this is it
i oc using overdriventool and hwinfo to monitor the temps of the gpu
i tried applying after a restart and it didn't prompt anything that it was applied successfully but it displayed the changes with the current parameter
thanks

[0xcosmos]

yes - you can also use the gui. Sometimes ref doesn't make a huge difference too. What type of memory do you have? Post your cli line for reference also.

sapphire rx 570 4gb pulse and sapphire rx 580 8gb pulse both have hynix memory
cli command
winamdtweak.exe --i 1,2 --REF 30

[NCarter84]

yes - you can also use the gui. Sometimes ref doesn't make a huge difference too. What type of memory do you have? Post your cli line for reference also.

sapphire rx 570 4gb pulse and sapphire rx 580 8gb pulse both have hynix memory
cli command
winamdtweak.exe --i 1,2 --REF 30

Okay.

So I do, in my batch file each gpu..
 
WinAMDTweak.exe --gpu 0 --ref 30
TIMEOUT /T 1
WinAMDTweak.exe --gpu 1 --ref 30
TIMEOUT /T 1
WinAMDTweak.exe --gpu 2 --ref 30
TIMEOUT /T 1
WinAMDTweak.exe --gpu 3 --ref 30
TIMEOUT /T 1
WinAMDTweak.exe --gpu 4 --ref 30
TIMEOUT /T 1
WinAMDTweak.exe --gpu 5 --ref 30

[Apprentice]

is/will the miner updated to November 30 XMR update?

[kerney666]

is/will the miner updated to November 30 XMR update?

Hi!

We currently do not plan to support RandomX for GPUs, or turn TRM into a CPU miner with RandomX support. We continue our work on GPU-centric algos and aim to provide the best possible implementations for AMD for the algos we support. For RandomX, GPUs will be profitable for a very short time around the fork, it simply isn't worth the huge investment in time.

[ivomm]

Hi! Could you give me an example of tuning AMD 570 for Turtle coin? More specifically, which is the most power efficient core clock/voltage? I've read the documentation and it said for the core 1050 mhz, but how low can the voltage go - 800V or even less? Currently I am 1150/850 but the power consumption is 20% more than CN-r.

[lebuawu2]

Hi,

can someone share hashrate and power consumption comparison for Polaris card (RX 580 8GB) between TRM, PM, Claymore with the same setting (Core Clock, Mem Clock, Other Tweak) ?

Thanks.

[kerney666]

Hi! Could you give me an example of tuning AMD 570 for Turtle coin? More specifically, which is the most power efficient core clock/voltage? I've read the documentation and it said for the core 1050 mhz, but how low can the voltage go - 800V or even less? Currently I am 1150/850 but the power consumption is 20% more than CN-r.

Chukwa and CN/r are completely different algos, there's just no point expecting a power consumption X because CN/r draws Y.

For your question, you just have to test your way to a stable setup, impossible to say where your 570 will croak . If you have a power target you don't want to exceed you'll have to clock down the mem clk to throttle the algo, otherwise just continue to dial down the core clk and voltage and see where you end up.

[kerney666]

Hi,

can someone share hashrate and power consumption comparison for Polaris card (RX 580 8GB) between TRM, PM, Claymore with the same setting (Core Clock, Mem Clock, Other Tweak) ?

Thanks.

We will shortly release a Ethash miner testing tool, it's just a simple open source node.js project. You will be able to run controlled long-running tests on all miners. The reason this is important is that the displayed hashrates of Claymore and Phoenix are just bullshit. They both add +1.5% or more of fake hashrate. I don't ask anyone to buy these claims without being able to verify it themselves though, which is why we'll release the tool (which acts as a low diff fake pool with a static epoch and controlled job update mechanism) and everyone can see for themselves if they are willing to mine air for ~24h. To verify that we're not insane, we've also reverse engineered both miners, analysed their kernels, traced their OpenCL enqueue calls, and the evidence is clear.

Plenty of people have already pointed this out just by logging all shares over time, but it's really hard to prove anything. You need controlled runs of (preferably) 1 million shares, which is more or less impossible without controlling the environment properly. Another simple way is just to find a big farm from e.g. the frontpage of ethermine.org (found blocks) and check the difference between their reported and accepted hashrate.

Here is one example: https://ethermine.org/miners/6F714AaAAF72977267601cC1cADC49fb3966Ff89/dashboard

Reported: 3.206 TH/s, Accepted: 3.111 TH/s, difference -2.97%. I'm fairly certain this is Phoenix miner. Why do we have a diff of -3%? The dev fee is 0.65%, and there are 1% stale shares, and this is a HUGE sample set that should converge nicely. Contrary to what people seem to believe, the additional -1.35% just should _not_ disappear. For comparison, here is a run using our soon-to-be-released testing tool for 247k shares on Phoenix 4.7c:

Code:

Hashrates for 1 active connections:
    Global hashrate: 228.51 MH/s vs 235.43 MH/s avg reported [diff -2.94%] (A247366:S1575:R0 shares, 93582 secs)
    Global stats: 99.37% acc, 0.63% stale, 0% rej.
    [1] hashrate:  228.51 MH/s vs 235.43 MH/s avg reported [diff -2.94%] (A247366:S1575:R0 shares, 93582 secs)

Look at that, a diff of -2.94% between the reported and accepted hashrate, what a coincidence? To be fair though, 247k shares is only good for a +-0.5% estimate at 99% confidence, so we must treat the value accordingly. The point is that neither CM nor PM can never ever produce a poolside hashrate over time that matches their displayed hashrates.

Sorry for a long rant to your simple question, the bigger point I'm trying to make is this: unless miners start accepting that CM and PM are bullshitting their displayed hashrates, "comparing" CM/PM/TRM/Ethminer is pointless, you'll just be stating that CM and PM are much better than what they really are.

[sech1]

To verify that we're not insane, we've also reverse engineered both miners, analysed their kernels, traced their OpenCL enqueue calls, and the evidence is clear.

Wow, this deserves a separate article (Medium maybe?). Indeed, if you trace all OpenCL calls and save timestamps with microsecond precision, it's easy to calculate the real hashrate miner-side, without having to wait for 1000000 shares.

[kerney666]

To verify that we're not insane, we've also reverse engineered both miners, analysed their kernels, traced their OpenCL enqueue calls, and the evidence is clear.

Wow, this deserves a separate article (Medium maybe?). Indeed, if you trace all OpenCL calls and save timestamps with microsecond precision, it's easy to calculate the real hashrate miner-side, without having to wait for 1000000 shares.

I've debated this. Regardless of what I think of the whole setup, I think it's even worse to hack a miner publicly and leave the kernels wide open etc. It's a matter of principle. You also leave the door open for arguments like "yes, but I have my super defense that notices your pathetic workarounds, so I give you my shit kernel instead". Bogus arguments, I've dumped the running kernels in 100% clean environments directly from mapped vram to verify miners were running the same kernels at later points in time, but these arguments are still very hard to prove wrong.

Therefore, I think it's better to provide a testing tool instead that anyone can run on a cloud vm (or on your local LAN with a few IP redirects), acting as a fake pool with low diff, but not low enough to affect miner operation. The miner will then run in a completely clean environment, zero tampering involved, and it's impossible for it to understand it's mining against a fake pool. Moreover, the testing tool is useful for other purposes as well, like generating bad shares much more quickly when tuning and testing OC.

Anyway, this way it will take around 2 days to get 1,000,000 shares, sure, but I think it's worth it. You can prove that you'll have a bound of +-0.3% at a 99% confidence level with that magnitude of shares, which is good enough for our purposes. It should also be sufficient with enough people verifying the results, I don't believe the whole wide world needs to test it themselves.

We will start by posting a github project, then we'll see what happens.

[GKumaran]

Running tests on ETH Vega 64 reference cards on windows 10 using 18.6.1 drivers

Actual effective core speed of 930mhz is the best speed for ETH on my cards.
By this i mean the speed u see in HWinfo or in the stats report when u press 'S' in TRM.
Anything above this is just adding temp/power with no HR improvements and anything below this reduces the HR.


Setting :
TRM Eth Config -> A1024
Timing -> --RAS 32 --RCDRD 12 --RCDWR 10 --RC 44 --RP 12 --RRDS 3 --RRDL 3 --FAW 12 --REF 15600 --RFC 248
ODT speeds : 930(P6 locked)/1028(p3 unlocked)/835mV  @ 1028 SOC

HWinfo speeds : 935/1028/812mV
TRM speeds : 935/1028/835mV

Results :
47.76mh/s per card

On 6 cards :
1275 core -> 286.0 mh @ 1278 watts -> 0.2238 mh/w
 930 core -> 286.0 mh @ 1166 watts -> 0.2453 mh/w  
Note : these watts are at the wall with 5 120mm fans blasting the cards, actual efficiency(hash/watt) is better than this.

Note:

• U can get the same Hash/watt results with 1100 mem clock and go over 50mh/s
• I dont use 1100 mem clock, cause HBM temp arent controllable!! My ambients are high
• I dont blow the tREF over 15600, cause i wany my card to stay alive long  

[kerney666]

We will shortly release a Ethash miner testing tool, it's just a simple open source node.js project. You will be able to run controlled long-running tests on all miners. The reason this is important is that the displayed hashrates of Claymore and Phoenix are just bullshit. They both add +1.5% or more of fake hashrate.

Plenty of people have already pointed this out just by logging all shares over time, but it's really hard to prove anything.

Code:

Hashrates for 1 active connections:
    Global hashrate: 228.51 MH/s vs 235.43 MH/s avg reported [diff -2.94%] (A247366:S1575:R0 shares, 93582 secs)
    Global stats: 99.37% acc, 0.63% stale, 0% rej.
    [1] hashrate:  228.51 MH/s vs 235.43 MH/s avg reported [diff -2.94%] (A247366:S1575:R0 shares, 93582 secs)

Look at that, a diff of -2.94% between the reported and accepted hashrate, what a coincidence?

Isn't that statistically the same amount as the fee?  A likely coding error, a simple oversight at best or
willful incompetence at worst.

Miners typically calculate hash rate by counting hash iterations over time. it's a fair way to measure
the miner's performance but there's no direct connection to share submission. You're trying to prove
your point statistically when there is a precise way to do it if you can find the hash loop code in the kernel.

Man, I apologize, but there's just no beating around the bush here, this is maybe the most inaccurate statement I've ever seen in this forum. You just invalidated the whole world of PoW:

it's a fair way to measure the miner's performance but there's no direct connection to share submission.

The connection is exactly the opposite, they are directly and fully connected, and it's the basis for EVERYTHING related to proof-of-work: when you calculate N hashes for as many nonces, given a specific difficulty we can say _exactly_ how many shares matching that diff we are _expected_ to find. This is the very essence of proof-of-work, and there are no approximations involved. For a smaller N, the variance in the _actual_ outcome will be high, sometimes we find zero shares, sometimes we find more than expected. As N grows larger and larger, the relative error between the nr shares we are _expected_ to find and the nr of shares we _do_ find become smaller and smaller. With proven theorems, we can show that after e.g. 1 million shares, we can estimate N from the nr of shares found and the difficulty to within +-0.33% at a 99% confidence level.

So, I'm not _trying_ to prove my point statistically, I am indeed proving it. And yes, as mentioned above I've also reverse engineered both miners to verify the claims. The reason I am proving it statistically instead of doing open surgery in public on closed source miners has already been answered above: it's a matter of principle, I'm not going to hand out closed source intellectual property to the world. If you want to hack miners, do so yourself. The whole point is that the statistical test is just as effective down to a certain bounded interval that we can prove, but you are absolutely correct in that tracking the OpenCL enqueue calls would be more effective and provide the answer with 100% accuracy. However, since we can run tests where the deviation is 5x outside our 99% confidence level accuracy, you can be damn sure things are seriously off without having to hack miners.

Please note that I have not made any claims as to knowing _why_ this is the case. If you're a good-hearted person you are free to believe it's all just a little coding mistake. For some reason all other miners in the world manage to do these calculations correctly (and they are darn trivial), but only the two biggest closed source miners in the world for crypto's largest emission gpu mineable coin happen to have a little bug or two that makes e.g. Nicehash run their miners instead of other alternatives. Right. That's besides the point I'm trying to make though: when comparing miners by looking at their displayed hash rate, if you don't understand that there is a significant amount of BS hashrate involved in certain miners, that comparison is very much invalid.

Anyway, we will soon be releasing this little tester tool and everyone can run it for themselves. There will most probably be a range of "experts" expressing doubts around the statistical test, but what can you do? At the end of the day, you really just have to run this miner (or the open source Ethminer) instead on a large enough farm and the numbers will be visible poolside as well. Unfortunately, you need a farm in the TH/s range to really get a tight enough continuous sample on e.g. Ethermine, which is why I linked you to an example wallet above.

As a final little example, this is how the open source Ethminer converges after 900k shares on the same rig at the same clocks as the Phoenix example above:

Code:

[[20191114 08:23:17.421]] [LOG]    Hashrates for 1 active connections:
[[20191114 08:23:17.421]] [LOG]    Global hashrate: 230.97 MH/s vs 230.99 MH/s avg reported [diff -0.01%] (A908252:S6201:R0 shares, 85023 secs)
[[20191114 08:23:17.421]] [LOG]    Global stats: 99.32% acc, 0.68% stale, 0% rej.
[[20191114 08:23:17.421]] [LOG]    [1] hashrate:  230.97 MH/s vs 230.99 MH/s avg reported [diff -0.01%] (A908252:S6201:R0 shares, 85023 secs)

There just isn't any black magic to this process. Ethminer has no dev fee and no bullshit implementations. If it scans 230.99 MH/s x 85023 secs = 19.639 THashes it will find the expected nr of shares within a very tight range. Same thing with all miners that aren't faking any numbers. It really is that trivial unless you're running the worst PoW algo in history with some seriously skewed entropy, which isn't the case for any of the major algos out there. In this case, Phoenix miner underperformed the open source miner with more than -1% running under the same conditions. When people look at the displayed hash rates though, they will see Phoenix winning with +1.9%. That's how you corner a market of miners with no tools to verify they're making the optimal choice.

[Doucesti]

Hello! Do you update miner for monero fork friday?
Thank you, I've been using your miner for almost a year!

 

[dingdongtobias]

advertizing own work by spit on other dev's work is not the way to win!!!!
understand you late in the eth game so want to make atenttion in dirty way

[kerney666]

advertizing own work by spit on other dev's work is not the way to win!!!!
understand you late in the eth game so want to make atenttion in dirty way

Well, you're always a bit of a troll and probably some alias account for someone else, posting obscene posts removed by moderators in this thread, I know that, but I agree with both you and joblo, this can REALLY look that way. It's all about if I'm correct or not, isn't it?

[dingdongtobias]

no trolling, you have good product no need do this dirty game for get atenttion

[kerney666]

no trolling, you have good product no need do this dirty game for get atenttion

Fair enough, and I get your perspective 100%. Now, just for a second, assume I'm correct and put yourself in my shoes:

• I strongly believe closed source miners should present accurate numbers. We've always educated miners on how to use e.g. xmrig-proxy to test our CN kernels to make sure we are indeed producing the poolside results.
• We have the best ethash kernel as measured by a number of metrics. If you could read GCN assembly, I could e.g. show that we're running X% less valu instructions, chose an original way of structuring and running the kernel to be able to remove other bloat, and more.
• Currently, it doesn't matter how good we are. The results on Polaris cards are so cutthroat that +1.5% is a huge number (for Vegas we often have a distinct advantage if you take the time to tune properly, but not always beating 1.5%). So, everyone comparing Polaris miners will see that we're "worse". Farm admins testing miners for 30 mins comes back and says "no no, not better". Then they test poolside with a single rig for 24h, still just getting random results because it's far far far from enough shares to prove anything. I have no problem acknowledging solid work and being beaten, but this... No.

So, imho it's all about if I'm correct or not, and I will wrap up our tester tool today. It's a very bad timing I've been swamped for two days when this exploded, not my intent.

Last, If I'm NOT correct about all this, and for some reason I'm a complete fool that has misinterpreted everything and I'm the only one able to generate these results, I will most definitely issue the necessary apologies to all parties involved and go eat my underwear, then look like a fool for the rest of my life. Simple as that.

[kerney666]

Edit: your post was so long I didn't absorb it all the first read. I've changed my reply.

What you describe is statiscally accurate to a certain level of precision but not exact because luck always plays a part.
The longer the sample period the less the error but it's always non-zero.

With the tool release I will post links to basic work on the Poisson distribution and proven bounds. Like I wrote, after 1M shares it's a proven fact that 99% of the time, your samples hashrate will be +-0.33% from the true value. We have run our tests over and over again and reproduced the same results, and those runs are independent. If people want to believe that the black swan event keeps repeating itself every single time, I can't stop them, I can just point out that it's very very very improbable.

The pool has no direct knowlege of how many nonces the miner is actually hashing, it calculates hash rate from shares / time.

Indeed, and you are making my point: neither can the user based on the displayed hash rate printed by a closed source miner (this miner included). We can print anything. It needs to be probed, just like a pool does. Hence the release of a "pool" than uses much lower diff and calculates your hash rate in a single huge session.

But those falacies are beside the point as I accept that your test is statistically accurate enough to prove there is a discrepency,
but not necessarilly a problem.

There is indeed a problem if a miner's displayed hash rate - dev fee never will be representative of what it can generate poolside.

Whether it was your intent or not, your post implies willful intent on the part of the miner developper
when, IMO, there is a perfectly reasonable explanation.

I disagree. Errors in the range of 0.2-0.5% are fine, that could be an added DAG rebuild as part of a dev fee switch etc. Not more than that.

Publishing your test is also irresponsible. It looks like you've started a conspiracy theory and are trying to spread it.

Ehmm, are you kidding? Right now, what I _have_ been doing can _indeed be called irresponsible_, i.e. _not_ backing up my words with a scientifically proven way for others to reproduce my results. NOT publishing is the irresponsible action.

You've already done all the hard work with the kernel, you can prove it one way or another. You don't have to reveal
any secrets, just the results. It's either including fee time in the hashrate or the miner sofware is inflating the count.
One is a user misunderstanding, the other is unethical.

I don't think people would just buy the results from some logs I'm presenting? Giving everyone the same chance of reproducing the results is key. It's basic peer review. If what I'm claiming can't easily be reproduced by others, how can the community trust my claims in any way? I CLEARLY have a huge incentive of spreading disinformation here.

I think the responsible thing to do is the extra step and either confirm the conspiracy or kill it, after all you
started it. But It's up to you.

I 100% agree, and that has ALWAYS been the intent. Your issue rather seems to be with the approach taken to prove my claims, which I still strongly argue is the best approach: simple open source software used for a long-running statistical test, with proven bounds on the probability for certain results to happen.

Also, please note that I'm _not_ happy about my quote being taken from a Discord and posted in youtube vids, but that was me being naive. Tonight (CET) or tomorrow at the latest, the ethash miner tester tool will be published open source on my github. For people with a grasp if of the statistics involved, they will buy the results (assuming they match our own results, that is).

I'm going with fee time, prove me wrong.

I've spent 100+ hours on this, easily. Fee time was of course the first thing I checked since it's the obvious explanation. No one is _stealing_ anything. No miner is consuming more of your resources than announced. Claymore is bang on target for 1.0%. Phoenix switch time is also 100% correct. The dev fee switch time will be easily identifiable in the the tester tool's logs since we're pushing through shares every second. The dev fee switch means a blackout window of N secs.

I will not be posting anything else here now before releasing the tool mentioned above, it's such a time and focus hog.

[UnclWish]

kerney666, can you add setting for clocks and voltages via your miner commands? I don't think it's too difficult...