|
Note that the dag cache isn't implemented in 1.27 for amd cards, so when you mine eth+zil you loose 2 dag generations every 90 minutes. A few percent. This is fixed in v1.28
|
|
|
|
In epoc 455 the 1080ti need abit more power and coreclock to keep the hashrate. In msi afterburner increase the powerlimit(80 ?) and the templimit (85), and try to get the coreclock stable at 2050... 47 MHASH Here with --kernel 0 --xintensity 1024... core: 2060 mem: 5700 Lower kernel numbers are stable on higher clocks.  |
|
|
|
Now it hangs here for several minutes after not doing anything,this same error happens with lolminer only they
This is not a crash. Do you see the white square in the window? Rightclick with the mouse in the window. And the output will resume. A problem with windows 10. You can try without --kernel 0 in the bat. Then the program will autotune. It might go faster. |
|
|
|
I did it like that exactly.Here is a picture of the error anyway and of the bat file configuration.Tell me what is wrong.
There was an error in the docs. The correct parameter is --worker-name and not --worker_name so rename to --worker-name |
|
|
|
--computername
computername is not needed use: --worker_name swogerino |
|
|
|
|
Set ETH_WALLET=(ethereum wallet)
Set ZIL_WALLET=(zil wallet)
:loop
TBMiner --algo ethash --hostname eu.ezil.me --port 5555 --wallet %ETH_WALLET%.%ZIL_WALLET% --worker-name %computername% --dagintensity 1 --kernel 0
timeout 10
goto :loop
Use the pill in the backround for the 1080ti.
|
|
|
|
|
v1.28 will have improved performance for amd cards on ETH+ZIL (dagger cache). We have also added the possibility to mine to ip adresses directly instead of hostnames.
|
|
|
|
I am setting the dagintensity value to "9", is that considered too high of a number?
Thanks. 0 or 9 is the default setting for nvidia. |
|
|
|
This is BS. If you find more solutions than you submit it will lower the pool's hash rate, the one that matters.
If this is really happening it's a software defect that should be fixed.
The point is that mining on super Low difficulty is not a real case scenario. Check the latest NBMiner. They have moved the cpu verfication code out to it's own thread in order to perform better on low difficulty. We might do the same in tbminer, but why should we? No ethereum pools use low difficulty, so it wont affect the profit, but it can improve the test scenario.. Better to disable cpu verification. A software defect in the test, not in the miner. |
|
|
|
Is there any benefit in adding the dagintensity value if mining on miningpoolhub?
The point of the --dagintensity 1 is to avoid crash on dag creation on high clockrates. You can oc the memory +100-200 or more with this setting on, but the dag generation will be slower. So not good in eth-zil mining. In v1.28 we will do an adjustemnt to the dag creation with --dagintensity and make it slower. |
|
|
|
My reply to you in my thread: Yes it said all... You said Pool 53 Mhs and is 50Mhs... where are this 3Mhs?
The pool is the average of 6 hours, but he has only mined for 5:48 and the last accepted shares has not been added to the pool yet... The pool only refresh every 10minutes. So I expect the 50.50MHASH poolside hashrate comes from 5:30 minutes of mining If you want to mine on low difficulty use --xintensity 1 . The hashrate will hurt, but perhaps the fake test will show the same numbers as in the miner window. I have explained to you why in the thread above, but you don't seem to listen. When the difficulty is low, the gpu mining software will need to submit all the found solutions in a warp to the pool,. On high diff only 1 solution is found, but on low diff 16 or more could be found, and this could cause the mining software to skip sending solutions to the pool because 2 or 4 is the maximum solutions limit per warp in the optimized code.. An other problem is that on low difficulty the jobs enter the miner much more rapidly, and then the gpu has to abort work more often. So by reducing the workload (intensity) of each warp it will give an advantage in the test. This means that it is easy to improve the "test results" in the simulation, but it won't improve the profit on the pool...
The point of a miner software is to make money. Configure it wrong and you will loose money. |
|
|
|
Yes it said all... You said Pool 53 Mhs and is 50Mhs... where are this 3Mhs?
The pool is the average of 6 hours, but he has only mined for 5:48 and the last accepted shares has not been added to the pool yet... The pool only refresh every 10minutes. So I expect the 50.50MHASH poolside hashrate comes from 5:30 minutes of mining |
|
|
|
Pictures say more than words. This is a real test on a real mining pool.. With a real profit difference. The hashrate you see is real. The hashrate reported in the miner window is confirmed. Why don't you do a test on the 2miners pool with --xintensity 4096? Compare it with all the other miners. And you will see why more and more ppl are switching to the Team Black Miner... |
|
|
|
Pictures say more than words. |
|
|
|
This is not a real test. The TRM Ethash Miner Tester v1.0.0 is reducing the difficulty too much. Why don't you do a real test with 1 million shares on a normal pool? When the difficulty is low, the gpu mining software will need to submit all the found solutions in a warp to the pool,. On high diff only 1 solution is found, but on low diff 16 or more could be found, and this could cause the miningsoftware to skip sending solutions to the pool because 2 or 4 is the maximum solutions limit per warp in the optimized code.. An other problem is that on low difficulty the jobs enter the miner much more rapidly, and then the gpu has to abort work more often. So by reducing the workload (intensity) of each warp it will give an advantage in the test. This means that it is easy to improve the "test results" in the simulation, but it won't improve the profit on the pool... Users who have switched to the team black miner has reported more than +5% poolside profit. Check it out... https://www.youtube.com/watch?v=YtFqb8I_eVIAnd read the faq for the optimal pools and settings. https://github.com/sp-hash/TeamBlackMiner/blob/main/FAQ.md |
|
|
|
It's all AMD and I explicitly use --amd-only to exclude the 1 Nvidia card I have in that machine from TBM
Perhaps the --amd-only switch isn't working. Try to select --cl-devices manually --cl-devices [0,1,2,3,4,5] Use tbminer --list-devices to get the correct indexes. |
|
|
|
So, 1.25 is working. 1.26 is working. "The Latest" (not sure if it's +cuda or without cuda), is not working
In the latest version opencl has been disabled for nvidia. so the if you select amd devices with --cl-index you need to change the indexes. Use tbminer --list-devices to find the correct indexthe pool url has to end with 2miners.com so use eth.2miners.com and --port 2020 |
|
|
|
Happens to me when I'm near 100% actual power utilization for long periods of time. Try reducing your gpu clock to 1500 or 1560 and that should pull the power usage down enough for a stable overclock.
You can use the tbminer option --lock-cclock [1560,1560] |
|
|
|
|
Show Posts
