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

Are you running a monitor on that gpu? Currently that means you'll have to tune down the config manually, but we're about to add code for detecting and adjusting that automatically. The Windows TDR timeout can also still be bitchy at times, I'm about to run more tests on that today and add automatic behavior for that too.

Awesome pal will try this out!

Might be my config, but it looked good for a couple of minutes then the power at wall meter dropped the load - soon to be followed by the dreaded 'dead' red text. Will try it at stock settings again and see later.

Team Red Miner v0.7.2 released

https://github.com/todxx/teamredminer/releases

Changes in v0.7.2

• Fixed kawpow dag build DEAD gpu issue on windows Adrenalin 2020 drivers.
• Fixed Navi 5600(xt) support on windows.
• Fixed mining on Vegas on older amdgpu-pro drivers.
• Fixed ADL reporting of stats on windows for newer cards.

This release is mostly another round of bug clean-up for various driver issues users have been reporting.
We've also added a kawpow tuning guide to help new users tune GPUs on kawpow.

Thanks. Everything's fine.

Save your 1 BTC ... just share the code in that source folder you created in github!
[/quote]

Nobody owes you anything.

Hi primavera8989,

One of the changes that we forgot to mention is that we do not use the B mode for polaris 8GB gpus by default starting in v0.7.0.
To get the miner to use the B mode again you can add the following option: --eth_config=B

Hi! Has anyone tried POLARIS? On RX488, RX478 the hashrate is lower on the new version 0.7.1 by 0.7 from small rig. Please tell me how to fix it.
Win_10
Adrenalin_18.6.1
TRM_0.6.1
https://i.ibb.co/GHsp9K7/061.jpg
TRM_0.7.1
https://i.ibb.co/BLcGG3F/071.jpg

a) I’m not one of the devs - I’ve just been using this software for >1.5 yrs now, and the devs competence and trustworthiness have been more than proven at this point, unlike yourself.

b) if you don’t want to use closed source software- that’s a reasonable position.  So go use something else and keep your BS allegations to yourself until/unless you have some proof.

Tbh, you're a nobody--and the devs that work on this miner are too busy producing software that this community values to have to prove anything about you one way or another.

So go spout your nonsense elsewhere; you're polluting a thread that's useful to me and diluting other member's worthwhile commentary with your bs.

But, thanks for getting to what you're really looking for, free code for nothing, probably to remove the well-earned devfee.

Truth shall set us all free - share your source code to prove I’m full of shit!

Yeah, sounds a little weird tbh. Therefore, I'm happy to make you a public bet for 1 BTC with a known escrow that you're full of shit, care to take me up on it? You provide your magic hacked software that produces 58-62 MH/s on a Polaris card or 95-100 MH/s on a Vega 56/64, hashrate is then verified statistically by a 3rd party for a test with approx 1 million submitted shares to get the bounds on the Poisson distribution within reasonable bounds, then the escrow pays out? Would love to make an easy 1 BTC.
[/quote]

Save your 1 BTC ... just share the code in that source folder you created in github!

I had better idea to prove my findings .... tested the hacked releases of 2 VERY popular ETH mining softwares and noticed my hash rates went up almost double compare with using the original ones!

Shocking, eh!!
[/quote]

Why are you even here - whats your goal?  You’re constantly spreading completely baseless BS, and clearly have no clue on how to tune GPUs/miners.

Go away troll.

Yeah, it was interesting to observe all the early attempts of maxing out Navis using 128 for workgroup size which just caused a ton of invalid hashes proportionally to the hashrate increase. Hashes got merged and simply accessed the same memory locations, hence the increased hashrate due to better cache utilization, at least that's my take on it. It was never real to begin with, and you'd have thought the developers of the miners used could have been more clear about what was going on...

FAKE HASHRATE--

It is possible with several ETH mining softwares to produce a console-reported hashrate that is an artifact, an unreal number.  It merely takes a faulty configuration string for the miner to produce this untrue hashrate number.

I have 2 brand new Navi 5700 XT cards, and several older Vegas.  I had my Vegas and Navis (both un-modded) reporting 58+ MH/s for ETH.

However, the effective hashrate at the pool was perhaps 2/3 of the console-reported hashrate, or less.  The miners were producing high numbers of incorrect shares.  A carefully edited screencap would show an amazing, but untrue, hashrate report.

I have, however, tuned my Navi cards to about 0.58+MH/Watt for ETH, and I am still tweaking.  Very few rejects, approximately 53MH/s per card, and stable for days.  No BIOS mods and no hacks, just tuning.       --scryptr

I had better idea to prove my findings .... tested the hacked releases of 2 VERY popular ETH mining softwares and noticed my hash rates went up almost double compare with using the original ones!

Shocking, eh!!
[/quote]

