Topic: [ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More - page 55. (Read 211762 times)

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?

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

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

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.

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.

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?

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 .

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.

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.

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.

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.

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

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

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

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.

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:


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, can you add setting for clocks and voltages via your miner commands? I don't think it's too difficult...

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.


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.


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


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.


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.


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