 Show Posts
|
|
Pages: [1]
|
Team Red Miner v0.5.7 releasedhttps://github.com/todxx/teamredminer/releasesChanges in v0.5.7 - Added CN conceal algo for Conceal (CCX).
- Added cuckarood29 algo for grin.
This release brings a couple new algos: CN conceal and cuckarood29! CN conceal is a bit picky about memory timings, so please checkout the CN_MAX_YOU_VEGA.txt doc before switching your rigs to it. My 4 x Vega 64 are mining at 4.5kH/s each. Settings like on CNR. "Cool" algo in terms of power and temps. |
|
|
|
When I try to mine GENX using command line, I get following output: "Warning: No user profile defined in command line (--profile <profileName> missing) Using only DEFAULT section and command line input Reading pool data from command line Error: No coin profile find for coin GENX " From user manual, I thought GENX can be mined that way I have the same problem. It started from v 0.7.0. Worked fine on 0.6.0. Please fix it. |
|
|
|
@todxx, Hello, When will TRM support turtle's new algo "chukwa" and loki's new algo "RandmXL"?
Hi! We're currently working on other algos. For Turtle, we might take a swing at chukwa at some point. For Loki, and any other RandomX-derived algo, I don't see us spending the time, there's no point producing gpu code that no one would run. Rondom X will be used by many coins: Monero; Graft (GRFT) is considering, Triton-SAO (XTRI) is considering and others will follow. For Turtlecoin and its algo, it shouldn't be forgotten that TRTL is the 3rd most forked CN coin (After Bytecoin and Monero), so smaller projects should also adopt chukwa. Unfortunately, the nr of projects using an algo is irrelevant when the returns on a Vega 64 are -90% of a Ryzen 3900x, and just wait for the next gen Threadripper... Instruction caches are blown up, SIMD parallelism is close to impossible to utilize, caches are much too small to support the chosen L1/L2/L3 hierarchy, just to mention three major mismatches between the algo and how a GPU is constructed. People need to stop dreaming about RandomX on gpus. Not even starting to consider GPU for Random-X, maybe I confused you. My bads. Point is, integrate Random-X fur CPUs because a lot of projects will switch to it. That could be a major improvement in TeamRedMiner functionality. Joined mining CPU-RandomX and GPU-Grincuckatoo31 or CPU/GPU UPX2 mining since I think for now the most profitable CPU algo. I bet there is a room for improvement over xmrig-upx. |
|
|
|
Team Red Miner v0.5.5 releasedhttps://github.com/todxx/teamredminer/releasesChanges in v0.5.5 - Added cuckatoo31 algo for grin.
We've added cuckatoo31 for grin mining! Seems we might have been a bit late as asics are might already be here for the algo  . What is average hashrate on Vega 64? |
|
|
|
Team Red Miner v0.4.4 releasedhttps://github.com/todxx/teamredminer/releasesChanges in v0.4.4 - Added * mode specifically for modded timings on Vega GPUs. Use with e.g. --cn_config=15*15. This mode is now the default for Vegas.
- Introduced slow start/ramp-up. Threads increase their workload slowly at start or restart after e.g. a network outage.
- Added interleave adjustment logic. Readjusts the two threads per gpu over time to make sure they don't gravitate and get stuck.
- Added support for forcing colors (--force_color) for windows redirected consoles (git bash, cygwin, node.js).
- Added hotkey menu system (show stats, enable/disable gpu).
The new * mode opens up tweaking Vega timings for 2MB CN algos like CN-R! We've seen a few extremely tuned V64 LCs able to hit over 2400h/s on CN-R with 1400/1100 clocks! For those of you playing with timings, please share your results! We love seeing how far you guys can push these cards  Setting L22*22 on my Vega 64 just decrease hashrate in CN_Turtle. On L22*22 I got 20.26kH/s and on L22+22 21.80kH/s on this timings: --CL 19 --RAS 30 --RCDRD 12 --RCDWR 6 --RC 44 --RP 13 --RRDS 5 --RRDL 5 --RTP 4 --FAW 18 --CWL 6 --WTRS 4 --WTRL 9 --WR 15 --WRRD 1 --RDWR 18 --REF 12800 --RFC 248 CNR 15*15 2375h/s CNR 14*16 2385h/s Vega set at: 1400@900 1007@900. Thanks for testing and reporting! Should have been better described: the *-mode is for the 2MB variants, not for turtle. Turtle doesn’t need any tweaks, it puts max load on the mem controller anyway. Using this timings: --RAS 28 --RCDRD 12 --RCDWR 5 --RC 44 --RP 10 --RRDS 3 --RRDL 3 --RTP 5 --FAW 20 --CWL 7 --WTRS 4 --WTRL 9 --WR 16 --WRRD 1 --RDWR 19 --REF 12800 --MRD 8 --MOD 15 --PD 8 --CKSRE 10 --CKSRX 10 --RFC 250 CNR: 14*16 2430h/s One error previously: Vega set at 1400@900 and 1107@900 |
|
|
|
Team Red Miner v0.4.4 releasedhttps://github.com/todxx/teamredminer/releasesChanges in v0.4.4 - Added * mode specifically for modded timings on Vega GPUs. Use with e.g. --cn_config=15*15. This mode is now the default for Vegas.
- Introduced slow start/ramp-up. Threads increase their workload slowly at start or restart after e.g. a network outage.
- Added interleave adjustment logic. Readjusts the two threads per gpu over time to make sure they don't gravitate and get stuck.
- Added support for forcing colors (--force_color) for windows redirected consoles (git bash, cygwin, node.js).
- Added hotkey menu system (show stats, enable/disable gpu).
The new * mode opens up tweaking Vega timings for 2MB CN algos like CN-R! We've seen a few extremely tuned V64 LCs able to hit over 2400h/s on CN-R with 1400/1100 clocks! For those of you playing with timings, please share your results! We love seeing how far you guys can push these cards Setting L22*22 on my Vega 64 just decrease hashrate in CN_Turtle. On L22*22 I got 20.26kH/s and on L22+22 21.80kH/s on this timings: --CL 19 --RAS 30 --RCDRD 12 --RCDWR 6 --RC 44 --RP 13 --RRDS 5 --RRDL 5 --RTP 4 --FAW 18 --CWL 6 --WTRS 4 --WTRL 9 --WR 15 --WRRD 1 --RDWR 18 --REF 12800 --RFC 248 CNR 15*15 2375h/s CNR 14*16 2385h/s Vega set at: 1400@900 1007@900. |
|
|
|
This is by far the best settings I tired. 4x Vega 64 with waterblocks. Core 1300@0.950V and 1100@0.95V Normally it was 19.24kH/s/Vega. After the timing set is about 21.85kH/s/Vega. Max temps: Core 40*C, HBM mem 53*C. Team Red Miner v0.4.3 L22+22. HWinfo GPU chip power 157W. I don't have a power meter. almost 4h no errors. https://ibb.co/R7CWKjwvega64 lc is happily mining 21.2kh/s with 1230/1090@800mv showing only 115 watt in HWinfo GPU chip power I will get to that eventually. For now I'm testing other settings. On normal timings the best intensity was L24+24. at the same core/mem freq I had consistent 19,24kH/s on all cards +-0.05kH/s. On new timings this intensity was not that stable. After that L22+22. After 4,5h of hashing first HW error showed up and speed was 21.85 kH/s but with the spread od 0.4kh/s betwen cards. After that I have tested L20+20 but that was ruled out because of decrease in hashrate of about 0.5kH/s/cards. Now I'm using L18+18 and got result of 21.83 kH/s +-0.03kH/s between cards. Using Adrenalin 19.4.1. |
|
|
|
Hi Guys,
Zorg33 said to me share this set, because it's impossible, but working good for me:
--CL 12 --RAS 28 --RCDRD 12 --RCDWR 5 --RC 44 --RP 10 --RRDS 3 --RRDL 3 --RTP 5 --FAW 20 --CWL 7 --WTRS 4 --WTRL 9 --WR 16 --WRRD 1 --RDWR 19 --REF 17550 --MRD 8 --MOD 15 --PD 8 --CKSRE 10 --CKSRX 10 --RFC 250
Vega56 @ 64 sapphire samsung ram, Win10, 18.6.1 and 18.5.1 classic 1408/900core 1100/900mem
Turtle 22+
ETH 51+
Cr-Lite 10K khs (1600/990 1100/900, but crashed, 9600kh 1408/900 1100/900 super stable after 24h)
This is by far the best settings I tired. 4x Vega 64 with waterblocks. Core 1300@0.950V and 1100@0.95V Normally it was 19.24kH/s/Vega. After the timing set is about 21.85kH/s/Vega. Max temps: Core 40*C, HBM mem 53*C. Team Red Miner v0.4.3 L22+22. HWinfo GPU chip power 157W. I don't have a power meter. almost 4h no errors.  <a href=" https://ibb.co/R7CWKjw"><img src=" https://i.ibb.co/t3b56Lr/Vega.jpg" alt="Vega" border="0"></a><br /><a target='_blank' href=' https://pl.imgbb.com/'>prywatne serwery plemiona</a><br /> You would be using a lot of power. You should be able to drop your core and voltage a lot. 950mv is soo high for 1300 core. You're right, but for now I would like to test this settings for a while and than I will decrease voltage. However I did observe some stability issue at 0.900V but it was at different timings an on LC bios which I found to be not very good for low power tuning. |
|
|
|
Hi Guys,
Zorg33 said to me share this set, because it's impossible, but working good for me:
--CL 12 --RAS 28 --RCDRD 12 --RCDWR 5 --RC 44 --RP 10 --RRDS 3 --RRDL 3 --RTP 5 --FAW 20 --CWL 7 --WTRS 4 --WTRL 9 --WR 16 --WRRD 1 --RDWR 19 --REF 17550 --MRD 8 --MOD 15 --PD 8 --CKSRE 10 --CKSRX 10 --RFC 250
Vega56 @ 64 sapphire samsung ram, Win10, 18.6.1 and 18.5.1 classic 1408/900core 1100/900mem
Turtle 22+
ETH 51+
Cr-Lite 10K khs (1600/990 1100/900, but crashed, 9600kh 1408/900 1100/900 super stable after 24h)
This is by far the best settings I tired. 4x Vega 64 with waterblocks. Core 1300@0.950V and 1100@0.95V Normally it was 19.24kH/s/Vega. After the timing set is about 21.85kH/s/Vega. Max temps: Core 40*C, HBM mem 53*C. Team Red Miner v0.4.3 L22+22. HWinfo GPU chip power 157W. I don't have a power meter. almost 4h no errors. https://ibb.co/R7CWKjw |
|
|
|
Ok lets start from a beginning.
Clocks. 1530@1050V and 1100@1050. Works great on CNv8 with 15+14. 2050h/s. Cards are on water.
On the same clocks on CNR and those crashes. On 13+12 works with bad hashrate reporting. At that settings and 18.6.1 driver I have 36*C on the core and 155W of power.
I also use this miner for Lyra2rev3 with 108Mh/s per cards with no problem for weeks.
So NO, this is not the problem with voltage/clocks setting.
Every algo creates a different load signature, which can require different clock/voltage settings. Just because some combo of settings worked for some other algo, doesn't mean it will work here. Though it does appear the settings should be close to cnv2.
What about the bad hashrate rapport? This is voltage/clocks setting issue to?
Absolutely - I've seen the same behavior, in many different miners, for many different algos. Just now, in linux, I experienced a 2700H/s report from TRM stemming from a too extreme uv. Yes, the combo of clocks and algo is the key metric. The issue with this algo is the random code (re)generation. Since we build our kernels in asm, we don't recompile like the other miners, we solve this in a different way. In turn, this means this kernel gets a very different load footprint in one specific way. @wacholek: we've also done some extensive host-side changes in this release, so can you verify that CNv8 and lyra2rev3 runs just as good as before with _this_ version, not 0.3.8 or 0.3.9? Would be great data to have to fix things. Also, I remember you running some custom mod for water, but what OS and driver are you running? System Win10. 4 x Vega 64 wit LC bios on water. Lyra2Rev3 1500@950 1100@945 On v0.3.10 429.8Mh/s ; On v0.4.0 435.7Mh/s. Very good. Hashrate and avr Hashrate the same. Good work!!! I will test CNv8 later. |
|
|
|
Team Red Miner v0.4.0 releasedhttps://github.com/todxx/teamredminer/releasesChanges in v0.4.0 - Added cryptonight R support. (--algo cnr)
- Added support for ssl/tls pool connections using the stratum+ssl:// prefix.
- Added colors (and an option to disable them).
- Slight performance increase for lyra2rev3 (~0.5%).
- Fix for occasional crashes when pool disconnects.
- Added more messages regarding not being connected to dev pool.
- Changed printing to not block mining progress if stdout writes block.
A bit delayed with this post, but better late than never. The main change in this version is the addition of CN/R support. Performance of CN/R is roughly the same on Vegas as cnv8. Polaris cards are a bit slower with larger cards losing about 0.5% and the smaller cards like rx550s losing ~1.5%. Power for CN/R is up by 2-3% compared to cnv8. Also we've added some user requested features like colors and support for ssl pool connections. Hi, I have problem with Vega and CryptonightR. Intensity set to 12+11. (14+14, 14+13 hangs my cards) And I have this results: [2019-03-09 11:10:54] Stats Uptime: 0 days, 00:09:01
[2019-03-09 11:10:54] GPU 0 [34C, fan 0%] cnr: 2.811kh/s, avg 1.403kh/s, pool 2.235kh/s a:5 r:0 hw:0
[2019-03-09 11:10:54] GPU 1 [34C, fan 0%] cnr: 2.825kh/s, avg 1.413kh/s, pool 2.982kh/s a:7 r:0 hw:0
[2019-03-09 11:10:54] GPU 2 [29C, fan 0%] cnr: 2.800kh/s, avg 1.399kh/s, pool 1.491kh/s a:3 r:0 hw:0
[2019-03-09 11:10:54] GPU 3 [31C, fan 0%] cnr: 3.053kh/s, avg 1.523kh/s, pool 0.0 h/s a:0 r:0 hw:0
[2019-03-09 11:10:54] Total cnr: 11.49kh/s, avg 5.739kh/s, pool 6.708kh/s a:15 r:0 hw:0
[2019-03-09 11:11:10] Shutting down...
[2019-03-09 11:11:11] GPU 2 CN thread 1 exiting.
[2019-03-09 11:11:11] GPU 3 CN thread 0 exiting.
[2019-03-09 11:11:11] GPU 0 CN thread 1 exiting.
[2019-03-09 11:11:11] GPU 1 CN thread 1 exiting.
[2019-03-09 11:11:20] GPU 0 thread 0 shutdown timed out.
[2019-03-09 11:11:20] GPU 1 thread 0 shutdown timed out.
[2019-03-09 11:11:20] GPU 2 thread 0 shutdown timed out.
[2019-03-09 11:11:20] GPU 3 thread 1 shutdown timed out. 1. 2.8kh/s is rather high. Avarage is a half of this. Intensity 13+12 [2019-03-09 11:21:02] GPU 0 [ 0C, fan 0%] cnr: 3.060kh/s, avg 1.525kh/s, pool 1.579kh/s a:2 r:0 hw:0
[2019-03-09 11:21:02] GPU 1 [ 0C, fan 0%] cnr: 3.072kh/s, avg 1.531kh/s, pool 1.579kh/s a:3 r:0 hw:0
[2019-03-09 11:21:02] GPU 2 [ 0C, fan 0%] cnr: 3.044kh/s, avg 1.517kh/s, pool 395.0 h/s a:1 r:0 hw:0
[2019-03-09 11:21:02] GPU 3 [ 0C, fan 0%] cnr: 3.050kh/s, avg 1.520kh/s, pool 2.371kh/s a:4 r:0 hw:0
[2019-03-09 11:21:02] Total cnr: 12.22kh/s, avg 6.093kh/s, pool 5.923kh/s a:10 r:0 hw:0
2. I have trouble with shutdown. After that I have to force miner to close the window. Hi! Like other people just noted, I believe this is related to your clocks. Intensity 12+12 will still have enough pads running to put load on the gpu. CN/r is yet another different beast than CNv8, those random ops are a heavy workload with a lot of muls. One of your threads per gpu has crashed in all cases above, you can tell from the timeouts when exiting. I've tested all my Vega 64 LC and Vega 56s at old school CN clocks (1408@900, 1100@900, 56s flashed to 64 bios), and have ran successfully for extended periods without issues. What environment (OS, driver) are you using, and what Vegas are these? Ok lets start from a beginning. Clocks. 1530@1050V and 1100@1050. Works great on CNv8 with 15+14. 2050h/s. Cards are on water. On the same clocks on CNR and those crashes. On 13+12 works with bad hashrate reporting. At that settings and 18.6.1 driver I have 36*C on the core and 155W of power. I also use this miner for Lyra2rev3 with 108Mh/s per cards with no problem for weeks. So NO, this is not the problem with voltage/clocks setting. What about the bad hashrate rapport? This is voltage/clocks setting issue to? |
|
|
|
Team Red Miner v0.4.0 releasedhttps://github.com/todxx/teamredminer/releasesChanges in v0.4.0 - Added cryptonight R support. (--algo cnr)
- Added support for ssl/tls pool connections using the stratum+ssl:// prefix.
- Added colors (and an option to disable them).
- Slight performance increase for lyra2rev3 (~0.5%).
- Fix for occasional crashes when pool disconnects.
- Added more messages regarding not being connected to dev pool.
- Changed printing to not block mining progress if stdout writes block.
A bit delayed with this post, but better late than never. The main change in this version is the addition of CN/R support. Performance of CN/R is roughly the same on Vegas as cnv8. Polaris cards are a bit slower with larger cards losing about 0.5% and the smaller cards like rx550s losing ~1.5%. Power for CN/R is up by 2-3% compared to cnv8. Also we've added some user requested features like colors and support for ssl pool connections. Hi, I have problem with Vega and CryptonightR. Intensity set to 12+11. (14+14, 14+13 hangs my cards) And I have this results: [2019-03-09 11:10:54] Stats Uptime: 0 days, 00:09:01
[2019-03-09 11:10:54] GPU 0 [34C, fan 0%] cnr: 2.811kh/s, avg 1.403kh/s, pool 2.235kh/s a:5 r:0 hw:0
[2019-03-09 11:10:54] GPU 1 [34C, fan 0%] cnr: 2.825kh/s, avg 1.413kh/s, pool 2.982kh/s a:7 r:0 hw:0
[2019-03-09 11:10:54] GPU 2 [29C, fan 0%] cnr: 2.800kh/s, avg 1.399kh/s, pool 1.491kh/s a:3 r:0 hw:0
[2019-03-09 11:10:54] GPU 3 [31C, fan 0%] cnr: 3.053kh/s, avg 1.523kh/s, pool 0.0 h/s a:0 r:0 hw:0
[2019-03-09 11:10:54] Total cnr: 11.49kh/s, avg 5.739kh/s, pool 6.708kh/s a:15 r:0 hw:0
[2019-03-09 11:11:10] Shutting down...
[2019-03-09 11:11:11] GPU 2 CN thread 1 exiting.
[2019-03-09 11:11:11] GPU 3 CN thread 0 exiting.
[2019-03-09 11:11:11] GPU 0 CN thread 1 exiting.
[2019-03-09 11:11:11] GPU 1 CN thread 1 exiting.
[2019-03-09 11:11:20] GPU 0 thread 0 shutdown timed out.
[2019-03-09 11:11:20] GPU 1 thread 0 shutdown timed out.
[2019-03-09 11:11:20] GPU 2 thread 0 shutdown timed out.
[2019-03-09 11:11:20] GPU 3 thread 1 shutdown timed out. 1. 2.8kh/s is rather high. Avarage is a half of this. Intensity 13+12 [2019-03-09 11:21:02] GPU 0 [ 0C, fan 0%] cnr: 3.060kh/s, avg 1.525kh/s, pool 1.579kh/s a:2 r:0 hw:0
[2019-03-09 11:21:02] GPU 1 [ 0C, fan 0%] cnr: 3.072kh/s, avg 1.531kh/s, pool 1.579kh/s a:3 r:0 hw:0
[2019-03-09 11:21:02] GPU 2 [ 0C, fan 0%] cnr: 3.044kh/s, avg 1.517kh/s, pool 395.0 h/s a:1 r:0 hw:0
[2019-03-09 11:21:02] GPU 3 [ 0C, fan 0%] cnr: 3.050kh/s, avg 1.520kh/s, pool 2.371kh/s a:4 r:0 hw:0
[2019-03-09 11:21:02] Total cnr: 12.22kh/s, avg 6.093kh/s, pool 5.923kh/s a:10 r:0 hw:0
2. I have trouble with shutdown. After that I have to force miner to close the window. |
|
|
|
Core clock is adjusted based on voltage + load. At idle, (assuming lower p states disabled,) you will see core clock at/near what you set. While mining, it will depend on the miner load signature - some algos will tax the core more than others, causing more of a clock throttle if you're significantly undervolted. This is all independent of other state settings (i.e. it is not related to P3.) Also, this only happens when ACG is engaged, which *should* only be for P5,6,7. In linux, you can step down to P4 to avoid this throttling, while in Windows, I have been unsuccessful in such attempts.
Generally I agree. However core freq throttling is also dependent what core voltage you set even if the card is in idle state. When I was mining CNv8 ( which is not so core intensive algo) I set 1.100V because I could not get 1660Mhz on the core. Than my P7 state was set @ 1750Mhz (defult for LC). On this algo I was at 180W. On idle (no miner load) clock was as I set 1750Mhz. On Lyra2rev3 core power is the main issue so on my settings I have 0.950V on load @ 1500Mhz and 1.000V @1600Mhz on idle. And that is with P7 set @ 1700Mmhz. So Vega is throttling even on idle if you set very low core voltage. I always use my Vegas with only P7 enable. I found that more stable when some network problems or pool problems occurs. All above is more like a guide how to set your Vega, not a ready recipe. I can't speak definitively to lyra2rev3 performance, as i have yet to benchmark, but with every other algo i've run, i've found Vegas to become increasingly inefficient above 1400Mhz (actual) / ~175w (at the wall.) If you're just out for raw production, and don't care about heat or the lifespan of the GPUs, then mine away at 225w or wherever you're at. Otherwise, you might want to check your hash/watt on some lower settings and compare (i usually find an 'actual' core speed of ~1300-1400Mhz to be a good spot for other algos.)
Since the biggest degradation of silicon IC's, especially for HBM, is temperature I use water to cool down that power hungry card. I have 38*C on the core and HBM under full 218W load. Try that on air. Using liquid cooling I also have higher efficiency but in my case this is completely irrelevant. |
|
|
|
Hello, does anyone know if this miner on Win10 requires a large page file like some other miners with other algos?
My page file is set on 64GB for my 4 Vega 64 rig. I have absolutely no problem with this or any other miner. Your card runs in P7, not P2/3. And I think you will consume more Watt at the wall in P7 than just 200.
It is not that simple with the P-states on Vega. Theoretically you are right. Cards is running on p7. But the core/voltage ratio is set like on P2 state. Vega sets core clock based on the core voltage. This is a major principle in all known reference Vegas. So setting core voltage on 1.2V you can do what ever you wont with the clock and set clock will be more less the same. Limit is the power. But when you set core voltage at 1.000V and clock at 1600Mhz will result only about 1300Mhz on the core because this is the clock for P3 state as default. So lower the core voltage value on P7 will result lower core clock corresponding to that voltage. In my case set 1.000V but in reality cards keeping 0.950V which results about 1500Mhz even if my P7 core clock is set to 1700Mhz. All my 4 Vegas consumes 986W of power at the wall and that include PCI-E slot power and PCI-E 2x8pin socket power. I use 2 1200W HSTNS-PD19 Platinum PSU because at that power level it is only worm and very quiet. So 214W from HWinfo is not that inaccurate since it is not at the wall power. |
|
|
|
The miner (Nicehash - lyra2rev3) crashes regularly my Vega64 and with that my rig. Some driver, voltage and clocks tested, unfortunately no change.
Other algorythm like Beam and Ethereum works quite stable about weeks.
Please fix it, the performance is incredible.
Try to run your Vega64 with P4, which gives nearly same hashrate as P7, but saves you ~50W per card. Runs 100% stable with 0 crashes. What do you mean exactly, should I set the clocks to P4 level? I tried this already, no solution. Your problems are normal because your overheating Vega on standard clocks. This algo is core-intensive so it have to be tuned carefully. I have 4 Vega's 64 LC in room temp 18*C. Configuration is very problematic and it need a lot of afford. Settings for my vegas: https://ibb.co/6RkwHNBThat sets my cards to P2/P3 (0.950V) and boost the clock up to 1500Mhz. That consumes 212W of power and give me 108Mh/s per cards. My max results where at 1.050V and 1630Mhz. Cards power where 265W and give me 120Mh/s. But those settings gave to much stress to the core and cause instability (hot spot at 70*C on water) Temps are: GPU thermal diode 38*C GPU HBM temperature 36*C GPU Hot Spot temperature 62*C https://ibb.co/1TV7JWjAll of this where my settings and works for me and I do not encourage anyone to use it. By the way. Miner 0.3.10 is rock-stable on my equipment. |
|
|
|
Did anybody try latest ethos ? It should supports vega linux overclock. ethOS 1.3.2 changelog (released July 31st 2018)
Major Changes
Added support for Radeon RX VEGA: for all miners, overclocking, reporting, and mixing RX VEGA with other RX GPUs.
Added avermore ewbf-equihash nevermore tdxminer xmr-stak xtl-stak TDX miner not working on the vega (1.3.2) Why it is not working? What is the massage? What is the clinfo response? It should work if they say so. I am only curious what is the hashrate of ta stock Vega64 on ethOS? What kernel did they use? Is it slower than on 16.04 because I'm getting 29.5Mh/s@4xVega 64. They say nothing about voltage control of a Vega. That is a pity for me. I sinuously thinking about buying this OS but without good Vega suport will be a mistake. |
|
|
|
Posting again because I guess no one else tried or reported back... Has anyone tried this it is suppose to reduce power consumption. Didn’t know if any of you would have luck with it. I tired the first suggestion without luck and was going to see if the second suggestion maybe worked by the doctor aka tekcomm. https://github.com/RadeonOpenCompute/ROCm/issues/463 The Doctor is working on that. We're all waiting for the true under voltage on all Vega rigs. |
|
|
|
looks like dev abandoned ship...
I hope not because this miner has a grate potential. There are some tweaks to be done but, as far as I know, it is the best AMD miner available. |
|
|
|
This is very interesting. I have to look into that. What was your problem with running tdxminer? Opencl problem in general. Creator of tdxminer requested testing and implementation of miner to this Linux build. We need advenced linux user to give some tip how to make it work https://github.com/tekcomm/AMD-rocm-rippa/issues/3I think the magician tekcomm already did that. But since I'm in 1% as inteligent as he is it will take days before I will sort it out. I will sort it out eventually because I am as stubborn as he is  https://github.com/tekcomm/linux-kernel-amdgpu-binaries |
|
|
|
This is very interesting. I have to look into that. What was your problem with running tdxminer? |
|
|
|
|
