Hi Doktor,
Accoding to you recomendation I changed drivers to Adr.18.6.1(prev. was blockchain)
and faced with hash rate double decreased.
Iw was ~1900h/s on old drivers, but now it ~830h/s for rx570-4 on CN fast.
Compute mode enabled(SRBMiner-CN.exe --setcomputemode).
Please, help. Ireaaly dont want to return to blockchain drv.
Hi i can think of 2 things: 1. You did not run setcompute mode as admin 2. You are using 1 thread instead of 2 |
|
|
|
Isn't there a Monero fork in the works supposed to go live very soon?
Cryptonight v2?
I thought XMR was supposed to fork on 1st September... Maybe I got that wrong.
Have you got a new miner version ready in any case?
EDIT: I found it. September 16th. There's some time left.
can you share the link? |
|
|
|
doktor - during low hashrate or miner hang events, miner restarts will trigger (not RIG reboot) - under what circumstances will the "reboot-windows.BAT" file triggered ? Can we select via CLI to do RIG REBOOT instead of miner restart in config file? Thanks
Set in config.txt "reboot_script" : filename to a batch file in miner directory, if set it turns off built in miner reset procedure on gpu failure, and instead runs this scriptStrange, but after 1.6.5 version this doesn't seem to work anymore, and the miner just wants to restart and hangs. Any ideas why? Doktor, With v1.6.6 on 2 rigs, 2 x Vega56 and 4 x Vega64, and reboot script updated in the config file. The Vega64 rig is stable mining XMR and has not triggered the reboot file since Aug 28. The Vega56 rig however, reboots every half hour like clockwork. I am tempted to revert to v1.6.5 but if you can figure out whats wrong - I will avoid the downtime. sorry but i can't help without looking at log files. Add --logfile log.txt in your start.bat (at the end of SRBMiner-CN.exe line) to enable logging then when you got the log (after 30 minutes where you say it restarts), upload the logs somewhere and give me the link please. |
|
|
|
Vega56 users, please try v1.6.7 and a heavy algo (haven, bittube, heavy, italo) with :
intensity : 61
worksize : 9
threads : 2
Do you get better results than earlier ?
How many performance increase have you found? Maybe try it later when I am back home Which driver do you use? Instead of 1500hs i get around 1550 hs without the 'start the miner with intensity 60 then ... ' trick. As this is VERY nice, i want to be sure im not the only one getting it  |
|
|
|
|
Vega56 users, please try v1.6.7 and a heavy algo (haven, bittube, heavy, italo) with :
intensity : 61
worksize : 9
threads : 2
Do you get better results than earlier ?
|
|
|
|
Anyone else having issues with Vegas on CN-Fast? I have multiple vega rigs that give lower numbers than expected. It seems only 3-4 cards will give the appropriate hashrate while the rest take a ~300 drop for some reason. This happens to both 56 rigs and 64s. All my rigs have minimum 200GB of virtual memory on the systems. It's really wierd. Doesn't happen with CN-LiteV7, StelliteV4 or regular CNV7 only with CN-Fast.
All rigs are using Adrenalin 18.6.1. I have tried all the miners from V1.6.1- 1.6.7.
This is a Vega 56 rig:
This is a Vega 64/56 rig:
There is a problem on RX480 - hashrate drop from 850 to 480 hashes. It is then restored and a few good share again. Until I figured out the reason. So what was the reason, if you figured it out ?  |
|
|
|
Yes I have 290x, a few 290, and one 390x. All in 6 card rigs. When 3 threads are used, not all cards will start. Here are a couple examples
I:42 W:8 T:2 K:2 (even though K:1 was put in config globally) 290x - 848 h/s & 290 - 776 h/s on average
I:38 W:8 T:2 K:1 (no kernel value in config) 390x - 842 h/s & 390 - 825, 787, 786, 787, 833
So kernel 2 was assigned to 290 series and kernel 1 was assigned to 390 series. Kind of strange but maybe it's based on memory. I will try to override K:1 for the 390's in gpu_conf section.
If you could tell me what that person was getting for his 390x with 3 threads and 30 intensity, that would be very helpful.
There is no such a thing as global kernel setting in the config, so that's why it isn't working Kernel parameter can be set only in gpu_conf. You should try kernel 2 on the 390x also, the 3 thread setup, because kernel 1 is now really more for 4xx 5xx and vegas. |
|
|
|
doktor - during low hashrate or miner hang events, miner restarts will trigger (not RIG reboot) - under what circumstances will the "reboot-windows.BAT" file triggered ? Can we select via CLI to do RIG REBOOT instead of miner restart in config file? Thanks
Set in config.txt "reboot_script" : filename to a batch file in miner directory, if set it turns off built in miner reset procedure on gpu failure, and instead runs this scriptThanks doktor. Added the file name in config file. Will monitor rig. you can find all these hefty parameters on the first page or in the readme  |
|
|
|
Somebody could post a conf file for 2 vega?
To manually set up video cards, you must create a "gpu_conf" array in the config.txt file. Example : "gpu_conf" : [ { "id" : 0, "intensity" : 0, "worksize" : 8, "threads" : 2}, { "id" : 1, "intensity" : 0, "worksize" : 8, "threads" : 2} ] |
|
|
|
doktor - during low hashrate or miner hang events, miner restarts will trigger (not RIG reboot) - under what circumstances will the "reboot-windows.BAT" file triggered ? Can we select via CLI to do RIG REBOOT instead of miner restart in config file? Thanks
Set in config.txt "reboot_script" : filename to a batch file in miner directory, if set it turns off built in miner reset procedure on gpu failure, and instead runs this script |
|
|
|
Paste here your config.txt
Also it would be very nice to get the log file pasted here
{ "cryptonight_type" : "normalv7", "intensity" : 100, "double_threads" : true, /* THERE ARE A LOT OF OPTIONS/PARAMETERS YOU CAN USE HERE */ /* YOU CAN FIND THEM IN THE README FILE */ } what do you mean by log? sorry im so new with mining thank you If you are using the latest 1.6.7 version then logging is enabled by default, every time you start the miner it creates a .txt file. Start miner and let it run a minute or two, then paste here the latest .txt file created. |
|
|
|
Yes, my Vega 56s do the same thing with fast algo. Still no explanation as to why.
IDK neither because its the same code as V7, only that it uses half the iterations as normalV7. Everything else is same. Have you tried what i suggested earlier to use 112/16/2 ? |
|
|
|
Hi, could you help me identify the problem,
First, i cant set SRBMiner.exe to compute mode, and I cant get 2khs with my vega 56, even though, I've done per your instructions.
thank you
Write down what steps you did, and what result did you get. Also driver version, did you use soft powerplay tables, clocks etc. nothing much bee done on the config, 0 intensity and changing registries and crossfire. and then i followed your guide on intensity, worksize and others now my SRBMiner detects 3 cards, and only 1 card got hashrate... Paste here your config.txt Also it would be very nice to get the log file pasted here |
|
|
|
|
I fixed a small bug with the new --algoswitchmintime parameter, as it was reset on algo change.
If you are using algo switching please download 1.6.7 again.
|
|
|
|
Hi;
@doktor83 Thank you for the new version.
My miner (V1.6.7 ArtoCash) works only 11 minutes with 2,1kH/s than miner is rebooting itself.
Adrenalin 18.6.1, intensity 0, No OC, 6*RX580 8G Limited edition, Win10
Kind regards
Hi, maybe you should try to set intensity by hand, because the auto setup isnt perfect Try with the value you get from auto - 1 for start. So your config could look like this for example: {
"cryptonight_type" : "artocash",
"intensity" : 54,
"double_threads" : true
}54 is here just an example, you should use the value you get from auto - 1 |
|
|
|
doktor, my hawaii cards are being detected as pre-GCN and kernel 2 gets loaded by default. If you don't set a global intensity then it tries to use 3 threads.
edit: If I raise the intensity to 42 then I good get speeds with kernel 2 and 2 threads even though I put kernel 1 in my config....
kernel2 is now for 'older' cards, so thats why it selects that one automatically. Also i got info from someone with 390x cards that for v7 3 threads and intensity 30 works best, i couldn't test that i dont have those cards. Do you have 290x ? you should be able to change to kernel 1, that setting is set per card like : "gpu_conf" : [ { "id" : 0, "intensity" : 124, "worksize" : 8, "threads" : 2, "kernel" : 1 } ] |
|
|
|
Hi, could you help me identify the problem,
First, i cant set SRBMiner.exe to compute mode, and I cant get 2khs with my vega 56, even though, I've done per your instructions.
thank you
Write down what steps you did, and what result did you get. Also driver version, did you use soft powerplay tables, clocks etc. |
|
|
|
Any chance to create a linux version? Your miner is the best and it's a pity that it can't be used on Linux.
Im not really planning it because i was totally focused on windows from the start, and way too much code has to be changed/adapted and that means also a lot of new bugs. But hey, i won't say never, who knows... |
|
|
|
|
V1.6.7
- Now providing binary kernels for popular algos on mainstream cards (Vega56&64&FE, RX470&480&570&580, RX550&560)
- Auto setup for a lot of cards improved, especially for RX550, RX560
- A lot of OCL optimizations, mainly on Heavy algos (Heavy, Haven, Bittubev2, Italo)
- Removed --sendallstales parameter because it is now the default behavior (to send all stale shares)
- When using algo switching mining time is now showing total mining time, not just for the specific algo
- Now on every miner start a new log file is created, in the format of date-time in normal mining mode
- Added parameter --algoswitchmintime
- Completely setup everything for algo switching on Monero Ocean pools, you just need to edit your algo hashrates, and change wallet in the example files
+ Ok, binary kernels. Yes, the .zip grew in size a lot, because i decided to provide binary kernels for a few algos, for popular video cards.
I had to do this because of the crappy new 18.7+ drivers, where the compiler created bad .srb files.
A lot of people don't follow the big letters from the first page that says use 18.3.4 or 18.6.1 drivers.
So now i provide binary kernels for popular algos for :
- Vega 56
- Vega 64
- Vega FE
- RX 470
- RX 480
- RX 570
- RX 580
- RX 550
- RX 560
If you have some problems with these pre-compiled files (maybe blockchain drivers don't like them), just delete the BinaryKernels directory, and the miner will compile them for you, just like it was before.
I had a problem on one of the 580 rigs on BC drivers while testing, that they could not handle intensity 56 anymore, but 55 was ok with the new kernel.
Deleted the pre-compiled kernels, miner created them on BC drivers and then cards could run again on intensity 56.
+ I did a lot of optimizations in OCL kernels, and in auto setup for a lot of cards, so you should try it out. Heavy algos on Vega56 and auto setup now give you more hash by 1-2-3%! (tested on 18.6.1 drivers)
+ The --sendallstales is removed and you don't have to use it anymore, because that is now the default setup
+ For those using the algo switching, a new parameter --algoswitchmintime was added, it is used on Monero Ocean pools, and it sets the minimum time that you want an algo to be mined. The default value is 600 (10 minutes), this means that the pool shouldn't switch to another algo for minimum 10 minutes. This parameter should be entered in seconds.
+ I created all files you need for algo switching on Monero Ocean pools, so you just have to edit them now. Put the hashrate of your rig for the specific algo in algos.txt and change the XMR wallet address in pools-algoswitch.txt
|
|
|
|
Hello guys, i'm triying mining with this SRBMiner Version 1.6.6 i have one ASUS R9 270x 2GB OC. the pool is Qrl.herominers and i have 343 h/s reporting with normalv7 algo, but i don't see acepted shares, after 1 hour i just keep whatching "Pool sent a new job..." ad nothing more. what can i do ?
you should use 18.3.4 or 18.6.1 drivers Is it because they screwed up the OpenCL libraries or something to that tune? 18.7 , 18.8 has a screwed compiler, so no shares are found when compiled on those drivers. But kernels compiled on older versions can be used with those drivers. |
|
|
|
|
Show Posts
