Topic: SRBMiner Cryptonight AMD GPU Miner V1.9.3 - native algo switching - page 83. (Read 237247 times)

Thanks for good software!

Thanks for all the info!

You example could be written as :

{ "id" : 0, "intensity" : 60, "worksize" : 16, "threads" : 1, "target_temperature" : 90, "target_fan_speed": 2500, "off_temperature":90, "adl_type": 1}

I tested the off_temperature on on a few rigs, it was OK, but going to check again.
Edit : ok found the problem, going to fix in next version

Until then you can set "off_temperature" outside gpu_conf


For those oldies adl_type 2 should be used (in 1.7.3 it is now auto set for GCN1 cards), but to be honest i don't know if the target temperature and fan speed stuff work on those cards, i couldn't test it.

It's a bit complicated with the speeds.
I would say they definitely went up for most cards, the 270X has a massive boost, hashing now at 400H/s.
The 280X is now hashing at around 440 H/s which is also an improvement.
The 290 went down to 460H/s initially from 540H/s, but after some tweaking, it went up to 520 H/s.

I only use R9 cards with your miner, the Vegas I have are mining ETH.

There also seems to be an issue with the off-temperature
this is a config example:
{ "id" : 0, "kernel": 1, "intensity" : 60, "worksize" : 16, "threads" : 1, "double_threads" : false, "target_temperature" : 90, "target_fan_speed": 2500, "off_temperature":90, "adl_type": 1},

But the miner still switches-off the video cards at 85C.
Also, I'm not sure if the fan controls work well for Pitcairn cards, most of the time they read 0 rpm or somthing like 10000 rpm and don't seem to spin at all.

Yeah, of course i will do it!
But i am currently on the road and want to calculate how many of my Cards in my Farm could be effected :-)

Last Time, with Version 1.7.2 i think there was no difference in the 3 Versions or have i done a failure?
Can i put it also on top of the config File where the General stuff for all Cards are or have i to do it in the line for each card where i set intensitiy for each card etc???

Why don't you try and see for yourself ?
It should have effect on both cards.

IDK about Stellite fork because they still don't know, and don't have a date yet.

You are right, the whole GCN1 family is put under the same id (g9), i supposed that a pitcairn binary should work on a tahiti etc.it looks like it's not that way.
I will separate them in the next version.

Can you tell me how are speeds now with the tahiti and pitcairn, compared to other miners?

Hey Doc,

- will the different Heavy Mode (1-3) effect only 8GB or also 4GB Versions Cards?
- when will Stellite fork approximately?

Hi,

There is an issue with your miner.
The kernel cache created for the
Radeon 280X and Radeon 270X are created for monero with the same name: g9_CNV8_w16_f8_hm1_ha.srb
If you have a system which combines 280X and 270X cards, then you can't use both card, since the kernel generated for one type will fail on the other.

You should generate different kernels for the 280X and 270X. Thank you.

Hi, DOK) Thanks for the upgrade)
UPX algo, RX 480 8G, bc drivers, intens 0 - 3890H/sec (wow!!!). I'm afraid a little) Is it - OK?

Many thanks to the creator of this great miner!

hmm ok nice..

As i seen recommend 18.6.1. did not want to risk.

1 - Can i install it and mine normally without change anything in my config_?

2 - Other question dok, i notice that auto intensity from version 1.7.0 was [56] and now is [60] ,for vega 64, why such increase? is safe to maintain that?

3 - In my rigs i use winver v1709 and disable all updates. I want to use in my desktop pc one vega 64, its ok to install last winver and amd drivers with no lose in performance? in rigs im not updating anything, only for new drives if you say is safe

Many thanks for help  

What do you mean?
It works with the latest drivers also

Thanks for new version.

When could we see support for a more recent amd drivers?

Thanks

Yes, i should use font size 300, because even if there are separate sections for gpu_conf and other parameters in the readme, and on the first page, somehow people dont see it 

Thank you for the new version Dok !! 
Restores 1mb algo speeds to their original high speeds !!

For vega users :  the key word being GPU_Conf "ONLY"

V1.7.3
- Bringing back support for GCN1 cards [pitcairn, tahiti ...]
- Heavy_mode 2 is now an improved 3 with a little less hash and less errors than 3
- Small OCL optimisations for Vegas
- Added parameter 'off_temperature' to gpu_conf, to protect GPU from overheating
- Added parameter 'old_mode' to gpu_conf, which creates the kernel with the old method
- Added new algo 'Hycon'
- Added new algo 'Upx'
- Added new algo 'Stellitev8'
- Renamed algo 'freehaven' to 'swap'


+ Even if unintentionally, but SRB became slower and slower on old GCN1 cards because optimisations that were good for newer gpu's were a kill for those oldes.
I managed to borrow a tahiti card (280x) for a few days, and create a new kernel that is now working OK with these oldies. Speeds should be acceptable now

+ As you know there are 3 heavy modes available. This is how it goes now :
1. Slowest but shouldn't produce any compute errors
2. Faster than 1, it is a re-worked 3, a little bit slower than 3, but with less errors
3. The fastest but it can produce the most compute errors

I think 2 could be the winner here because my tests of 12hr show :
1. 0 errors
2. 1 error
3. 4 errors

Of course the default one is still 1, because it is the most stable mode.

+ Added a gpu_conf only parameter 'off_temperature'. I think this will be very useful. What it does is it turns off that one particular overheated GPU until it cools down by 15c, then it's turned back on.
Default is 85c, so that means if a GPU reaches 85c, miner turns it off automatically (while the other GPU's are still working), and it waits until it cools down by 15c, in this case that is 70c.
When temperature is < 70c the GPU is automatically turned back on and it continues to work.
The '15c' difference can't be changed.

+ Added a gpu_conf only parameter 'old_mode'. With the changes i made in 1.7.2, that allow the creation of kernels on drivers newer than 18.6.1, algos that use a scratchpad <=1MB (litev7, mox, dark, upx) suffer from a hashrate drop on Vegas (maybe others too, i didn't test). So if you set this parameter to true, it will create kernel the old way, and the speed on these algos should be back.
Don't forget, if you use old_mode : true, and compile the kernel on a driver newer than 18.6.1, you probably won't be finding any shares!

+ Added 3 new algos :

- upx [ https://bitcointalksearch.org/topic/dai-mainnet-upx-uplexa-ai-anonymity-and-ecommerce-via-iot-5058404 ]
- hycon [ https://hycon.io ]
- stellitev8 [ https://bitcointalksearch.org/topic/annpow-torque-decentralized-node-list-via-ipfs-zeronet-2813261 ]

Stellitev8 will be active when stellite forks.

Hi Mate!

It´s easy to find out which Card is "damaged", just go to device Manager and just activate 1 GPU Card 1 by 1 and run the miner with just 1 ID, then let run the miner.

maybe it helps. 

Greetings
Patrick

depends how the system crashed, if blue screen or freeze then you can't do much i guess.
If just a card dropped out, that will be in the log.

Hi Dok, is there any way to find out which GPU (I have mix 56's & 64's with different memories) crashed the system? I've tried searching log but can't really tell. TIA

1.7.2 is also ok, but he should use a pool with higher diff, 1000 is insanely low for 6 gpu's, he finds a ton of shares, and when new job arrives, those shares are still sent to the pool and they are stales then.
It can even happen that he gets rejects.

Just use much higher difficulty port on that pool, or a vardiff port.