SRBMiner Cryptonight AMD GPU Miner V1.9.3 - native algo switching

[StarLog]

You may have to unquarantine the files that windows defender saw. Another theory could be that you haven't configured your config file yet. One time i got stuck trying to look for the problem
until i realized i haven't added any GPU configurations to the batch file.

Anyway thank you doc for another wonderful update!
[/quote]

m.vina,

Thanks, I had the av scan turned off, before I started so don't think that was it. when I ran it first, it used the authors address, and configured the cards.
Then after the problem, I deleted the folder, and re unzipped. let me play some more.

After playing, I got it to work,  great

[1579653747]

1579653747

[1579653747]

1579653747

[1579653747]

1579653747

[1579653747]

1579653747

[nordmann666]

I installed on windows 10 pro system, ran the app, and it worked fine.
Then decided to run the start.bat file, well now....

When I run the application, it launches the dos window blank., and then closes.
So I deleted the folder, and unzipped again. when I launch the app, the same thing happens.

I made sure that windows defender excluded the folder..

Any ideas.?

run the app with pre-opened cmd.exe -> than you get the error message and the cmd windows dont close automatic

[UnclWish]

doctor, in 1.6.2 situation with building kernels files is the same as in 1.6.1? Nothing changes there?

[doktor83]

doctor, in 1.6.2 situation with building kernels files is the same as in 1.6.1? Nothing changes there?

sorry i don't understand the question

[UAGet]

- Fixed miner crash when using a non AES capable CPU on some algos

Yes! For my RX 560 all Ok.

[UnclWish]

doctor, in 1.6.2 situation with building kernels files is the same as in 1.6.1? Nothing changes there?

sorry i don't understand the question

Don't you forget about fragments, chunk size, etc...?

[heavyarms1912]

Guys,

first, thanks to all that didn't care and made fun of me when I reported missing hashrate problem. I tried hard to explain that the cast-xmr and srbminer report incorrect or inconsistent hashrate, for example my vega rigs are hashing up to 20% less on the pool than what the miner reports, just to be stomped by armada of forumeers who try to teach me basic math, finally, I was advised to find another miner if I don't like this one - and I did

last few days I tried new  miner called JCE, the guy just made a beta version for GPUs, and my Vegas not only hash better than SRBminer (7xVega 56 14350) but every single hash is counted by the pool properly. This leads me to conclusion that srb and cast have issues with counting or are reporting false hashrate. I will now support new guy and his miner.

If doktor83 ever cares to fix this problem, I will be happy to provide support and more details.

Have fun and enjoy your mining

I am glad you finally found something that is working for you.
But please, next time don't come back just to advertise another miner.

It's a very very pertinent and valid observation however.
Especially since JCE is claiming a lot of devs "cheat" with their closed-source miners. If his miner's hashrate coincides with what the pools report - and SRB, Cast etc do not - there is a problem, isn't there?

it's pretty much given that closed source devs would be picking up optimizations from open source.
The only reason they wouldn't is if the integration of the optimization is an overhead.

[SmartOdissey]

Hello Guys and Doctor83.

I have a rig with Vega56-4pcs and XFX 580_8G  - 3pcs

System is Win 10 64 LTSB 1607.

All 580 are flashed with bios modified by SRBPolaris.
All Vega56 stock.

OverdriveNtool params for Vega 56:
GPU_P6=1312;950
GPU_P7=1474;1000
Mem_P3=945;950
Power_Target=-20

For 580:
GPU_P6=1300;1100
GPU_P7=1318;1100
Mem_P2=2130;950
Power_Target=-20

SrbMiner 1.6.0 params
"cryptonight_type" : "haven",
"intensity" : 0,
"double_threads" : true,
"min_rig_speed" : 7800,

"gpu_conf" :
580           { "id" : 0, "intensity" : 51, "worksize" : 8, "threads" : 2}
Vega56     { "id" : 1, "intensity" : 56, "worksize" : 8, "threads" : 2}
   
