⛏Team Black Miner (ETHB3 ETHW ETC VTC KAWPOW FIROPOW ZIL +dual +tripple mining )

[Ramsete2]

2nd day of fight: TBMiner vs GMiner

TBMiner (ver 1.19)


GMiner (ver 2.70)


To be honest I expected more distance between the two miners, but they are very close indeed.
Still confused about results.

[1714031769]

1714031769

[1714031769]

1714031769

[sp_]

2nd day of fight: TBMiner vs GMiner

Third day. You had a v1.18 vs 2.70 earlier.

1. You are running on a mining pool that doesn't pay for stale shares. Change the pool and increase the intensity
2. You are running on sub optimal clocks. I know this is a power issue, and that pushing it to 106MHASH is not worth the power, but still..



v1.20
1. Removed unwanted debug output for AMD/OpenCL. (Linux)
2. Removed cost from console status if watt reading is null.
3. Added mutex lock to average solution time to avoid thread race condition.
4. Avoid gpu timouts at startup on rigs with more than 12 cards
5. Improved staleshare checker less stales reported.
6. increased default nvidia --xintensity to 225 to improve the poolsite hashrate.
7. Added --dagintensity 0-9 for nvidia cards to prevent crash on high oc RTX cards.
8. Fixed reported hashrate on some pools with high case workernames.
9. Added following pools: 666pool.cn, gpumine.org and rustpool.xyz.

https://github.com/sp-hash/TeamBlackMiner/releases/

TeamBlackMiner_1_20_cuda_11_5.7z
https://www.virustotal.com/gui/file/41d5cd1b48cdde280f3d3f1b236d9c1c892f67742772e75bd32420ce7ac9b6bd?nocache=1

TeamBlackMiner_1_20_cuda_11_4.7z
https://www.virustotal.com/gui/file/9a26df7e3f60ceaca3b44d4216d067c9e30295b0490068cfa3cb81cdd1e90919?nocache=1

TeamBlackMiner_1_20_cuda_11_2.7z
https://www.virustotal.com/gui/file/7a99d5404890abbb80e9965b7e76a913abdaf13abf9685604c511a25c61766fd?nocache=1

TeamBlackMiner_1_20_Ubuntu_18_04_Cuda_11_4.tar.gz
https://www.virustotal.com/gui/file/af0374531ff5807315c7b10fc241a26b84c581640fb5c7075173911e9a479e0f?nocache=1

v1.20, 150 shares test on crazypool with default --xintensity 224. no stales. Good poolside hashrate.






