Update after about one day of GMiner vs TBMiner competition  TBMiner (ver 1.18):  GMiner (ver 2.70):  TBminer - Gminer 1-0 |
|
|
|
Should I revert back to 1.17 until that bug is fixed in the next release?
No need, the bug is only displaying the wrong pool speed, and has nothing to do with performance. In v1.19 poolspeed will be disabled for vardiff pools. Is xintensity 512 too low for 2miners?
you can try 800 |
|
|
|
Am I the only one who doesnt understand how to disable one of my two GPU??   Tried -Y 0 -Y 1 Use brackets around the selection --Y [0,1]
Is there supposed to be a significant variance between the Pool Hashrate and the Hashrate reporting within TBM?
You seem to be abit unlucky here. Normally it will even out over time. Higher difficulty, higher fluctation in the hashrate poolside. v1.18 has a bug in the stats for pool that use vardiff. F.eks Nicehash.
1345m [2021-10-23 22:13:06.008] 0.00 H/W 693.68 MH/s 694.60 MH/s 9678/41/200 (99.58%)
Should I be concerned about the rejected shares ?
99.58% is a good result on nicehash. I see that you run with --xintensity 224, you can lower the xintensity to remove stales, but then the hashrate will drop as well. [moderator's note: consecutive posts merged] |
|
|
|
Only gpu 2, 3 & 4 should be set as to work with TBM.
--cl-devices [2,3,4]
i use nb miner with mem tweak get 34.xx mhs
TBM should be faster on the gtx 1070. Memtweak for the gtx 1070ti has not been implemented yet, but you can use the t-rex to get the cards to tweak correctly for free. nbminer ~34MHASH -1% fee TBminer+trexmemtweak ~35MHASH -0.5% fee [moderator's note: consecutive posts merged] |
|
|
|
To understand better for myself; my 5 gpu's are all AMD's, and with your command I would set those first 2 as to use the Nvidia Cuda so disabling them AMD's, right?
Unfortunately it does not seem to work.
For amd you need to use --cl-devices [0,1]
i think a lot of room to improve 1070ti hashrate... maybe u can consider change something
1070ti needs memtweak. You can run an old t-rex miner on ultra low intensity in the backround. will boost the hashrate from 32-33 to 34-35. For the gtx 1080 and gtx 1080ti use "the pill" [moderator's note: consecutive posts merged] |
|
|
|
I have a split miner on HiveOS on which gpu's 0 and 1 work on a different miner (TRM) than gpu's 2, 3 and 4 (GMiner).
I wanted to switch gpu's 2, 3 and 4 to TeamBlackMiner.
In the miner configuration of TBM I can disable gpu's 0 and 1 by adding 0,1 in the appropriate field.
But this is not really disabling those gpu's. TBM is starting them up together with the other miner, resulting in a rig crash.
Any suggestions?
Use brackets around the selection --cuda-devices [0,1] Make sure you don't use it with --auto-detect |
|
|
|
I noticed that the Nvidia 1060 6Gb cards do not work.
Do I need to set anything to work?
1060 6gb should work. Whats your driver version and os?. The cuda 11.5 build needs the latest driver. |
|
|
|
the shell. Same behavior. I've noticed that there is a "Cannot open shared object file" message the occurs occasionally. Maybe this is related?
We are currently using the AMD Display (ADL) Library to read AMD stats. This is an outdated library, and we are working to add another way to do the stats. The error message is probably from a failing adl request. Improved support for AMD cards is comming, Higher priority than LHR NVIDIA support at the moment. |
|
|
|
I'm doing some Max.Performance testing on version 1.18 with my 3090. Here is a screen cap of the results and setup values for the OC. One thing to note is that there is a large variance on intensity and power, setting the intensity too high with a high OC will drop power levels due to throttling (even though the card doesn't report any performance limits other than utilization, which is normal when the card is being used for mining). In this run I have the intensity set to 2200 - kennel selected as 7  Really nice speed, but --xintensity 2200 won't work on all mining pools. For new miners, you should read our faq https://github.com/sp-hash/TeamBlackMiner/blob/main/FAQ.mdThe trottle could be because the memory temperature get too hot. You feed the card too much work and power  |
|
|
|
|
v1.19 will have reset clock on dag generation. So if you set the clock with lock clock, the program will automaticly reset to default on epoc change/dag generation.
|
|
|
|
It happened already twice, once exited because one card was stuck at 0, and once as the screenshot below, one GPU dag verification failed.
V1.16 has a too high default xintensity for the rx570/580 cards. You can try --xintensity 78 or upgrade to v1.18. In v1.18 the default will run at same speed, but half of the stale shares. |
|
|
|
|
What's the output of
$ nvidia-smi ?
|
|
|
|
All my cards are recognized except the RX 580 models (I have 3 of them).
Not sure about hiveos but I am running the 580 and the 570 without any problems on windows. Stats are working as well for these cards.
I say that I have the same frequency as gminer 1070/2200 and I am at 4900w instead of approximately 4750.
I tried all the kernels, all the intensities lol always the same.
The lowest power with --xintensity 1 --kernel 0, but not so good hashrate...
stale share 1% and i dont see any error
Is the miner restarting often. I see a dip in reported hashrate, lost internet connection? Look for gpu timed out messages in the log.
in the new version also put the stars all X min
as an example all --stats 30
so every 30min
You can use the --no-stats option to turn it off.
Does this support the Pascal mining edition cards such as P-104's and 102's? Tried it out but after saying it's generating dag it exits the thread and fails to actually mine. Using Windows 10 with 472.12 drivers, tried both the cuda 11.4 and 11.2 versions, as well as auto and default xintensity and lower kernels.
Use the v1.18 cuda 11.5 build If not run with --kernel 0. The P102, and P104 is running a build in memtweak that caused problems in the earlier versions. You can try to remove any overclock and tune until it crashes. [moderator's note: consecutive posts merged] |
|
|
|
=> [2021-10-23 09:32:07.269] API request (127.0.0.1)
yes. will be removed in v1.19 how to reduct watt ?
for nvidia: -M --power-limit [,] (set powerlimit)
- Still have bug of not showing any statistics (TEMP, FAN, CORE, MEM, WATT, HASHRATE/W), using latest NVidia beta driver
Windows or linux? There was a bug in the linux version that was fixed in v1.18 - If Kernel is on Auto, miner will choose various numbers, even if cards (Zotac RTX3080) are identical
--kernel 6 should work good on the rtx3080. The autotune can be improved, it is running too short time in v1.18. - Miner will not connect on pools on SSL (please solve this bug a.s.a.p. thanks)
yes. This is first priority right now. [moderator's note: consecutive posts merged] |
|
|
|
I get an "incorrect login" if I use the SSL url, and a weird "SSL connect error"
There is a problem with the SSL connection. We are working on it. Use the normal ports
average hashrate is dropped with tbm see this graph below
Check the log file for errors. perhaps you need to tune different. Too many stale shares? [moderator's note: consecutive posts merged] |
|
|
|
gtx 1660 with memtweak (bios mod) ~35MHASH !
--kernel 0 / GPUMemoryTransferRateOffsetAllPerformanceLevels=1700
57m [2021-10-18 17:57:42.023] GPU0 1660S 0.00 H/W 34.98 MH/s 35.01 MH/s 18/0/0 (100.00%)
57m [2021-10-18 17:57:42.023] GPU1 1660S 0.00 H/W 35.14 MH/s 35.11 MH/s 29/0/0 (100.00%)
57m [2021-10-18 17:57:42.023] GPU2 1660S 0.00 H/W 35.18 MH/s 35.10 MH/s 22/0/1 (100.00%)
57m [2021-10-18 17:57:42.023] GPU3 1660S 0.00 H/W 35.10 MH/s 35.01 MH/s 22/0/0 (100.00%)
57m [2021-10-18 17:57:42.023] GPU4 1660S 0.00 H/W 33.33 MH/s 33.49 MH/s 24/0/1 (100.00%)
57m [2021-10-18 17:57:42.023] GPU5 1660S 0.00 H/W 33.43 MH/s 33.47 MH/s 21/0/0 (100.00%)
57m [2021-10-18 17:57:42.023] GPU6 1660S 0.00 H/W 35.02 MH/s 34.96 MH/s 26/0/0 (100.00%)
57m [2021-10-18 17:57:42.023] GPU7 1660S 0.00 H/W 34.83 MH/s 34.96 MH/s 32/0/1 (100.00%)
57m [2021-10-18 17:57:42.023] GPU8 1660S 0.00 H/W 35.03 MH/s 35.03 MH/s 20/0/1 (100.00%)
57m [2021-10-18 17:57:42.023] GPU9 1660S 0.00 H/W 35.03 MH/s 35.03 MH/s 24/0/0 (100.00%)
57m [2021-10-18 17:57:42.023] GPU10 1660S 0.00 H/W 35.09 MH/s 35.01 MH/s 32/0/0 (100.00%)
57m [2021-10-18 17:57:42.023] GPU11 1660S 0.00 H/W 34.94 MH/s 35.00 MH/s 29/0/0 (100.00%)
57m [2021-10-18 17:57:42.023] GPU12 1660S 0.00 H/W 32.47 MH/s 32.42 MH/s 25/0/0 (100.00%)
57m [2021-10-18 17:57:42.023] GPU13 1660S 0.00 H/W 35.16 MH/s 35.09 MH/s 30/0/0 (100.00%)
57m [2021-10-18 17:57:42.023] 0.00 H/W 484.71 MH/s 484.68 MH/s 354/0/4 (100.00%)
The gtx 1660S cost nothing, and very profitable with The Team Black miner.. This snapshot is running with --kernel 0 v1.18 works with --kernel 7 @copyspeed
I'm running HiveOS 1.16 build
If you know how to update to 1.18 on Hive, I'll be happy to try
https://github.com/sp-hash/TeamBlackMiner/releases/Download the v1.18 ubuntu cuda 11_4 build, unzip it ssh into the rig and replace the tbminer file... [moderator's note: consecutive posts merged] |
|
|
|
it will max when your gpu run out of memory. LHR cards run good at max speed in 2 minutes using --xintensity 10000, but profitwise not good. And then you need to reset the device and regenerate the dag.
The team black has the fastest dag generator in the world. So all you need to do is to reverse engineer our code. MIT students can do it in a few days. but why don't you try to solve it yourselves? |
|
|
|
|
it will max when your gpu run out of memory. LHR cards run good at max speed in 2 minutes using --xintensity 10000, but profitwise not good. And then you need to reset the device and regenerate the dag.
|
|
|
|
|
are you running v1.18? can you test --xintensity 1024
|
|
|
|
|
Show Posts