Usually i have on HEAVY/HAVEN 1050-1090 H/s for 580, and 1250-1370 H/s for Vega56 with   Blockchain drivers Aug 23.
And 600-800H/s for 580 and 1350-1470 H/s for Vega56 with 18.5.4 drivers.

Better hashrate with outside T 20C and lower. If temperature 30C+ hashrate go down to 20-30%....

And i need to know:
1. How miners get a 1800-2000H/s  CN Heavy with Vega56?
2. Why hashrate is down for 580 with latest drivers?

[livada]

And i need to know:
1. How miners get a 1800-2000H/s  CN Heavy with Vega56?

no way

v7 have this HR(2000+) heavy have 1500HR with vega card

your setup use more power. 750-800W? for 4 vega?GPU_P7=1474;1000 is to much( i use 1440/905mv and have 1500+Hr)
u not use soft powertable. Use soft powerttable and your rig use 650-670W for 4 vega and have 1400-1500HR on heavy algo per card

and you use haven not heavy. haven give a little smaller HR.

[livada]

V1.6.2
- Added support for Italocoin new algo (from block 55.000)
- Auto intensity for Vega cards improved, also managed to increase hashing speed on Vega cards for about [b]~1-1.5%[/b][/size][/size] (mainly on heavy algos)
- If user uses non existing GPU id in gpu_conf, it will be ignored, no error will be thrown
- Fixed miner crash when using a non AES capable CPU on some algos
- Added Windows version and build in log
- Added video driver version in log
- Added info about CPU AES support in log
- Statistics now shows number of stale shares that were accepted by pool
- Added parameter 'min_rig_speed_duration' that can set period for 'min_rig_speed' parameter (minimum is 30 sec), default is 5 min

+ I finally bought a Vega 56 card, so in the next releases i will try to improve the performance for Vegas. For now a little speedup of about 1-1.5% is achieved, mainly on Heavy based algos (Heavy, Haven, Bittube, Italo)

+ If you use a non existant id in gpu_conf, it will now be ignored, only id's that exist in your system will be used

+ There was a bug in soft AES that caused miner crash on Stellite and Haven algos, this is now fixed

+ Added accepted stale shares number in statistics. It can't know the number of real accepted stale shares on pool side, but the logic is simple, if a new job is received, but the miner sends a result in the mean time that is for the previous job, and this share gets accepted by the pool, miner will treat this like an accepted stale share.

+ min_rig_speed_duration can set the time you want to check the average hashrate for 'min_rig_speed' parameter. Default is 5 min.

i test this version and this is it. Problem with small HR is SOLVED.
This version always give  best HR. Not more  on-of  3-4 time. Higher HR is here on start. Nice job doctor.
min_rig_speed_duration - good option (for me)

[RuMiner]

livada lucky you... I've tried different variants again - hashrate is still lower on that 1-1.5%
even updated 18.4.1 drivers to 18.6.1 - no effect
what drivers do you use?

+ I finally bought a Vega 56 card, so in the next releases i will try to improve the performance for Vegas.

Is there a chance you will make BIOS editor for Vegas? ;-)

[henri2018]

V1.6.2
- Added support for Italocoin new algo (from block 55.000)
- Auto intensity for Vega cards improved, also managed to increase hashing speed on Vega cards for about ~1-1.5% (mainly on heavy algos)
- If user uses non existing GPU id in gpu_conf, it will be ignored, no error will be thrown
- Fixed miner crash when using a non AES capable CPU on some algos
- Added Windows version and build in log
- Added video driver version in log
- Added info about CPU AES support in log
- Statistics now shows number of stale shares that were accepted by pool
- Added parameter 'min_rig_speed_duration' that can set period for 'min_rig_speed' parameter (minimum is 30 sec), default is 5 min

+ I finally bought a Vega 56 card, so in the next releases i will try to improve the performance for Vegas. For now a little speedup of about 1-1.5% is achieved, mainly on Heavy based algos (Heavy, Haven, Bittube, Italo)

