Topic: [ANN] TeamRedMiner - Optimized Win/Linux AMD GPU Miner for lyra2z and phi2 - page 19. (Read 85791 times)

Does anyone know if there is a miner watchdog script available here or are people basically writing there own?

If a miner truly requires full GPU mem page file, you would want what I wrote as the first option: total GPU mem size (all GPUs mem combined) + 4GB (for system).  Are you sure Claymore really required that tho - I'm betting that was the requirement when GPU mem was limited to 2 or 3GB - when you're getting up to 8GB, I'm not sure it's necessary anymore.   If it really is due to DAG size, then 3GB per GPU should be enough through at least mid-2019.

I know with Ethash on Claymore it ‘requires’ a page file at least equal to total GPU memory, so for 6 8GB Vega 64s that’s 48GB, maybe due to DAG file size.

But my question here is/was does this miner “require’ some amount of page file? Because I’m sizing my drives based on this.

I think I answered it though, basically, no. I switched over to this miner (Lyra2rev3) keeping my old ethash/claymore page file size (48GB), then switched it to system managed size (which ended up being much smaller) and have seen no issues or reduction in HR.

Total GPU mem size + 4GB should be more than enough for any algorithm - so 36GB should be enough for your 4 vega rig.  Really, 4GB * num GPUs + 4GB (system) should be plenty in most cases.



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.



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.) 

You are right. Did a self-test and was surprised

Played a bit around and ended up with nearly same settings as yours. Everything above 110 MH/s will be less stable in the long run.

My page file is set on 64GB for my 4 Vega 64 rig. I have absolutely no problem with this or any other miner.




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.

Hello, does anyone know if this miner on Win10 requires a large page file like some other miners with other algos?

I do not have Vegas (ive 4x RX580), but I really appreciate your post: Configuration, step by step, captures, ... very complete!

Thanks for the tipp, my last try, I will increase the voltage again and test the setup.

Stay tuned.

Your card runs in P7, not P2/3. And I think you will consume more Watt at the wall in P7 than just 200.

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/6RkwHNB

That 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/1TV7JWj

All 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.

Well I feel dumb... 😳 thanks for the info

https://bitcointalksearch.org/topic/m.49799677

Five posts above this.

What do you mean exactly, should I set the clocks to P4 level? I tried this already, no solution.

Radeon VII support any time soon? Not sure what happened to my earlier post asking this.

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.

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.

My friend, maybe you shouldn't waste too much time on Monerov8 with the imminent fork... Your efforts would probably be better spent on the new algo... and that other family of algos I believe I have mentioned to you a couple of times in the past...

It’s only an init thing, we have a somewhat special init procedure compared to other miners. When the gpu miner is running you should be able to start and run the cpu miner just fine.

Also, I think it could work if you give the gpu miner highest or real-time priority as well.

I have ran TRM on Radeon VII, but we need to release a new version that recognizes the new device string. Also, ROCm is a little messier than Windows and amdgpu-pro. We will try to get that out shortly. However, CN will need to be optimized for the VII, the current kernels run ok but not optimally. That will most probably not be included in a first release supporting Radeon VII.