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

[kerney666]

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

You shouldn't have posted here in the first place, You never once mentioned the subject of this thread so it was
all off topic. It's also out of line to hijack a thread to advertise your own software.

It's become clear you're just trying to spread FUD and picked on closed source miners because
they are an easy target. I'm no fan of closed source and a proper objective audit of their performance
would be a good thing. But that's not what you're doing.

OMG, you just won most ignorant post of the day award once again, congrats!

Do you do any research what so ever? You are posting in the thread for TeamRedMiner. I'm one of the two devs behind TeamRedMiner. This IS my thread. It's about the closed source miner I'm one of the devs for. Get it?

The topic we're discussing is EXACTLY on-topic since we're also an ethash miner now. My first post on this topic was in direct response to the following:

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.

In short, my response was "such tests are useless since I claim said miners are boosting their displayed hashrate. I will shortly release testing software for the community to verify these claims for themselves.". How can that not be a very logical way of initiating this discussion? Did you even read back to the start of the thread?

Since you clearly don't know who I am, allow me to introduce myself. I'm one of the best AMD GCN devs in the mining scene, and have been for the last two years. Ask anyone who actually knows something about the topic. I've been writing GCN asm kernels from scratch 100 times more complex than a simple ethash kernel. We have probed the memory controller on Polaris and Vegas for our CN work until there's nothing left to know. For many of our algos, there is no other miner even close to our performance. For the bulk of the remaining, we're just the best (although shout-out to Lollie who might have snatched a c31 spot now, not sure). When I say that something is off on an AMD gpu, I usually know wtf I'm talking about, and I'm putting my good name and reputation behind it.

My intentions have been very clear, and I've repeated myself multiple times now. Let me repeat it for you one more time. This is the roadmap:

• Release Ethash miner tester tool incl documentation.
• Let the community test for themselves.

This IS THE WAY you do black box testing on closed source miners. I have been educating our CN user base on how to use xmrig-proxy and to what extent they must push the share count in their tests to get statistically significant results for ages. Go ahead, go join the Conceal (CCX) discord and check their mining thread and read my post from Oct 5, to take one example, that's where I remember discussing the topic last. Or download our miner and read step 8 in our included HOWTO for tuning Vegas.

[kerney666]

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

Gaaah, it's actually messier than you'd think, especially since we're a cross platform miner. Need to do both the full OverdriveN API on windows, then messing around with sysfs on linux. Not impossible, but it's one of those things you just love to rely on e.g. mining OSs for, handle all linux quirks etc.

If things quiet down somewhat I'll take a more proper look though.

[UnclWish]

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

Gaaah, it's actually messier than you'd think, especially since we're a cross platform miner. Need to do both the full OverdriveN API on windows, then messing around with sysfs on linux. Not impossible, but it's one of those things you just love to rely on e.g. mining OSs for, handle all linux quirks etc.

If things quiet down somewhat I'll take a more proper look though.

I'm Windows user, so linux things difficult for me ))) You can make 1st windows controls, if it more simple. Linux support can be added later.
Just thinking... You're miner good! Very good!
Thanks for your work!
I'm testing eth right now... Looks fast... Will see on accepted speed at pool side...

[keksik]

im using Claymore 15 and mining eth. reported hash is 825.9 and average 6hours is only 727,6mhs.

going to try TRM 0.6.0, curious about results.

[laik2]

OMG, you just won most ignorant post of the day award once again, congrats!

Touche!

Well, I'm pleased to meet you and a little humbled.

You didn't start the thread and I don't know anything about TeamRed, or any other closed source
miner for that matter. But that's no excuse. I apologize.

I still have my original question. How does black box testing identify if a discrepency is due to
boosting the hashrate or has a simple explanation? Doesn't that require looking inside the box?

Difference is that on a blackbox you are in control of the so called "luck", so if you by any chance are trying to cheat you won't get away with an excuse like "It's all based on pool's luck".

[kerney666]

To anyone interested in sorting out our claims around the displayed hash rates by closed source AMD ethash miners

As planned, we have now released our Ethash miner testing tool publicly. Since we have made claims around the validity of certain miners' displayed hashrates, the goal was always to produce an open source miner testing tool that the community can run themselves to verify these claims. That tool has now been released. I am publishing it here and in the TRM discord for the time being. The next step is to gather results from external parties outside of my and todxx's control to verify that our results are indeed reproducible.

