For 1.38, the 18.04 build is reporting lower hashrate than the 20.04 build, is this normal?
the ubuntu 18.04 build is cuda 11.4. The team black miner is optimized for cuda 11.5 Ubuntu 18.04 (2016) is not going to be supported next year, and is selected by the other mining softwares. |
|
|
|
I will build 1.39 today with fixes for Ethproxy pools and 0 rejected shares.  This bug has been there since version v1.00 Poolside rejects on hiveon.net and ezil.me and some other pools that use the ETHPROXY protocol. In the later versions we have improved the reject rate abit, but I think v1.39 will remove them all together. A stratum problem solved on NVIDIA and AMD rigs. Selecting the correct pool has been important when using TBM, but perhaps this will change after the bugfixed release is out. |
|
|
|
So latestet v1.38 is stable on HiveOS or does it require some tweaks? I did not get it
The ubuntu 18,.04 build was released late, but the 20.04 build is working with some tweaks. This is not help me for hive os , what can I do with this error ? Perhaps upgrade the rig to the latest hiveos image that has buildt in support for v1.38? |
|
|
|
Sometime only 1 card can launch success (My rig has 8 cards).
Did you try --dagintensity 1 You need to setup virtual memory. 40GB or more. Is ethereum classic working? |
|
|
|
I cant start mining even only 1 card in 1.37 & 1.38, but 1.35 is total normally. The config is all the same.
Windows 10, AMD RX 6600
cuda 11.4 or 11.5? whats the config? |
|
|
|
|
Ubuntu 18.04 build will probobly fix it. Today or tomorrow.
|
|
|
|
Yeah stale share miner for AMD, on my Nvidia Testrigs i got 0 stale shares over 3 weeks of mining. Strange miner
The xintensity is multiplied by 4 on amd. so 1000 on amd = 4000 on NVIDIA. Too high intensity on the wrong pool will give stales/rejects. |
|
|
|
Recorded shares in the recent 6 hours are displayed in the table above. If you have a significant amount of invalid shares, please check the GPU overclocking settings of your mining rig. If there are many stale shares (more than 5% of all shares), there is an issue with your internet connection. We recommend you to ping the pool with a special stratum-ping tool. When rewards are distributed according to the PPLNS scheme invalid and stale shares are not credited.
on 2miners.com: You will get rejected share (stale) if they don't pay for it . But in your screen you had 100% accepted so all good |
|
|
|
I am now in 2miners and v1.37 and this is how it looks like:
00:01:03 [2022-01-10 12:20:25.282] GPU0 590S 351.37 kH/W 29.52 MH/s 28.97 MH/s 10/0/7 100.00%
00:01:03 [2022-01-10 12:20:25.282] GPU1 6800 0.00 H/W 63.89 MH/s 63.29 MH/s 27/0/12 100.00%
The third column is estimated stale shares. 2miners pay for level 1 stales so it shouldn't be a problem. you have 100% accepted shares in the window. You can check in the pool statistics for stale shares. |
|
|
|
The speed is good. The miner window will report stale shares, but if you check the pool you will se almost no stales. |
|
|
|
Thank you. Any more ideas for intensity or maybe more tweaks? It's already like sport for me - just wanna understand TBM!  High xintensity only work on some pools. Pools that pay for stale shares. (f.ex 2miners.com, miningpoolhub, nanopool, f2pool and many others.) The Ethereum blockchain reward stale work, and pools that are made for Bitcoin style blockchains doesn't work so good with the TBM miner. High intensity with tweak might reduce the stales. You can try 2miners.com with --xintensity 4096, and get 100% accepted shares and few stales poolside, but on flexpool, ethermine, crazypool. ~5% stales and lower payouts. Other than that, there were times when this wasn't occurring that I was seeing 71 MH/s as the Average (3 hour) hashrate at the 2miners pool -- which is about 12-13% above anything else I've ever seen! (512 intensity; 1642 MHz GPU; 2122 MHz Memory {Actual runtime reported values} @ 145 Watts).
512 AMD intensity is equal to 2048 for cuda cards. Above 1024 is probobly not working good on AMD cards, but I have reports of good returns with 6xxx on nvidia as well. On the 2080 Super. So perhaps 1250 is the maximum good value? |
|
|
|
Hello. How to run autotune? Want to tune my good old 1070 Thanks If no --kernel parameter is set the program will autotune automatically. Here in the picture (RTX 2060 mobile on ubuntu 20.04) kernel 8 was selected and kernel 0 was measured to be 2.12% slower. (gpu speed is percent of the fastest kernel) On 1070 --kernel 0, 1 or 2 is usually the fastest. You need a high coreclock and power to get the best speeds.  |
|
|
|
|
I would think that kern 6-8 will perform best.
but depends on the power settings of your gpu. A lower kernel number works better if the gpu has a low tdp. Run the autotune a few times and see which one is the fastest in your setup. Increase the power if it doesn't end up 5-8
|
|
|
|
Hi what settings I must use on rig with 13 3080 Palit GameRock no lh , I try any kernels and xint , but L0L miner , faster all time . I am on 2miners pool , driver 495.46 HIVE os , maby I don't understand what to do with alot of settings , kernel , tweak , xint . Can you help me ? I have the same rig , on lol , and it faster (((
try --xintensity 3108 or --xintensity 2331 And let it run for a few days. |
|
|
|
I see, so the reported hashrate should now be more accurate, right? However, why does the latest version show higher hashrate in the beginning and then it drops?
The Poolspeed is sometimes high and sometimes low in the beginning. The average hashrate is only accurate after enough samples has been collected. The gpu can also trottle. f.ex if the memory or core is too hot, the speed will be reduced. Other factors that can reduce the poolspeed hashrate is problems with the internet / network / pool. |
|
|
|
|
You should run the cuda 11.5 build for the best speed.
hashrate bugs in 1.28
When a solution was found, it exited the solver immediately without scanning the whole range of nonces, but the full hashrate was added. This is caused a inflated hashrate. Worse on on low difficulty.
An index bug sometimes caused hash to be added to the wrong gpu, so if you run with a good gpu and a poor gpu in the rig, the poor gpu's hashrate could be inflated.
In 1.29 we don't send shares to the pool if the diff hash changed. On a vardiff pools (p2p style) or simulator pools this might reduce the hashrate, but we did it to reduce rejected shares on real pools like Nicehash.
in v1.36 we have increased the number of samples in the average hashrate, so you should run for a longer period of time.
We reduced the default intensity to reduce the stale shares.
Poolside the cuda_11_5 1.36 should be better, but the defaults might not.
f.ex for AMD cards
--xintensity 512 is pretty good on 2miners.com . Much better than 24.
AMD 6900xt:
xintensity 24: ~60MHASH poolside
xintensity 512: ~70MHASH poolside
|
|
|
|
|
Windows or Linux? cuda 11.5 build? Driver?
in 1.36 you need to increase the --xintensity for the best speed.
|
|
|
|
|
Show Posts
