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.
|
|
|
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?
|
|
|
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?
|
|
|
LHR1 470 driver hdmi dongle x16 riser cable. cuda 11.2 build 100% unlock
|
|
|
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.
In v1.20 we have implemented a --dagintensity parameter that can help users remove DAG validation errors with RTX cards on high oc. Will Release tomorrow [moderator's note: consecutive posts merged]
|
|
|
Read the faq https://github.com/sp-hash/TeamBlackMiner/blob/main/FAQ.mdMany miningpools accept stale shares, but can start rejecting them if you send more than 5% stales. The ethereum blockchain pay 87.5% for stale share blocks (uncle blocks) The bitcoin blockchain pay 0% More than 50% of the Ethereum mining pools pay for stale shares. The Team Black Miner works best on pools that pay for stale shares.
|
|
|
C-Clock = 1500 (this is a good mid-point for managing the voltage without actually setting the voltage -- I'm running 0.778V at 1500 core) M-Clock = +1625MHz => 11376MHz PState =0 PowerLevel = (85-119% depending on your Xintensity level) Xintensity = 2100 I'm mining on 2Miners and getting 136 - 137MH/s at the client (reporting 158.74 MH/s as Pool Hashrate @ 1.11 Shares per minute) That's a nice pool hashrate. Too much focus on stale shares, and too little focus on profit... This is not bitcoin mining, this is ethereum.
|
|
|
1.20 will be released soon with more fixes
|
|
|
it's already been fixed. Download the latest 1.19 from github.
|
|
|
TBMiner vs GMiner competition, update after one day: TBMiner (ver 1.19) GMiner (ver 2.70) The default --xintensity 160 in v1.19 seems to have reduced some stale shares and increased the profit on this pool. vs --xintensity 192 in v1.18. --kernel 8 is looking good. Tbminer - Gminer 2-0
|
|
|
use another program to set memclocks. msi afterburner is good
|
|
|
on 2miners try --lock-cclock [1500,1500] --kernel 8 --xintensity 768 -1 is for AMD cards. Also, getting this msg "Cannot open nvidia-smi for gpu utilization information" when it starts.
Reinstall the driver. stats will not work properly without nvidia-smi
|
|
|
More than 5% stale. The point is that 2miners will reject your shares if you have more than 5% stales. If you get 100% accepted shares you are good.
Adding the parameter "--no-stats" fixed the issue! Any chance as to why this parameter prevents the crashing of the miner in this version versus the previous ones? A bug intruduced in 1.19, fixed in 1.20. [moderator's note: consecutive posts merged]
|
|
|
What pools will pay for stales? Thanks
https://github.com/sp-hash/TeamBlackMiner/blob/main/FAQ.mdMore than 50% of the network is rewarding stale work: - miningpoolhub (100% reward for stale shares) - 2miners (100% reward for stale shares) - nanopool (100% reward for stale shares) - antpool (100% reward for stale shares) - Spiderpool (100% reward for stale shares) - F2Pool(100% reward for stale shares) - uupool(100% reward for stale shares) - xnpool.com(100% reward for stale shares) - woolypooly (100% reward for stale shares) - ezil (70% reward for stale shares) -hiveon (80% reward for stale shares) And there are more...
|
|
|
The ethereum blockchain pay 87.5% for level 1 stale shares. It's called uncle blocks. 6 levels of stale shares are payed, but the lower levels have a lower payout. When a mining pool reject your stale work they can actually take your money. Most pools pay for stale work, but the percentage can be reduced. Read the faq. This is not a miner problem. The Team Black miner is made by the people who made the first opensource Ethereum miners for NVIDIA. Rejecting stale shares is dangerous for the security of the blockchain by design and should be avoided. https://github.com/sp-hash/TeamBlackMiner/blob/main/FAQ.mdThe bitcoin blockchain and other coins that based on this blockchain doesn't reward stale work but the same rules doesn't apply for ethereum. Only a few ethereum mining pools doesn't pay for stale shares.
|
|
|
We had the wrong linux build of the v1.19 build that was included in hiveos. A new one has been uploaded to the same place. Hashrates will fluctate on high difficulty, sometimes higher sometimes lower, this is normal https://github.com/sp-hash/TeamBlackMiner/blob/main/FAQ.mdAbout the hashrate, better results on pools that pay for stale shares. It's not about rejected shares, its about the way the protocol and pool work that is the problem. Increase the intensity : +2-3% Mine on a pool that pay for stale shares: +1.5% +4.5% better poolside hashrate if you change the pool. - Crazypool doesn't pay for stale shares - Flexpool doesn't pay for stale shares
I'm also having the same issue on Hiveos, all rejected shares Coin: ETC Pool: miningpoolhub GPUs: 4 x RX570 4GB
Your clocks are too high. When you see the hashrate drop to 0 and time out, reduce the clocks. This kernel is different from the other miners and need a retuning of the clocks. Lower clocks and increased intensity can increase the hashrate and the profit. Set the intensity manually to increase stability [moderator's note: consecutive posts merged]
|
|
|
Oh. sorry about that, it will be added again in v1.20
Crashes after one minute of running with --kernel 0, 1, 4, 6, 8.
I am using default clocks during the initial start of TBM.
try with --no-stats. And then without --lock-cclock. The dag verification code will be improved in v1.20. With options to create the dag slower. [moderator's note: consecutive posts merged]
|
|
|
yes. we will try to improve this in the next versions.
|
|
|
Also, it seems that there's a problem when trying to set memory clock
Read a couple of posts back, we only support the memclock values from nvidia-smi. Use another program to set the memclock for now. msi afterburner is good.
|
|
|
|