doktor83 (OP)
|
 |
May 04, 2019, 02:55:54 PM |
|
How do I enable tweaking on my VII... eavery time i start miner it sais tweaking: disabled
Run as admin, its in the readme
|
|
|
|
|
|
|
Be very wary of relying on JavaScript for security on crypto sites. The site can change the JavaScript at any time unless you take unusual precautions, and browsers are not generally known for their airtight security.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
sharmanov
Newbie
Offline
Activity: 53
Merit: 0
|
 |
May 04, 2019, 02:58:41 PM |
|
How do I enable tweaking on my VII... eavery time i start miner it sais tweaking: disabled
Run as admin, its in the readme I did. it still shows disabled
|
|
|
|
doktor83 (OP)
|
 |
May 04, 2019, 03:52:18 PM |
|
How do I enable tweaking on my VII... eavery time i start miner it sais tweaking: disabled
Run as admin, its in the readme I did. it still shows disabled Are you running version 1.8.7 ? If so, look at the log file at the beginning theres more info why is tweaking disabled, if not running 1.8.7 then thats the problem 
|
|
|
|
clancy182
Newbie
Offline
Activity: 21
Merit: 0
|
 |
May 04, 2019, 05:04:58 PM |
|
What driver recommend for new version 1.8.5? Are we need to apply memory timing after that?
I still think that 18.6.1 creates the fastest code, if you are compiling. If you have Vegas you can use the built in 'tweaking profiles' or use ElioVP's tool but first disable SRB tweaking with --disabletweaking switch Ok then, ill try tweaking profile, if vega56 samsung can reach 2100+, ill move from teamred, I like your api remote My Vega56 hynix reaches 2100+, so you should do much better  Hey, can you post what driver you are using and what ODN settings? I know you wrote "just pushed mem up to 940mhs and P7 to 925mV." But can you please elaborate a little bit on how you achieved that? Cheers Here's a video for you : https://youtu.be/QyJzAhdDnPghi dok, in the video, how can u have so low temp with 2300 rmp i have 4 vega 56 with stock bios and i reach like 65-70°... what is the light mode with ODT that u mentioned in this video ? i use 1.8.7 srbminer with 18.6.1 without softpowerplay table JG
|
|
|
|
crpt0x
Newbie
Offline
Activity: 4
Merit: 0
|
 |
May 05, 2019, 11:20:32 AM |
|
Hi,
doktor83 is there some parameter to disable a gpu in config or in START.BAT like keyboard shortcuts but will remain after miner restarts? I have a gpu that I'd like to disable for a while.
|
|
|
|
Markyz23
Newbie
Offline
Activity: 30
Merit: 0
|
 |
May 05, 2019, 04:59:52 PM |
|
The latest version 1.8.7 works perfectly for upx2. CPU is not overloaded. On the contrary on the same rig running at the same time srbminer and xmrig.
Will try it out, i used the 1.8.6 version yesterday. Otherwise i will use the "old_mode" solution. Thanks a lot:) I tested the 1.8.7 version and the "old_mode" method and in my case none of them helped. Still the cpu is at 99% and it's throttling my gpu's. With "old_mode" : true the hashrate drops even further, around 22kh/s per card. Is there anything else i can do? Doctor, did you found out what's causing the cpu overload? Nah, not really possible that with old mode enabled still 99%. Yes, hashrate is little lower on some algos with it enabled because more work is done on the GPU, and almost none on the CPU. I exactly know why it's giving more load on the cpu, because upx job round is done in less than 100ms, and a 1,2,4mb scratchpaded job is done in ~2s. Rewriting some stuff to use intrinsics, so cpu load will be lower. But still old mode enabled should decrease your cpu load a lot. Fixed the issue, my config was not properly structured and it didn't initialize old_mode. Now the hashrate is great and the cpu workload is around 55%. Great job doctor. Currently i achieved to lower the cpu usage by around 40% without the old_mode enabled, still working on it, maybe i can lower it more. Weak CPU + lot of GPU's in rig + low difficulty can really make your CPU sweat. I am surprised that your cpu usage is 55% with old_mode, that must be some really weak CPU in there  Checked again after a while and it's down to 30-35%. It's a Intel Celeron G3900, the most affordable one for mining. Sold my Ryzens. As far as i read this ann, there's a lot of improvement for Vega cards but almost none for the RX series. Is there any juice left for you to squeeze out of them or should i start considering buying Vega's now when they are cheap?
|
|
|
|
doktor83 (OP)
|
 |