The issue for a miner is of course that the tool is not built as a proxy to a real pool, you will be mining air for 18-35h depending on your rig size and miner being tested. That said, if you're interested in helping out with this little issue and have a stable rig to spare for a few days, then read the (long) README for the tool and break a leg. We will be available in the TRM discord to sort out any issues you might have getting things running. All results and contributions are greatly appreciated!

And, Happy Thanksgiving to all you guys in the US!

https://github.com/Kerney666/trm-ethash-miner-tester

[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.

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.

Hi Kerney,

I agree with you, hash rate displayed in the miner is just number, we need to verify in the pool side. I just want to get rough estimation base on hashrate in the miner, because it will be easy rather than wait 24h in pool side.

Thanks.

[lebuawu2]

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?

lol advertizing and pointing the fact (we need to check of course) in his own thread should be ok, dingdongtobias is just die hard SRB which don't like with your miner because someone advertise TRM miner in SRB thread.

[lebuawu2]

im using Claymore 15 and mining eth. reported hash is 825.9 and average 6hours is only 727,6mhs.

going to try TRM 0.6.0, curious about results.

I also feel the same with you, I tried both Claymore and PM both of them showing pool side (ethermine) more lower than in the miner(after deducted fee from miner and pool side).

will wait for your review after you try TRM.

[joblo]

To anyone interested in sorting out our claims around the displayed hash rates by closed source AMD ethash miners

OK  I'm truly impressed.

We both feel passionately about the issue of hashrate accuracy and I had also recently taken
steps to improve transparency.

My initial misunderstanding of who you were closed my mind to the fact you knew exactly what
you were doing all along, and in the end I agree with your approach 100%. You've factored in the
fee, you have control of the pool side, you have a high share rate to reduce variability (as well as
a form of stress test on the miner, nice touch), everything is covered except the math in the miner.

Your tool indeed isolates the problem as I was hoping it would.

I'm sorry for crapping in your thread, I'll be cleaning up my mess now.

[kerney666]

To anyone interested in sorting out our claims around the displayed hash rates by closed source AMD ethash miners

OK  I'm truly impressed.

We both feel passionately about the issue of hashrate accuracy and I had also recently taken
steps to improve transparency.

My initial misunderstanding of who you were closed my mind to the fact you knew exactly what
you were doing all along, and in the end I agree with your approach 100%. You've factored in the
fee, you have control of the pool side, you have a high share rate to reduce variability (as well as
a form of stress test on the miner, nice touch), everything is covered except the math in the miner.

Your tool indeed isolates the problem as I was hoping it would.

I'm sorry for crapping in your thread, I'll be cleaning up my mess now.

Hey man, I'm always happy to reboot a relationship that started off on the wrong foot . At the end of the day, glad to have you here!

And yes, I do feel passionately about this, not just b/c I obviously have a vested interest in this particular case. I've always been pushing to educate miners on this topic, neither miner devs nor miners draw any benefit from the semi-random "I did a 24h test" results, but it quickly gets too complicated for the casual miner .

[UnclWish]

kerney666, Today my rig, connected to nicehash with TRM eth start to recieve connections errors from pool and reconnect again and again but always connection refused by pool. I noticed this only after more than an hour of this errors while I had my way home...
I thought that my connection is dead, or pool on service... But closing miner and restart him solves the problem.
What it was?

[todxx]

kerney666, Today my rig, connected to nicehash with TRM eth start to recieve connections errors from pool and reconnect again and again but always connection refused by pool. I noticed this only after more than an hour of this errors while I had my way home...
I thought that my connection is dead, or pool on service... But closing miner and restart him solves the problem.
What it was?

Hi UnclWish,

We've seen things like this happen in the past when a pool has banned an IP, but that usually only happens if the miner does something like submit a lot of invalid shares.
Do you have a log of when this happened?
I'd be interested to see the part of the log when it stopped mining and started having this problem.

[UnclWish]

kerney666, Today my rig, connected to nicehash with TRM eth start to recieve connections errors from pool and reconnect again and again but always connection refused by pool. I noticed this only after more than an hour of this errors while I had my way home...
I thought that my connection is dead, or pool on service... But closing miner and restart him solves the problem.
What it was?

Hi UnclWish,

We've seen things like this happen in the past when a pool has banned an IP, but that usually only happens if the miner does something like submit a lot of invalid shares.
Do you have a log of when this happened?
I'd be interested to see the part of the log when it stopped mining and started having this problem.

No, I haven't rejected shares. Only several. And I didn't change anything with connection, even didn't restarted it. So my IP stays the same.
How to enable logging? I make log and when problem repeats post it here.

[kerney666]

kerney666, Today my rig, connected to nicehash with TRM eth start to recieve connections errors from pool and reconnect again and again but always connection refused by pool. I noticed this only after more than an hour of this errors while I had my way home...
I thought that my connection is dead, or pool on service... But closing miner and restart him solves the problem.
What it was?

Adding this as well: we have v0.6.1 on the way out, finally adding pool strategies (incl failover), so at least you should be able to failover to e.g. Nicehash US if your EU line goes down etc in the next version. We really waited a while to get that little feature added...  

[todxx]

kerney666, Today my rig, connected to nicehash with TRM eth start to recieve connections errors from pool and reconnect again and again but always connection refused by pool. I noticed this only after more than an hour of this errors while I had my way home...
I thought that my connection is dead, or pool on service... But closing miner and restart him solves the problem.
What it was?

Hi UnclWish,

We've seen things like this happen in the past when a pool has banned an IP, but that usually only happens if the miner does something like submit a lot of invalid shares.
Do you have a log of when this happened?
I'd be interested to see the part of the log when it stopped mining and started having this problem.

No, I haven't rejected shares. Only several. And I didn't change anything with connection, even didn't restarted it. So my IP stays the same.
How to enable logging? I make log and when problem repeats post it here.

You can enable logging by adding the following option to the command line:
--log_file=trm_log.txt

Where trm_log.txt is the name of the log file to write out.

[UnclWish]

kerney666, Today my rig, connected to nicehash with TRM eth start to recieve connections errors from pool and reconnect again and again but always connection refused by pool. I noticed this only after more than an hour of this errors while I had my way home...
I thought that my connection is dead, or pool on service... But closing miner and restart him solves the problem.
What it was?

Hi UnclWish,

We've seen things like this happen in the past when a pool has banned an IP, but that usually only happens if the miner does something like submit a lot of invalid shares.
Do you have a log of when this happened?
I'd be interested to see the part of the log when it stopped mining and started having this problem.

No, I haven't rejected shares. Only several. And I didn't change anything with connection, even didn't restarted it. So my IP stays the same.
How to enable logging? I make log and when problem repeats post it here.

You can enable logging by adding the following option to the command line:
--log_file=trm_log.txt

Where trm_log.txt is the name of the log file to write out.

Yes, I'm find it and enable allready. Now waiting for bug reproduction...

Questions on eth mining:
- if I have 8Gb cards but want to use A varinat of config. What best config would be for A? The same number as for B, or not?
- it's need to add option to force autoconfig only with A config.
- is there some command for setting intensity? For lowering mining intensity on some card.

Thanks for your work! Waiting updates.

[xMindx163]

Hello. It seems that the load on the Grin29 Radeon VII is not optimal enough. the card's power consumption jumps back and forth. Are there plans to fix this in future versions?

[UnclWish]

And it's need to optimize speed... On Phoenix with double kernels my RX 580 gives about 600KH/s (about 2%) more speed. Even if 0,65% dev fee not true, speed on TRM eth too low in compare with PM.

[todxx]

Yes, I'm find it and enable allready. Now waiting for bug reproduction...

Questions on eth mining:
- if I have 8Gb cards but want to use A varinat of config. What best config would be for A? The same number as for B, or not?
- it's need to add option to force autoconfig only with A config.
- is there some command for setting intensity? For lowering mining intensity on some card.

Thanks for your work! Waiting updates.

You can specify configs for the cards like with the cn_config, but it's eth_config instead.  To make all cards run A mode, you can use --eth_config=A
You can set a specific mode and intensity with something like so: --eth_config=A300
You can also provide a list with one entry per card, like so: --eth_config=A300,B400,A,B

And it's need to optimize speed... On Phoenix with double kernels my RX 580 gives about 600KH/s (about 2%) more speed. Even if 0,65% dev fee not true, speed on TRM eth too low in compare with PM.

I'm guessing you haven't read any of the last ~20 posts in this thread.  You might want to go back and look through them a bit.
TL;DR: Phoenix miner reports hashrate ~2.9% higher than it actually gets.  So by your measurement, we're getting about 0.9% better actual hashrate (I.E. your pool hashrate will go up 0.9%).