+ If you use a non existant id in gpu_conf, it will now be ignored, only id's that exist in your system will be used

+ There was a bug in soft AES that caused miner crash on Stellite and Haven algos, this is now fixed

+ Added accepted stale shares number in statistics. It can't know the number of real accepted stale shares on pool side, but the logic is simple, if a new job is received, but the miner sends a result in the mean time that is for the previous job, and this share gets accepted by the pool, miner will treat this like an accepted stale share.

+ min_rig_speed_duration can set the time you want to check the average hashrate for 'min_rig_speed' parameter. Default is 5 min.

Nice job, dok. For heavy algo, I don't need to run twice with intensity 60 first, and then 56. It is good now since intensity 56.

[UnclWish]

In 1.6.2 on cn-v7 algo intensity higher 100 not give jumps and drops in hashrate like it was on 1.6.1. But speed is low on v7... I tried 54,56,72,90,108,116 but all these intensities gives max 985 h/s on my RX 580 8Gb cards. On 1.6.0 I have 1030-1040 h/s...
Maybe I do something wrong? I tried to wait up to 10 min every try. But speed didn't jumps like in heavy algo. It pretty stable. Couse of it I didn't wait any longer.
Who got speed higher 1000 h/s on v7 with 1.6.2? Share your settings, please...

[NotEnough]

In 1.6.2 on cn-v7 algo intensity higher 100 not give jumps and drops in hashrate like it was on 1.6.1. But speed is low on v7... I tried 54,56,72,90,108,116 but all these intensities gives max 985 h/s on my RX 580 8Gb cards. On 1.6.0 I have 1030-1040 h/s...
Maybe I do something wrong? I tried to wait up to 10 min every try. But speed didn't jumps like in heavy algo. It pretty stable. Couse of it I didn't wait any longer.
Who got speed higher 1000 h/s on v7 with 1.6.2? Share your settings, please...

Same issue: 1.6.0 gets 1080 h/s on RX 588, but 1.6.2 - only 1025 h/s with same config.

[UnclWish]

In 1.6.2 on cn-v7 algo intensity higher 100 not give jumps and drops in hashrate like it was on 1.6.1. But speed is low on v7... I tried 54,56,72,90,108,116 but all these intensities gives max 985 h/s on my RX 580 8Gb cards. On 1.6.0 I have 1030-1040 h/s...
Maybe I do something wrong? I tried to wait up to 10 min every try. But speed didn't jumps like in heavy algo. It pretty stable. Couse of it I didn't wait any longer.
Who got speed higher 1000 h/s on v7 with 1.6.2? Share your settings, please...

Same issue: 1.6.0 gets 1080 h/s on RX 588, but 1.6.2 - only 1025 h/s with same config.

Samsung memory?

[NotEnough]

Samsung memory?

Yep, with Uber-Mix 3.1

[greerso]

V1.6.2
- Added support for Italocoin new algo (from block 55.000)
- Auto intensity for Vega cards improved, also managed to increase hashing speed on Vega cards for about ~1-1.5% (mainly on heavy algos)
- If user uses non existing GPU id in gpu_conf, it will be ignored, no error will be thrown
- Fixed miner crash when using a non AES capable CPU on some algos
- Added Windows version and build in log
- Added video driver version in log
- Added info about CPU AES support in log
- Statistics now shows number of stale shares that were accepted by pool
- Added parameter 'min_rig_speed_duration' that can set period for 'min_rig_speed' parameter (minimum is 30 sec), default is 5 min

+ I finally bought a Vega 56 card, so in the next releases i will try to improve the performance for Vegas. For now a little speedup of about 1-1.5% is achieved, mainly on Heavy based algos (Heavy, Haven, Bittube, Italo)

+ If you use a non existant id in gpu_conf, it will now be ignored, only id's that exist in your system will be used

+ There was a bug in soft AES that caused miner crash on Stellite and Haven algos, this is now fixed