Yeah, sounds a little weird tbh. Therefore, I'm happy to make you a public bet for 1 BTC with a known escrow that you're full of shit, care to take me up on it? You provide your magic hacked software that produces 58-62 MH/s on a Polaris card or 95-100 MH/s on a Vega 56/64, hashrate is then verified statistically by a 3rd party for a test with approx 1 million submitted shares to get the bounds on the Poisson distribution within reasonable bounds, then the escrow pays out? Would love to make an easy 1 BTC.

For miners that don't fully trust the displayed hashrate or that the communicated dev fee is correct, I would argue that the best way to verify poolside/dev fee hashrate is with fake pool hacks, much like the one we built ourselves for ethash, available on my github. It sets a low diff, the miner you want to test submits many many more shares compared to a normal pool, and after maybe 12h you have a very accurate picture of the "poolside" hashrate of the miner you're testing because you'll have submitted 500,000 shares by then and get a much much more accurate data point than looking at a 6h or 24h average on some pool for 1000 submitted shares (which really means nothing tbh).

[/quote]

I had better idea to prove my findings .... tested the hacked releases of 2 VERY popular ETH mining softwares and noticed my hash rates went up almost double compare with using the original ones!

Shocking, eh!!

They can’t - it’s machine-generated writing compiler!  

https://www.theregister.co.uk/2020/05/20/trend_accused_microsoft_cheating/

https://www.theregister.co.uk/2015/09/19/volkswagen_pollution_cheat_claims_epa/

Don’t expect much from developers - copying from open-sourced and then close-sourced theirs - making hundreds err ... millions of dollars worldwide from us -> miners who have blindly trusted them for years!

Hi!

Well it's not that simple, there's just no point really. We don't run mining the same way as the traditional switching miners do, we always mine user and dev in parallel, all the time, for all algos and situations where it's possible which is almost all. 99 hashes to the user, 1 hash to the dev, 99 hashes to the user, 1 to the dev, and so on. The user pool is always connected, the dev pool is always connected. We can print "User and dev fee now mining" at the start and that would be it .

We built it this way for a much smoother user experience: continuous hashrate for the user with no drops in pool avg, much lower risk for pools being angry that you stop submitting shares for a while, the pool diff stays constant and doesn't fluctuate with dev fee sessions, absolutely the same continuous gpu load all the time with no short interruptions when switching, etc. Now, if you'd be evil you could argue we built it this way to hide our super massive dev fee hashrate that really is 500% more than we're saying, but yeah, simply not the case...

There are a few notable exceptions though, MTP is one of them. We still try to switch different gpus at different times to keep things smooth for the user and it would honestly just (1) litter the logs with and (2) invite even more hackers that try to pick things apart by logging dev fee start/stop. Moreover, I can count the nr of users we have for MTP on one hand and none of them has complained .

For miners that don't fully trust the displayed hashrate or that the communicated dev fee is correct, I would argue that the best way to verify poolside/dev fee hashrate is with fake pool hacks, much like the one we built ourselves for ethash, available on my github. It sets a low diff, the miner you want to test submits many many more shares compared to a normal pool, and after maybe 12h you have a very accurate picture of the "poolside" hashrate of the miner you're testing because you'll have submitted 500,000 shares by then and get a much much more accurate data point than looking at a 6h or 24h average on some pool for 1000 submitted shares (which really means nothing tbh).

Hi, kerney666!
No questions about fees. But can you add in your miner info about devfee mining when it goes? At least start mining devfee and stop.

Yawn, you have nowhere else to FUD at the moment? My statement was the "first and only public AMD miner so far that can _compete with Team Green_", not the first working miner.

The 2% fee is the same as all other AMD miners for the same algo, of course with the exception of the open source reference miner. For this algo, we wrote our own machine-code generating compiler from scratch for the random math in progpow, we don't rely on any OpenCL compiler like everyone else. All code is written from scratch, not a single line "borrowed" from any reference implementation. That goes for both host- and gpu-side. We then chased every single f-ing cycle we could find in the algo. The results speak for themselves. We then set the same dev fee to the same level as everyone else despite probably spending 5x more time.

Regarding fake or hidden super hashrates, we have never lied about anything, there are other miners for that which we have shown already. There always seem to be a number of random posters with some hidden agenda appearing in our threads though claiming the same FUD bullshit about hidden fees. I wonder why.

All in all, you should run the miner you feel comfortable running. I truly understand that many people have issues with closed source software. That said, it's not very difficult to isolate your mining rigs from any sensitive data or network access to mitigate any worry about rogue "features". What you should stop doing is posting in every closed source miner thread saying they should give away what took them 100s of hours to produce at the price of your liking rather than what they decide justifies their effort. If you don't like closed source, don't use it. The dev fee is not your call to make, and I don't think you've ever ran any numbers to justify your whining about expensive fees, you're just an egocentric dude that think you're entitled to everything for free, otherwise you wouldn't be here posting in the first place.