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

[kerney666]

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.

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

[1715337835]

1715337835

[1715337835]

1715337835

[1715337835]

1715337835

[iDisturbia]

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.

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!

[iDisturbia]

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

[kerney666]

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

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.

[scryptr]

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

[kerney666]

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

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

[pbfarmer]

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

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.

[iDisturbia]

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

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

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!

[iDisturbia]

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.

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

[N2DCRYPT]

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.

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

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.

[pbfarmer]

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.

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

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.

[primavera8989]

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

[todxx]

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

TRM_0.7.1

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

[Iamtutut]

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

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

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.

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

Nobody owes you anything.

[primavera8989]

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

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

Thanks. Everything's fine.

[todxx]

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.

[ZombieWorm]

Team Red Miner v0.7.2 released
Changes in v0.7.2

• Fixed kawpow dag build DEAD gpu issue on windows Adrenalin 2020 drivers.

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.

[kerney666]

Team Red Miner v0.7.2 released
Changes in v0.7.2

• Fixed kawpow dag build DEAD gpu issue on windows Adrenalin 2020 drivers.

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.

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.

[ALEX_RAA]

Hi all

Is it mean that ETC on 4gb cards is over?
https://ibb.co/CPGR0qj

rig (4x570 4gb)
internal graphic card is used (no monitor emulation)
4gb RAM
pagefile 50gb
win10

p.s. if i start to ETH - it's generating dag file correctly

[kerney666]

Team Red Miner v0.7.3 released

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

Changes in v0.7.3

• Emergency patch for 4GB cards to handle a few more ETC epochs. A more complete patch is coming out shortly.

We will take the time to squeeze out as many epochs possible in an upcoming release. We'll also provide the specific epoch we expect the miner to work with for that release.

Note: I can't update the topic for now, todxx will take care of it as soon as he comes online.