May 06, 2019, 12:12:44 PM Last edit: May 08, 2019, 11:01:48 AM by doktor83 |
|
V1.8.8- Reduced CPU usage up to ~50%, can be noticed on algos with small scratchpad - User is now informed about tweaking status on the screen too, not just in log - No more --gpureorder, device ordering by bus id is now the default/only display mode - Added parameter --watchdogrounds , which controls after how many rounds will watchdog trigger - min_rig_speed_duration default is 1 minute now, because of the new --watchdogrounds parameter - Fixed a few cosmetical things on web stats + If not using 'old_mode', on weak CPU's the cpu usage could go boom on algos with small scratchpad (UPX2, Turtle). In this version i managed to lower the cpu usage up to ~50%. This also brings a small hashrate increase for RX cards on UPX2 as a side effect  + The default (and only) device ordering mode from now on is ascending by bus id, as it is in OverdriveNTool. Parameter --gpureorder is removed. NOTE: if you are using gpu_conf or --cgpuid, please run --listdevices to check if you are using the right deviceid!+ Because of some trouble with gpu/min_rig_speed watchdog and kernel precompilation on CN/R (V4), a new parameter --watchdogrounds was added, so you can control after how many check-rounds will the watchdog trigger. The GPU crash watchdog has a fixed interval of 30 seconds = 1 round. That means it will trigger miner restart only after --watchdogrounds * 30 sec (default number of rounds is 5). 5 * 30 = 150 sec ~ 2.5 minutes. If gpu crashes and can't recover for 2.5 minutes, the miner will trigger the restart action. min_rig_speed parameter is also affected by --watchdogrounds from now on. The 'min_rig_speed_duration' parameter default value is now 60 sec, this is the value as the above for the gpu crash watchdog, except that you can change the value of this to anything >= 30 sec. Taking the default value of 60 seconds and 5 rounds, it is 5 * 60 = 300 sec = 5 minute, that means if for 5 minutes the 'min_rig_speed' < total hashing speed, then it will trigger miner restart.
|
|
|
|
clousian
Newbie
Offline
Activity: 33
Merit: 0
|
 |
May 07, 2019, 12:12:17 AM Last edit: May 07, 2019, 12:23:58 AM by clousian |
|
Anyone have any experience running SRB v1.8.7 as a client in minerstat? Whatever I do in the config file, it doesn't translate when I launch srb in minerstat.
My settings for monero: { "cryptonight_type" : “normalv4”, "intensity" : 0, "double_threads" : true, "gpu_conf" : [ { "id" : 0, "intensity" : 106, "worksize" : 8, "threads" : 2, "old_mode" : true }, { "id" : 1, "intensity" : 59, "worksize" : 8, "threads" : 2, "old_mode" : true }, { "id" : 2, "intensity" : 106, "worksize" : 8, "threads" : 2, "old_mode" : true }, { "id" : 3, "intensity" : 105, "worksize" : 8, "threads" : 2, "old_mode" : true }, { "id" : 4, "intensity" : 105, "worksize" : 8, "threads" : 2, "old_mode" : true } ] }
What srb in minerstat is stuck at:
id 0,2,3,4 at 71 intensity id: 1 at 56 intensity. What am I doing wrong in the normalv4 config?
|
|
|
|
optii
Newbie
Offline
Activity: 23
Merit: 3
|
 |
