 Show Posts
|
|
Pages: [1] 2 »
|
That sounds like sp__ is back!  ))))) I would love resolution as then i would just have to switch to your miner without tweaking any cards instead of tweaking 5 rigs with multiple 3070s. Luckily my son has 3070 on this gaming machine so i test here. I will create a cache of the dag buffer on file. On every new epoc, one of the cards in the rig needs to be able to create the dag buffer. And if the validation fails for the other cards, the program will read from file. Will use around 5GB of harddrive space, but no need to reduce the clocks. I'm testing 1.45 on HIVE OS. At the start, the hashrate results on the pool and shares are good, I use cuda 11.4 Nvd driv. 470.94 , --kernel 1, --xintensity 1988 , cclock 1311. The miner still gives a dag generation error on rigs 3060 - 3070 . I continue the test. I noticed that your miner works fine for the first 24 hours, but then the speed slows down, the hashrate on the pool becomes smaller, maybe this is due to Hive OS and cuda 11.4 You should do more tests under HIVE OS, more than 24 hours.  I've done some analysis based on the shares per minute as at-pool hashrate and: *The miner stabilizes at around the 70 minute mark and remains fairly stable until at about the 300 minute mark, the miner performance begins to degrade after this. At the 430 minute mark, the degradation levels off and remains relatively constant until around the 500 minute mark where it degrades again until about the 600 minute mark where it remained stable / slightly increasing until the end of the sample dat at 780 minutes. It seems that for whatever reason, the first 60 minutes sees the most improvement and the highest share/minute production after it peaks decreases significantly to the 70 minute mark where it stabilizes until the 300 minute mark. yes, at the start it is very fast, but then the same LoL miner overtakes it and gives a more stable hashrate. The developer needs to conduct detailed tests for more than a day to stabilize his work while I return to LoL To be fair, at the end of my 780 minute (13 hour) run, the median/mean hashrate for my 3090 was 181/182 MH/s with a STD.Dev of +/- 10 MH/s, so I'm not complaining. I ran the test for more than a day and my hash dropped from 1345 to 1275 in the miner in about 27-28 hours. The pool averaged 1.26 gh/s over 6 hours |
|
|
|
That sounds like sp__ is back! ))))) I would love resolution as then i would just have to switch to your miner without tweaking any cards instead of tweaking 5 rigs with multiple 3070s. Luckily my son has 3070 on this gaming machine so i test here. I will create a cache of the dag buffer on file. On every new epoc, one of the cards in the rig needs to be able to create the dag buffer. And if the validation fails for the other cards, the program will read from file. Will use around 5GB of harddrive space, but no need to reduce the clocks. I'm testing 1.45 on HIVE OS. At the start, the hashrate results on the pool and shares are good, I use cuda 11.4 Nvd driv. 470.94 , --kernel 1, --xintensity 1988 , cclock 1311. The miner still gives a dag generation error on rigs 3060 - 3070 . I continue the test. I noticed that your miner works fine for the first 24 hours, but then the speed slows down, the hashrate on the pool becomes smaller, maybe this is due to Hive OS and cuda 11.4 You should do more tests under HIVE OS, more than 24 hours. I've done some analysis based on the shares per minute as at-pool hashrate and: *The miner stabilizes at around the 70 minute mark and remains fairly stable until at about the 300 minute mark, the miner performance begins to degrade after this. At the 430 minute mark, the degradation levels off and remains relatively constant until around the 500 minute mark where it degrades again until about the 600 minute mark where it remained stable / slightly increasing until the end of the sample dat at 780 minutes. It seems that for whatever reason, the first 60 minutes sees the most improvement and the highest share/minute production after it peaks decreases significantly to the 70 minute mark where it stabilizes until the 300 minute mark. yes, at the start it is very fast, but then the same LoL miner overtakes it and gives a more stable hashrate. The developer needs to conduct detailed tests for more than a day to stabilize his work while I return to LoL |
|
|
|
That sounds like sp__ is back! ))))) I would love resolution as then i would just have to switch to your miner without tweaking any cards instead of tweaking 5 rigs with multiple 3070s. Luckily my son has 3070 on this gaming machine so i test here. I will create a cache of the dag buffer on file. On every new epoc, one of the cards in the rig needs to be able to create the dag buffer. And if the validation fails for the other cards, the program will read from file. Will use around 5GB of harddrive space, but no need to reduce the clocks. I'm testing 1.45 on HIVE OS. At the start, the hashrate results on the pool and shares are good, I use cuda 11.4 Nvd driv. 470.94 , --kernel 1, --xintensity 1988 , cclock 1311. The miner still gives a dag generation error on rigs 3060 - 3070 . I continue the test. I noticed that your miner works fine for the first 24 hours, but then the speed slows down, the hashrate on the pool becomes smaller, maybe this is due to Hive OS and cuda 11.4 You should do more tests under HIVE OS, more than 24 hours. |
|
|
|
I am leaving the house now and can continue testing tomorrow.
Thanks for support!
TeamBlackMiner_1_44_cuda_11_6_beta6.7z The dag is taking 10 seconds on the 3070 Mobile in 1-44 beta 6 with --dagintensity 1. I am able to run stable on higher memclocks  My observations for almost a day of mining on a 12x3080 no LHR rig. 1. If you are using Hive OS, use cuda 11.4, 11.5 gives a slight drop in hashrate. 2. I tried all the cores of the miner, the core does not automatically set correctly in Hive OS (1.42 core 1, 1.43 core 3). You must manually set the sign from 6 to 8 if you use 1.42 and 12-15 if use 1.43 20xx 30xx series of cards. 3. It makes no sense to set the core clock above 1440, it does not give any performance, it only increases the temperature of the cards and power consumption. This only works on older cards like 1070, 1080, 1080 Ti with gdd5 memory. On cards with GDDR 6-6X memory, the core does not participate in ETH mining and there is NO point in increasing it! I tested the range from 1200 to 1600, anything above 1440 gives a drop in hashrate. 4. Option --xintensity , you need to select individually, for example, it works better for me on 8100 than on 4096. Bugs that I found, on a rig with 13 video cards 3090x2 3080x7 3070 x4 NO LHR, I could not achieve stable operation, constant dag generation errors and a lot of invalid shares. Also, a 12x3070 NO lhr rig gives errors during dag generation, option --dagintensity 1 is always on. Wishes, you should conduct detailed tests under HIVE OS, mining on Windows is extremely inconvenient and not popular. Big miners don't use Windows. Improve stability and fix core map definition. I will continue to test it on different rigs to find bugs and errors in the hive, as well as to find the optimal settings.  I've extensively tested TBM with an RTX3090 and can conclusively say that setting the core clock above 1440 does make a difference, especially in a windows environment. setting core clock is the only way we have to set the voltage of the cards in Linux, and 1650 for the GPU sets the voltage to 0.78 which is the sweet spot for the 3090 with a high xintensity value. I've tested 1500, 1550 and 1600 and the only way I've been able to obtain 135+ MH/s at-pool hashrate is by being at 1650 -- I will provide one caveat on those numbers, is that the testing was done on versions 1.24 to 1.28, afterwards I stopped because I was happy with the performance, and the later versions focused on LHR, which for some reason had a negative effect on the non-LHR cards until this last release. Version 1.27 was where I was able to achieve the highest rates on my 3090, and version 1.41 is where the AMD cards started to achieve 66+ MH/s under windows and 65+ under HiveOS. OK, I think you use it now ? Can you show your up time in hive os ? Here is my current HiveOS status -- I have a windows machine running an AMD 6900XT which I'm using to try and optimize my AMD cards in the Linux rig.  I just realized the the GPU and Memory stats are missing from the display (happens with HiveOS). Here is my HiveOS GUI for the reference values:  Not bad , what cuda and drivers do you use ? 11.5 ? Or 11.4 ? I'm using the 11.4 CUDA right now since 11.5 in linux underperforms. But I'm switching back and forth between 470.94 and 495.46 while running the 11.4 CUDA runtime to see if there's any driver benefits. how is your test going? what are the results? |
|
|
|
I am leaving the house now and can continue testing tomorrow.
Thanks for support!
TeamBlackMiner_1_44_cuda_11_6_beta6.7z The dag is taking 10 seconds on the 3070 Mobile in 1-44 beta 6 with --dagintensity 1. I am able to run stable on higher memclocks My observations for almost a day of mining on a 12x3080 no LHR rig. 1. If you are using Hive OS, use cuda 11.4, 11.5 gives a slight drop in hashrate. 2. I tried all the cores of the miner, the core does not automatically set correctly in Hive OS (1.42 core 1, 1.43 core 3). You must manually set the sign from 6 to 8 if you use 1.42 and 12-15 if use 1.43 20xx 30xx series of cards. 3. It makes no sense to set the core clock above 1440, it does not give any performance, it only increases the temperature of the cards and power consumption. This only works on older cards like 1070, 1080, 1080 Ti with gdd5 memory. On cards with GDDR 6-6X memory, the core does not participate in ETH mining and there is NO point in increasing it! I tested the range from 1200 to 1600, anything above 1440 gives a drop in hashrate. 4. Option --xintensity , you need to select individually, for example, it works better for me on 8100 than on 4096. Bugs that I found, on a rig with 13 video cards 3090x2 3080x7 3070 x4 NO LHR, I could not achieve stable operation, constant dag generation errors and a lot of invalid shares. Also, a 12x3070 NO lhr rig gives errors during dag generation, option --dagintensity 1 is always on. Wishes, you should conduct detailed tests under HIVE OS, mining on Windows is extremely inconvenient and not popular. Big miners don't use Windows. Improve stability and fix core map definition. I will continue to test it on different rigs to find bugs and errors in the hive, as well as to find the optimal settings. I've extensively tested TBM with an RTX3090 and can conclusively say that setting the core clock above 1440 does make a difference, especially in a windows environment. setting core clock is the only way we have to set the voltage of the cards in Linux, and 1650 for the GPU sets the voltage to 0.78 which is the sweet spot for the 3090 with a high xintensity value. I've tested 1500, 1550 and 1600 and the only way I've been able to obtain 135+ MH/s at-pool hashrate is by being at 1650 -- I will provide one caveat on those numbers, is that the testing was done on versions 1.24 to 1.28, afterwards I stopped because I was happy with the performance, and the later versions focused on LHR, which for some reason had a negative effect on the non-LHR cards until this last release. Version 1.27 was where I was able to achieve the highest rates on my 3090, and version 1.41 is where the AMD cards started to achieve 66+ MH/s under windows and 65+ under HiveOS. OK, I think you use it now ? Can you show your up time in hive os ? Here is my current HiveOS status -- I have a windows machine running an AMD 6900XT which I'm using to try and optimize my AMD cards in the Linux rig. I just realized the the GPU and Memory stats are missing from the display (happens with HiveOS). Here is my HiveOS GUI for the reference values: Not bad , what cuda and drivers do you use ? 11.5 ? Or 11.4 ? |
|
|
|
I am leaving the house now and can continue testing tomorrow.
Thanks for support!
TeamBlackMiner_1_44_cuda_11_6_beta6.7z The dag is taking 10 seconds on the 3070 Mobile in 1-44 beta 6 with --dagintensity 1. I am able to run stable on higher memclocks My observations for almost a day of mining on a 12x3080 no LHR rig. 1. If you are using Hive OS, use cuda 11.4, 11.5 gives a slight drop in hashrate. 2. I tried all the cores of the miner, the core does not automatically set correctly in Hive OS (1.42 core 1, 1.43 core 3). You must manually set the sign from 6 to 8 if you use 1.42 and 12-15 if use 1.43 20xx 30xx series of cards. 3. It makes no sense to set the core clock above 1440, it does not give any performance, it only increases the temperature of the cards and power consumption. This only works on older cards like 1070, 1080, 1080 Ti with gdd5 memory. On cards with GDDR 6-6X memory, the core does not participate in ETH mining and there is NO point in increasing it! I tested the range from 1200 to 1600, anything above 1440 gives a drop in hashrate. 4. Option --xintensity , you need to select individually, for example, it works better for me on 8100 than on 4096. Bugs that I found, on a rig with 13 video cards 3090x2 3080x7 3070 x4 NO LHR, I could not achieve stable operation, constant dag generation errors and a lot of invalid shares. Also, a 12x3070 NO lhr rig gives errors during dag generation, option --dagintensity 1 is always on. Wishes, you should conduct detailed tests under HIVE OS, mining on Windows is extremely inconvenient and not popular. Big miners don't use Windows. Improve stability and fix core map definition. I will continue to test it on different rigs to find bugs and errors in the hive, as well as to find the optimal settings. I've extensively tested TBM with an RTX3090 and can conclusively say that setting the core clock above 1440 does make a difference, especially in a windows environment. setting core clock is the only way we have to set the voltage of the cards in Linux, and 1650 for the GPU sets the voltage to 0.78 which is the sweet spot for the 3090 with a high xintensity value. I've tested 1500, 1550 and 1600 and the only way I've been able to obtain 135+ MH/s at-pool hashrate is by being at 1650 -- I will provide one caveat on those numbers, is that the testing was done on versions 1.24 to 1.28, afterwards I stopped because I was happy with the performance, and the later versions focused on LHR, which for some reason had a negative effect on the non-LHR cards until this last release. Version 1.27 was where I was able to achieve the highest rates on my 3090, and version 1.41 is where the AMD cards started to achieve 66+ MH/s under windows and 65+ under HiveOS. OK, I think you use it now ? Can you show your up time in hive os ? |
|
|
|
a lot of invalid shares.
i use --tweak / -u [6] and work better to reduce than w/o --tweak / -u What is your up time ? With tweak ? |
|
|
|
I am leaving the house now and can continue testing tomorrow.
Thanks for support!
TeamBlackMiner_1_44_cuda_11_6_beta6.7z The dag is taking 10 seconds on the 3070 Mobile in 1-44 beta 6 with --dagintensity 1. I am able to run stable on higher memclocks My observations for almost a day of mining on a 12x3080 no LHR rig. 1. If you are using Hive OS, use cuda 11.4, 11.5 gives a slight drop in hashrate. 2. I tried all the cores of the miner, the core does not automatically set correctly in Hive OS (1.42 core 1, 1.43 core 3). You must manually set the sign from 6 to 8 if you use 1.42 and 12-15 if use 1.43 20xx 30xx series of cards. 3. It makes no sense to set the core clock above 1440, it does not give any performance, it only increases the temperature of the cards and power consumption. This only works on older cards like 1070, 1080, 1080 Ti with gdd5 memory. On cards with GDDR 6-6X memory, the core does not participate in ETH mining and there is NO point in increasing it! I tested the range from 1200 to 1600, anything above 1440 gives a drop in hashrate. 4. Option --xintensity , you need to select individually, for example, it works better for me on 8100 than on 4096. Bugs that I found, on a rig with 13 video cards 3090x2 3080x7 3070 x4 NO LHR, I could not achieve stable operation, constant dag generation errors and a lot of invalid shares. Also, a 12x3070 NO lhr rig gives errors during dag generation, option --dagintensity 1 is always on. Wishes, you should conduct detailed tests under HIVE OS, mining on Windows is extremely inconvenient and not popular. Big miners don't use Windows. Improve stability and fix core map definition. I will continue to test it on different rigs to find bugs and errors in the hive, as well as to find the optimal settings. |
|
|
|
If the dag fail to verify try -K 1 (--dagintensity 1). Did you try the v1.43 build yet? I have added 7 cuda kernels that could work better on lower TDP settings (power).
--kernel can now take a value from 0 to 15
But run it in autotune mode first and check the results
I use dag intensity 1 , on all rigs in test , but on rigs with 12x3070 and 12x3060ti it is unstable , maby you must do it option maximum slowly for rtx 30xx series, or do option dag repair, like LoL miner . if you do this , I can test it on all my rigs , I have above 6 ghs. Then I posted result to the other user , I think it can help many people , who want use you miner . |
|
|
|
Did you try to optimize the code to speed things up during mining? I suspect it goes kind of "out of sync" at times
The ethproxy protocol need the full hash sent to the pool, this is calculated with the CPU. I see that other miningsoftware have moved the cpu verification and submit code to it's own thread. This might help abit. TBMiner is not working good on low difficulty pools because of this. my experience , in hive os 12x 3080 no lhr , the fastest core is 1 , 495.46 cuda 11.5 drivers give less performance than cuda 11.4 . You should do detailed tests in hive os and improve stability, some rigs keep getting errors while generating dag file. Manipulations with the kernel and pl do not give much change. I am attaching a screenshot of the 5 hour test.  |
|
|
|
In Hive OS, it always sets kernel 1 automatically
Make sure that -J 1 is not passed. The program should autotune, or you can set -J -1 to force autotune. I tried kernels from 5 to 8 - they work poorly, very few shares are found.
On windows and cuda 11.5 kernel 5-8 gives the best results on RTX cards. The next version will have 16 kernels to try to improve the performance on low power. You need to find out why your cards in the rig is using 168- 241 watt. Cards seems to trottle. (downclock and perform poorly) They need to run at the same wattage all the time. Did you manage to run them in p0 state? v1.42 windows 11.5 build Kernel 1 RTX 2060 31 MHASH Kernel 8 RTX 2060 33.5MHASH (but needs more power) v1.43 will be released in a few hours. I use P0 , tbm 1.42 cuda 11.4 , on cuda 11.5 I have worse results . video cards do not throttle, core frequencies do not drop off, this is out of the question. raising the power does not give an increase in hashrate, ethereum mining does not need a high core value, it only uses memory.  |
|
|
|
Added 2x 3080 LHRs to my setup and was hoping to get a stable hash rate on the cards.
Any tips or options to add as a starting point?
On windows I use 75% powerlimit and low coreclock as possible on the 3080ti. No need to lock the clock. If the card fail to unlock try with -1, -2, -3, -4 ... etc until it's stable. --lhr-unlock [-1,-1,0,0,0,0]  In Hive OS, it always sets kernel 1 automatically, on any settings, this kernel shows the best result in terms of hashrate, I tried kernels from 5 to 8 - they work poorly, very few shares are found. My result in 1 hour 15 minutes, until I see no increase even to the declared hashrate is not close ...... I continue the test further .... |
|
|
|
You are locking the coreclock at 1250, you probolby need to increase it to 1500 or something. The watt on the card is unstable which indicate trottleing. The memory temp could be too high or power too low.  dont work my friend......... Maybe need to enable P0 mode? |
|
|
|
After 2 minutes, the hashrate dropped again, but still more than cuda 11.5  with 13 cards you should get at least 1404 in the miner window on optimal settings. 108MHASH each. But perhaps you are running in powersaver mode.  |
|
|
|
Cuda 11.4 RTX 3080 110.5mh
Now you need to find the correct intensity for your rig so that the mining speed is reflected poolside. When you are done you will understand why alot of miners have switched. AMD/NVIDIA. Try to combine high --xintenity with --tweak --kernel . The defaults will probably not work optimal.  After 2 minutes, the hashrate dropped again, but still more than cuda 11.5 |
|
|
|
I tried on 2miners , on a 12x3080 rig, Hive OS cuda 11.5 driver 495.46 cuda 8 xint 3108 , I have 1321mh in the miner window. Average per pool per day 1.24 ghs. It works well for the first hour, then it starts to fall behind. I can put it for you again for a test for a day, so that you can be convinced of this yourself. Maby in hive i must use 11.4 cuda , i dont know, but it not work ....
Try v1.42 cuda v11.4 build. 11.5 might have issues. As reported in the previous post. 3108 might not be the optimal config for your rig. This setting works good on 1 rtx 3090. Cuda 11.4 in the miner immediately increase in hashrate Cuda 11.5 RTX 3080 102.5mh Cuda 11.4 RTX 3080 110.5mh Apparently the libraries and compatibility of the miner in HIVE OS with cuda 11.5 are at a low level and the miner does not work correctly. |
|
|
|
I spent about 4 days on tests,
Which version did you test. Which mining pool did you test? Let it run for 5000 shares. TBM should be faster if you configure it correctly.. What speed are you getting in the miner window. Screenshots please. I tried on 2miners , on a 12x3080 rig, Hive OS cuda 11.5 driver 495.46 cuda 8 xint 3108 , I have 1321mh in the miner window. Average per pool per day 1.24 ghs. It works well for the first hour, then it starts to fall behind. I can put it for you again for a test for a day, so that you can be convinced of this yourself. Maby in hive i must use 11.4 cuda , i dont know, but it not work .... Now I will turn it on on cuda 11.4 And I will throw off the test result in 2-3 hours here. Cuda 11.5 doesn't work on Hive os, probably because autotuning always chooses core 1 for my cards on any settings. |
|
|
|
I don't know if anyone else here is running a 3090 / 2060S / AMD 6-series type combo (or a non-lhr Nvidia AMD mix), but it seems to me that in linux (HiveOS ubuntu variant anyway), that the CUDA 1.15 driver (495.46) _REALLY_ nerfs performance, and I'm wondering if anyone is seeing that as well. With my 3090 under TBM 1.42 for CUDA 1.14 I am seeing 145 - 160 MH/s, but with 1.42 CUDA 1.15 I am seeing 128 - 133 MH/s. With my 2060S under 1.14 I see 43 - 45 MH/s, but with 1.15 the best I saw was 37 MH/s. Now some notes on that 3090; it's running in a semi-insulated environment and with the temperatures being about -18 degrees Celsius right now, I can clock the memory up to 11375 without any crashes, and the GPU is running at about 23 degrees (memory is probably in the mid 40's but I'm guessing based on previous ratios I have from windows readings since linux doesn't provide memory temps on Nvidia cards), so I am able to push this beyond the normal speed just due to it being damned cold. So, does anyone else have this experience with the 1.15 CUDA implementation in the 495.46 Linux drivers? TBM 1.42 @1.14 CUDA https://imgur.com/a/EEFk3RfTBM 1.42 @1.15 CUDA https://i.imgur.com/xddqbko.pngHello, I tried this miner with different settings with different driver versions in Hive os, left it for a day, but G miner on a similar rig from 12 x 3080 always gives more. I don't know how to set it up and I haven't really seen anyone who was able to consistently get a good result on it. At first it gives good speed, but after a couple of hours Gminer overtakes it even without a stail share, so draw your own conclusions.......Maybe there are some miracle settings that I don’t know about, but it loses outright to other miners. All these photos with measurements on 1 card for an hour are not a test, but prophonation. I tested it on 2 identical rigs and it loses outright ..... There are no miracles and fairy tales)))) I spent about 4 days on tests, but I could not achieve at least an equal result with Gminer. I tested all the cores and xintensity from 1124 to 9000. I installed different drivers cuda 11.5 -11.4, but there was no result. Only once I managed to get an increase on the pool, but it lasted for an hour, I think it was just luck, then Gminer went ahead by about 30-40 shares per hour. Maybe on AMD it gives an increase, but on NVIDIA it is useless. |
|
|
|
I have bad eanglish , it's a secret? I want use you miner, but don't understand, core clock musbe low or higher? Now I use 1440 on hive , on g miner I use 1100
No he posted in a public thread on reddit. Memclock higher. I think he had modified the cooler on the memory so that it could be clocked higher. I am unable to find the post now. A few months back. But TBM works better on 2miners than on ezil.me. On 2miners you can use --xintensity 3000 to 5000 without stale shares or rejects. (every share payed). On ezil good like 2 miners |
|
|
|
What settings do u use , core clock and memory ? And kernel ?
The record result was posted by a reddit user, the clocks and settings are hidden in one of the Team Black Miner threads there. I have bad eanglish , it's a secret? I want use you miner, but don't understand, core clock musbe low or higher? Now I use 1440 on hive , on g miner I use 1100 I run 2 hours , then restart , and kernel now 1 . |
|
|
|
|