[moderator's note: consecutive posts merged]

[abanamat]

v1.20
1. Removed unwanted debug output for AMD/OpenCL. (Linux)
2. Removed cost from console status if watt reading is null.
3. Added mutex lock to average solution time to avoid thread race condition.
4. Avoid gpu timouts at startup on rigs with more than 12 cards
5. Improved staleshare checker less stales reported.
6. increased default nvidia --xintensity to 225 to improve the poolsite hashrate.
7. Added --dagintensity 0-9 for nvidia cards to prevent crash on high oc RTX cards.
8. Fixed reported hashrate on some pools with high case workernames.
9. Added following pools: 666pool.cn, gpumine.org and rustpool.xyz.

https://github.com/sp-hash/TeamBlackMiner/releases/

TeamBlackMiner_1_20_cuda_11_5.7z
https://www.virustotal.com/gui/file/41d5cd1b48cdde280f3d3f1b236d9c1c892f67742772e75bd32420ce7ac9b6bd?nocache=1

TeamBlackMiner_1_20_cuda_11_4.7z
https://www.virustotal.com/gui/file/9a26df7e3f60ceaca3b44d4216d067c9e30295b0490068cfa3cb81cdd1e90919?nocache=1

TeamBlackMiner_1_20_cuda_11_2.7z
https://www.virustotal.com/gui/file/7a99d5404890abbb80e9965b7e76a913abdaf13abf9685604c511a25c61766fd?nocache=1

TeamBlackMiner_1_20_Ubuntu_18_04_Cuda_11_4.tar.gz
https://www.virustotal.com/gui/file/af0374531ff5807315c7b10fc241a26b84c581640fb5c7075173911e9a479e0f?nocache=1

v1.20, 150 shares test on crazypool with default --xintensity 224. no stales. Good poolside hashrate.

3060 with LHR?

[sp_]

LHR1 470 driver hdmi dongle x16 riser cable. cuda 11.2 build 100% unlock

[KillrBee]

Nice speed for the 580 is that hynix memory ?

-In Nanopool the Hashrate is not being reported, I would appreciate it being fixed in the next version.

Use lowercase in the worker name

-And finally I would like to know if it is working to increase the speed of the RX6800 gpu; I understand that it was necessary to exceed the limit of memory OC and modifications of times that for now are blocked.

You should get around 68MHASH with a change in --xintensity to dynamic Bios mod can give you 72-75 but with more power

--xintensity [60,60,-1,-1,-1]

AMD kernel rewrite is ongoing.

Yes, they are Hynix memories but the Microns mark 34 Mh / s and only the Samsung mark 32 Mh / s because if I increase the speed a bit they give me memory errors.

Change the intensity -1 and increase the power for the rx 6800 but they only go up to 66.5 Mh / s and I have no idea how to get them to 72 Mh / s, I thought you were working on that

My internet connection is not stable so when I change the network I must wait 3 minutes to reconnect again, I would appreciate knowing how to reduce this time. Help me with this.

With the RX6800s in windows you need to push the gpu clock up to around 1500 to 1600, memory speed with these cards is a tricky thing -- it's not a linear increase in performance as the speed goes up, there are huge drop-offs at certain speeds. Although 2150 is the highest you can set it, and AMD drivers will drop that to 2140 because... I don't know, the drivers are weird.   Also, try cranking up the power level.  It doesn't seem to do much to some of my AMD RDNA2 cards, but others it will make a difference (sometimes better, sometimes worse).

As for the network issues --- that's not miner related so I'm not sure if there's anything anyone except your ISP can help with; why are you making network changes anyway?


Do I win a prize for a world record??

https://imgur.com/a/I4XdVdw

[moderator's note: consecutive posts merged]

[sp_]

Do I win a prize for a world record??

Alot of stales with that --xintensity. 6-7 seconds between jobs. Ethereum has a 15 second block time. Let it run for an hour, what is the average hashrate, and the reject rate?

[Ramsete2]

lol but who cares to see those numbers on miner?
What really counts is poolside incomes, and I really doubt this would be profitable with 100% stales...

Just FYI, even with pools that accept stales, Crazypool and Flexpool still remain more profitable.
This has been tested by real facts, not just by big numbers shown on miner's screen...

2nd day of fight: TBMiner vs GMiner

Third day. You had a v1.18 vs 2.70 earlier.

1. You are running on a mining pool that doesn't pay for stale shares. Change the pool and increase the intensity
2. You are running on sub optimal clocks. I know this is a power issue, and that pushing it to 106MHASH is not worth the power, but still..

I agree that I can play a little bit more with Xintensity.
But even with this settings, we are comparing a total hashpower of 615MHs against 591MHs, so I would expect a better performance from TBMiner, just because or pure "raw power".
Or probably I'm missing something...

[moderator's note: consecutive posts merged]

[KillrBee]

lol but who cares to see those numbers on miner?
What really counts is poolside incomes, and I really doubt this would be profitable with 100% stales...

Just FYI, even with pools that accept shares, Crazypool and Flexpool remain still more profitable.
This has been tested by real facts, not just by big numbers shown on miner's screen...

Lol.

I'm not a moron.  I know that big client side numbers are just big numbers and unless they stand up on the pool side it means nothing.  But then Usain Bolt getting the W.R. for 100m doesn't mean he's any good running that 1/4 mile to the bus-stop, but he still wins a medal for crushing that first 100 meters.

Anyway, there are no 'stales' reported at the pool side -- essentially the stales that TBM are reporting are meaningless to my poolside share rate. These numbers only have meaning in relation to the poolside block solution rate, so I might be able to add an extra 0.000005% block share at 2Miners by going from 130 to 150 MH/s on this card.  I'm just fucking around with numbers to see what changing different settings will do and provide some quality feedback, or in this case, low quality but impressive peak results (and I did see the appropriate spike on 2Miners share rate during this test window, but that equates to an average of 10 -11 extra shares per 60 minutes at the current difficulty).  
 

[Ramsete2]

If you can, please make a week test on 2miners, than another week on Crazypool (or Flexpool) and tell us the total pool's income in ETH for that time.
Adjusting the Xintensity accordingly, of course.
At the end, what really counts, it's the income.
So, better to find the best way to earn more money, compared to electricity costs, as well.

[sp_]

Flexpool and crazypool might be faster per share, but if you can submit and get payed for 5-10% more shares on 2miners. 2miners might be faster anyway.

In my tests I get a +5% more accepted shares on 2miners/miningpoolhub than on flexpool. Tested TBM with --xintensity 768

+ Get payed for stale shares +3% (--xintensity 768)
+ More accepted shares on higher intensities (faster) +2%

Is if flexpool is more than 5% more profitable per share than 2miners?

[Ramsete2]

Flexpool and crazypool might be faster per share, but if you can submit and get payed for 5-10% more shares on 2miners. 2miners might be faster anyway.

In my tests I get a +5% more accepted shares on 2miners/miningpoolhub than on flexpool. Tested TBM with --xintensity 768

Get payed for stale shares +3%
More accepted shares on higher intensities (faster) +2%

Is if flexpool is more than 5% more profitable per share?

Honestly the only way to compare two pools is to make a parallel test.
After my comparison between GMiner and TBMiner I could make a test with just TBMIner on two different pools, always using two rigs with the same hardware.

[sp_]

Honestly the only way to compare two pools is to make a parallel test.
After my comparison between GMiner and TBMiner I could make a test with just TBMIner on two different pools, always using two rigs with the same hardware.

Yes, that would be an interesting test for sure.. You should upgrade to 1.20 for some extra boost on crazypool.

[KillrBee]

If you can, please make a week test on 2miners, than another week on Crazypool (or Flexpool) and tell us the total pool's income in ETH for that time.
Adjusting the Xintensity accordingly, of course.
At the end, what really counts, it's the income.
So, better to find the best way to earn more money, compared to electricity costs, as well.

The problem with this is that we have to factor in the pool luck rate and correlate that to your miner luck rate per block and then adjust the actual block reward to remove the MEV and Tip variability to get a Pool to Pool, miner to miner equivalence.

I was running on MiningPoolHub, but their API only refreshes their miner data once every 5 minutes at best; I saw times where the miner hash rate wasn't refreshed for 20 minutes.  So it's basically impossible to really create any sort of 1:1 comparison unless the pools are running the same software with the same payout scheme at the same difficulty and have the same (or nearly the same) total pool hashrate which will at least give us only block rewards and pool and miner luck to deal with as profitability variables.

[crazydane]

Here's one of my 3090's in a test rig with just the default Xintensity:



Probably got more in her (EVGA KingPin 3090 on water), but figured I'd do a baseline'ish run first.  This is after about one hour.

[sp_]

Here's one of my 3090's in a test rig with just the default Xintensity:

My results while testing --xintensity 224

crazypool: 0-1% stales
nicehash: 0-1% stales
ethermine: 1-2% stales
flexpool: 2-3% stales

I had to lower the -xxintensity down to 144 to get 0-1% stales on flexpool, but 144 lost a few Mhash'es in the rig. So different pools have different optimal intensity settings
As a miner developer it's hard to set the "correct" one. It require alot of testing.

[dle378]

Here's one of my 3090's in a test rig with just the default Xintensity:

My results while testing --xintensity 224

crazypool: 0-1% stales
nicehash: 0-1% stales
ethermine: 1-2% stales
flexpool: 2-3% stales

I had to lower the -xxintensity down to 144 to get 0-1% stales on flexpool. So different pools have different optimal intensity settings.
As a miner developer it's hard to set the "correct" one. It require alot of testing.

Did you try running xintensity 224 on 2Miners or is 768 better?

[sp_]

Did you try running xintensity 224 on 2Miners or is 768 better?

Higher intensity seems to be better on 2miners, but not too high. Most of my test cards are old and with bad cooling. I would need two or more identical cards on the same clocks to do a better test.

The problem with this is that we have to factor in the pool luck rate and correlate that to your miner luck rate per block and then adjust the actual block reward to remove the MEV and Tip variability to get a Pool to Pool, miner to miner equivalence.

Yes. Some pools doesn't include the pool luck rate. When comparing two pools the luck is important to calculate a proper estimate.


We just changed to epoc 450.
All my test rigs survived the epoch change on v1.20. If you got crashed rigs because of high clocks, add --dagintensity 0. a possible fix


[moderator's note: consecutive posts merged]

[Ramsete2]

We just changed to epoc 450.
All my test rigs survived the epoch change on v1.20. If you got crashed rigs because of high clocks, add --dagintensity 0. a possible fix

Also my rigs survived, there was just a little fluctuation of the reported hashrate (yellow line), but nothing more:



ver 1.19

[ayiphelmy]

what about this?

[sp_]

Why don't you try v1.20 and see if you can reproduce it.