May 07, 2019, 08:07:58 AM |
|
V1.8.8- Reduced CPU usage up to ~50%, can be noticed on algos with small scratchpad - User is now informed about tweaking status on the screen too, not just in log - No more --gpureorder, device ordering by bus id is now the default/only display mode - Added parameter --watchdogrounds , which controls after how many rounds will watchdog trigger - min_rig_speed_duration default is 1 minute now, because of the new --watchdogrounds parameter - Fixed a few cosmetical things on web stats + If not using 'old_mode', on weak CPU's the cpu usage could go boom on algos with small scratchpad (UPX2, Turtle). In this version i managed to lower the cpu usage up to ~50%. This also brings a small hashrate increase for RX cards on UPX2 as a side effect  + The default (and only) device ordering mode from now on is ascending by bus id, as it is in OverdriveNTool. Parameter --gpureorder is removed. + Because of some trouble with gpu/min_rig_speed watchdog and kernel precompilation on CN/R (V4), a new parameter --watchdogrounds was added, so you can control after how many check-rounds will the watchdog trigger. The GPU crash watchdog has a fixed interval of 30 seconds = 1 round. That means it will trigger miner restart only after --watchdogrounds * 30 sec (default number of rounds is 5). 5 * 30 = 150 sec ~ 2.5 minutes. If gpu crashes and can't recover for 2.5 minutes, the miner will trigger the restart action. min_rig_speed parameter is also affected by --watchdogrounds from now on. The 'min_rig_speed_duration' parameter default value is now 60 sec, this is the value as the above for the gpu crash watchdog, except that you can change the value of this to anything >= 30 sec. Taking the default value of 60 seconds and 5 rounds, it is 5 * 60 = 300 sec = 5 minute, that means if for 5 minutes the 'min_rig_speed' < total hashing speed, then it will trigger miner restart. hi, my vega 64 CN-R algo without tweaking Hashrate dropped from 2040 to 1970 moving from 187 to 188 , same config and same pool file and same coin. interesting is that my vega 56 didnt get affected. Im running low voltage settings on both cards (at the most stable possible setting)
|
|
|
|
Iamtutut
|
 |
May 07, 2019, 08:27:25 AM |
|
V1.8.8- Reduced CPU usage up to ~50%, can be noticed on algos with small scratchpad - User is now informed about tweaking status on the screen too, not just in log - No more --gpureorder, device ordering by bus id is now the default/only display mode - Added parameter --watchdogrounds , which controls after how many rounds will watchdog trigger - min_rig_speed_duration default is 1 minute now, because of the new --watchdogrounds parameter - Fixed a few cosmetical things on web stats + If not using 'old_mode', on weak CPU's the cpu usage could go boom on algos with small scratchpad (UPX2, Turtle). In this version i managed to lower the cpu usage up to ~50%. This also brings a small hashrate increase for RX cards on UPX2 as a side effect  + The default (and only) device ordering mode from now on is ascending by bus id, as it is in OverdriveNTool. Parameter --gpureorder is removed. + Because of some trouble with gpu/min_rig_speed watchdog and kernel precompilation on CN/R (V4), a new parameter --watchdogrounds was added, so you can control after how many check-rounds will the watchdog trigger. The GPU crash watchdog has a fixed interval of 30 seconds = 1 round. That means it will trigger miner restart only after --watchdogrounds * 30 sec (default number of rounds is 5). 5 * 30 = 150 sec ~ 2.5 minutes. If gpu crashes and can't recover for 2.5 minutes, the miner will trigger the restart action. min_rig_speed parameter is also affected by --watchdogrounds from now on. The 'min_rig_speed_duration' parameter default value is now 60 sec, this is the value as the above for the gpu crash watchdog, except that you can change the value of this to anything >= 30 sec. Taking the default value of 60 seconds and 5 rounds, it is 5 * 60 = 300 sec = 5 minute, that means if for 5 minutes the 'min_rig_speed' < total hashing speed, then it will trigger miner restart. I have an issue, my computer cashes because now SRB tries to use the Vega cores inside the Ryzen 2400G to mine, how could I disable the APU in your miner ? Thanks
|
|
|
|
doktor83 (OP)
|
 |
May 07, 2019, 08:51:11 AM |
|
hi, my vega 64 CN-R algo without tweaking Hashrate dropped from 2040 to 1970 moving from 187 to 188 , same config and same pool file and same coin. interesting is that my vega 56 didnt get affected. Im running low voltage settings on both cards (at the most stable possible setting)
This is interesting, yes, because on vega56 i do the testings, and nothing changed as you say. Are you running the --resetvega parameter ? Also the same ODT as before? Can you test it a few times, just to be sure that there is really a change in hashrate, because there shouldnt be...  I have an issue, my computer cashes because now SRB tries to use the Vega cores inside the Ryzen 2400G to mine, how could I disable the APU in your miner ? Thanks
By now, you mean from v1.8.8 ? The ordering of the devices changed - they are now ordered by bus id so it is the same order as in ODT. Run SRBMiner-CN.exe --listdevices in cmd and set device id's you use according to that
|
|
|
|
|
doktor83 (OP)
|
 |