+ Added accepted stale shares number in statistics. It can't know the number of real accepted stale shares on pool side, but the logic is simple, if a new job is received, but the miner sends a result in the mean time that is for the previous job, and this share gets accepted by the pool, miner will treat this like an accepted stale share.

+ min_rig_speed_duration can set the time you want to check the average hashrate for 'min_rig_speed' parameter. Default is 5 min.

Looks like you included Imperdin's heavy optimizations for that small bump.  Did you include that GPL3 code in your miner?

[doktor83]

V1.6.2
- Added support for Italocoin new algo (from block 55.000)
- Auto intensity for Vega cards improved, also managed to increase hashing speed on Vega cards for about ~1-1.5% (mainly on heavy algos)
- If user uses non existing GPU id in gpu_conf, it will be ignored, no error will be thrown
- Fixed miner crash when using a non AES capable CPU on some algos
- Added Windows version and build in log
- Added video driver version in log
- Added info about CPU AES support in log
- Statistics now shows number of stale shares that were accepted by pool
- Added parameter 'min_rig_speed_duration' that can set period for 'min_rig_speed' parameter (minimum is 30 sec), default is 5 min

+ I finally bought a Vega 56 card, so in the next releases i will try to improve the performance for Vegas. For now a little speedup of about 1-1.5% is achieved, mainly on Heavy based algos (Heavy, Haven, Bittube, Italo)

+ If you use a non existant id in gpu_conf, it will now be ignored, only id's that exist in your system will be used

+ There was a bug in soft AES that caused miner crash on Stellite and Haven algos, this is now fixed

+ Added accepted stale shares number in statistics. It can't know the number of real accepted stale shares on pool side, but the logic is simple, if a new job is received, but the miner sends a result in the mean time that is for the previous job, and this share gets accepted by the pool, miner will treat this like an accepted stale share.

+ min_rig_speed_duration can set the time you want to check the average hashrate for 'min_rig_speed' parameter. Default is 5 min.

Looks like you included Imperdin's heavy optimizations for that small bump.  Did you include that GPL3 code in your miner?

It just looks like, but dont worry imperdin, as i already told you i dont need to use your crazy insane mega giga optimisations. I already got even more speed increase since we talked, so if you plan releasing another mega giga optimisation please dont do it before i release the next version of miner.

[doktor83]

In 1.6.2 on cn-v7 algo intensity higher 100 not give jumps and drops in hashrate like it was on 1.6.1. But speed is low on v7... I tried 54,56,72,90,108,116 but all these intensities gives max 985 h/s on my RX 580 8Gb cards. On 1.6.0 I have 1030-1040 h/s...
Maybe I do something wrong? I tried to wait up to 10 min every try. But speed didn't jumps like in heavy algo. It pretty stable. Couse of it I didn't wait any longer.
Who got speed higher 1000 h/s on v7 with 1.6.2? Share your settings, please...

Same issue: 1.6.0 gets 1080 h/s on RX 588, but 1.6.2 - only 1025 h/s with same config.

guys what is your 30 min average speed in statistics 1.6.0 vs 1.6.2?

[ipe4enko]

In 1.6.2 on cn-v7 algo intensity higher 100 not give jumps and drops in hashrate like it was on 1.6.1. But speed is low on v7... I tried 54,56,72,90,108,116 but all these intensities gives max 985 h/s on my RX 580 8Gb cards. On 1.6.0 I have 1030-1040 h/s...
Maybe I do something wrong? I tried to wait up to 10 min every try. But speed didn't jumps like in heavy algo. It pretty stable. Couse of it I didn't wait any longer.
Who got speed higher 1000 h/s on v7 with 1.6.2? Share your settings, please...

Same issue: 1.6.0 gets 1080 h/s on RX 588, but 1.6.2 - only 1025 h/s with same config.

guys what is your 30 min average speed in statistics 1.6.0 vs 1.6.2?

It's not my questions. But on srb 1.6.1- 1.6.2 i see lower performance about 50 h/s on one rx550 card. If need i can publish logs.
On the same configs. Perhaps we need to change configuration, intensity or worksize?