May 07, 2019, 11:40:35 AM |
|
Swap the intensities in 1.8.8 in gpu_conf, so : id:1 = intensity 112 id:0 = intensity 122 You should be all back to normal  Check the post above yours
|
|
|
|
optii
Newbie
Offline
Activity: 23
Merit: 3
|
 |
May 07, 2019, 01:06:00 PM |
|
Swap the intensities in 1.8.8 in gpu_conf, so : id:1 = intensity 112 id:0 = intensity 122 You should be all back to normal  Check the post above yours perfect, it works fine now, thanks 
|
|
|
|
NCarter84
Jr. Member
Offline
Activity: 195
Merit: 4
|
 |
May 07, 2019, 10:54:20 PM |
|
For the life of me, I cannot get 1.8.8 to run on any algo.... Whenever I hit H or S, I get nothing... Very slow response times... Compute Errors and GPU Crashes. I've tried on CN-GPU and CN-HOSP.
I'm using command line to run the miner, as I always have... Did something change here that I missed? 1.8.6 runs fine.
--ccryptonighttype hospital --cpool [Server]:[Port] --cwallet [User] --cpassword [Password] --apienable
|
|
|
|
doktor83 (OP)
|
 |
May 08, 2019, 05:16:30 AM |
|
For the life of me, I cannot get 1.8.8 to run on any algo.... Whenever I hit H or S, I get nothing... Very slow response times... Compute Errors and GPU Crashes. I've tried on CN-GPU and CN-HOSP.
I'm using command line to run the miner, as I always have... Did something change here that I missed? 1.8.6 runs fine.
--ccryptonighttype hospital --cpool [Server]:[Port] --cwallet [User] --cpassword [Password] --apienable
Which gpu's and driver?
|
|
|
|
jimmyD30
Jr. Member
Offline
Activity: 64
Merit: 1
|
 |
May 08, 2019, 09:39:37 PM |
|
Hello, anyone know why I’m seeing this message (in light grey) after the miner been running for a while (not just right after startup)? “Precompiling program [Bus...” “Program finished precompiling [Bus...” Win10 / Vega64 / v1.8.8 / Monero
|
|
|
|
doktor83 (OP)
|
 |
May 08, 2019, 10:06:35 PM |
|
Hello, anyone know why I’m seeing this message (in light grey) after the miner been running for a while (not just right after startup)? “Precompiling program [Bus...” “Program finished precompiling [Bus...” Win10 / Vega64 / v1.8.8 / Monero Its all good, just thar from 1.8.8 user can see these messages, before it wasnt displayed.
|
|
|
|
jimmyD30
Jr. Member
Offline
Activity: 64
Merit: 1
|
 |
May 08, 2019, 10:39:08 PM |
|
Hello, anyone know why I’m seeing this message (in light grey) after the miner been running for a while (not just right after startup)? “Precompiling program [Bus...” “Program finished precompiling [Bus...” Win10 / Vega64 / v1.8.8 / Monero Its all good, just thar from 1.8.8 user can see these messages, before it wasnt displayed. Ok, thank you. I switched pools at the same time I upgraded to v1.8.8, so wasn’t sure what was going on.
|
|
|
|
NCarter84
Jr. Member
Offline
Activity: 195
Merit: 4
|
 |
May 09, 2019, 12:02:27 AM |
|
For the life of me, I cannot get 1.8.8 to run on any algo.... Whenever I hit H or S, I get nothing... Very slow response times... Compute Errors and GPU Crashes. I've tried on CN-GPU and CN-HOSP.
I'm using command line to run the miner, as I always have... Did something change here that I missed? 1.8.6 runs fine.
--ccryptonighttype hospital --cpool [Server]:[Port] --cwallet [User] --cpassword [Password] --apienable
Which gpu's and driver? I can't remmber which exact GPU I have 580/590 in this rig.... driver is 19.4.1 Other algos worked... I know WOW did fine... but for wow I had all the jazz added to the command line with the device id, intensity level, threads.
|
|
|
|
|