doktor83 (OP)
|
 |
June 09, 2018, 02:05:51 PM |
|
dok, I have an interesting problem. Using v1.6.0, with 5 rx470-8gb, stellite4 algo: All 5 GPUs initialize and are identified correctly on your miner, then after pool connection, display shows only FOUR GPUs, but the first one, GPU0, has DOUBLE the output of all others, I tried restarting, but with same output. Now this isn't a hashrate problem at the pool, just on the miner display. I think that the GPU bus identification is wrong on one of the cards by the miner software.
are you also on win 10 v1803 and some 18.5.2 or newer drivers?
|
|
|
|
JuanHungLo
|
 |
June 09, 2018, 02:08:53 PM |
|
dok, I have an interesting problem. Using v1.6.0, with 5 rx470-8gb, stellite4 algo: All 5 GPUs initialize and are identified correctly on your miner, then after pool connection, display shows only FOUR GPUs, but the first one, GPU0, has DOUBLE the output of all others, I tried restarting, but with same output. Now this isn't a hashrate problem at the pool, just on the miner display. I think that the GPU bus identification is wrong on one of the cards by the miner software.
are you also on win 10 v1803 and some 18.5.2 or newer drivers? Win 7-64, blockchain drivers (Aug), and yes the first and last GPU are both being identified as bus 7
|
Bull markets are born on pessimism, grow on skepticism, mature on optimism, and die on euphoria. - John Templeton
|
|
|
doktor83 (OP)
|
 |
June 09, 2018, 02:11:19 PM |
|
dok, I have an interesting problem. Using v1.6.0, with 5 rx470-8gb, stellite4 algo: All 5 GPUs initialize and are identified correctly on your miner, then after pool connection, display shows only FOUR GPUs, but the first one, GPU0, has DOUBLE the output of all others, I tried restarting, but with same output. Now this isn't a hashrate problem at the pool, just on the miner display. I think that the GPU bus identification is wrong on one of the cards by the miner software.
are you also on win 10 v1803 and some 18.5.2 or newer drivers? Win 7-64, blockchain drivers (Aug), and yes the first and last GPU are both being identified as bus 7 could you turn on logger and send it to me?
|
|
|
|
WhyMe
|
 |
June 09, 2018, 02:15:29 PM |
|
I've not find anything about this in first post or readme : is there any option to limit log file size ? Actually it's just growing day after day. Thanks
|
|
|
|
efeeyll
Newbie
Offline
Activity: 42
Merit: 0
|
 |
June 09, 2018, 02:47:06 PM |
|
Tried previous versions on 8*Vega64 rig under 18.3.4 driver, better hashrate than other miners (2000 h/s @ 160W per card) Today v1.3.2 fixed temp & RPM readings on my rig, stability seems very good Great job ! Thanks !
|
|
|
|
popow_sergei
Newbie
Offline
Activity: 26
Merit: 0
|
 |
June 09, 2018, 03:43:53 PM |
|
[2018-06-08 23:07:33] Error CL_OUT_OF_HOST_MEMORY when creating clCreateCommandQueue for DeviceID 0 (Thread 0) [2018-06-08 23:07:33] Error initing GPU's. Stopping miner process
what caused the error ?
|
|
|
|
UnclWish
|
 |
June 09, 2018, 03:56:29 PM |
|
[2018-06-08 23:07:33] Error CL_OUT_OF_HOST_MEMORY when creating clCreateCommandQueue for DeviceID 0 (Thread 0) [2018-06-08 23:07:33] Error initing GPU's. Stopping miner process
what caused the error ? You can read? Miner all wrote to you. Not enogh memory on card. Lower intensity.
|
|
|
|
Bry Guy
Newbie
Offline
Activity: 11
Merit: 0
|
 |
June 09, 2018, 03:57:47 PM |
|
V1.6.0 - Added support for Haven new algo after fork (block 89200) - Added support for Masari new algo (fast) after fork (block 204000) - Job timeout default is now 20 minutes - More logging on miner startup - Added option 'persistent_memory' in gpu_conf
Hey Dok, thanks for the update. I just started playing with persistent_memory. I know that your notes in CAPS after each option shown in the ReadMe are meant to be purely informational, but you may want to change the TRUE OR FALSE to lower case or use it in an example config to limit potential confusion, since the parser will throw an error if true/false is in CAPS when loading. Keep up the great work!
|
|
|
|
doktor83 (OP)
|
 |
June 09, 2018, 04:24:20 PM |
|
V1.6.0 - Added support for Haven new algo after fork (block 89200) - Added support for Masari new algo (fast) after fork (block 204000) - Job timeout default is now 20 minutes - More logging on miner startup - Added option 'persistent_memory' in gpu_conf
Hey Dok, thanks for the update. I just started playing with persistent_memory. I know that your notes in CAPS after each option shown in the ReadMe are meant to be purely informational, but you may want to change the TRUE OR FALSE to lower case or use it in an example config to limit potential confusion, since the parser will throw an error if true/false is in CAPS when loading. Keep up the great work! yeah i wrote all in caps to draw attention  When i get some time i will change it here and in the docs too. Do you have any success with per.mem on ? Using it should allow to go for a bigger intensity setting, on my test card (580 8g) algo normalv7, the best setting was i:54 / w:8 / t:2 i got ~926hs , now i can go to i:60 without problems, and have ~933-936hs edit: i:63 ~940hs 
|
|
|
|
Bry Guy
Newbie
Offline
Activity: 11
Merit: 0
|
 |
June 09, 2018, 04:46:08 PM |
|
V1.6.0Do you have any success with per.mem on ? Using it should allow to go for a bigger intensity setting, on my test card (580 8g) algo normalv7, the best setting was i:54 / w:8 / t:2 i got ~926hs , now i can go to i:60 without problems, and have ~933-936hs edit: i:63 ~940hs  I am running on an 8xVega 56 rig. So far I have only tested v7 algo. With unchanged i:/w:/t: settings here are what my initial tests show (only ran for 15 mins each): Unchanged i:/w:/t: settings (i:112/w:8/t:2), average h/s per card:1.5.8 - 2016 h/s 1.6.0 - 2012 h/s (pmem: false) 1.6.0 - 2020 h/s (pmem: true) I can provide more test results later with different intensities and algos if helpful.
|
|
|
|
FFI2013
|
 |
June 09, 2018, 04:51:08 PM |
|
Would anyone have good settings for r9 cards I have r9 270/280 and r9 390 and using stock clocks with miner configured settings, I get 150-200 hs more with xmr-stak I'm also mining bittube with these
|
|
|
|
istr
Newbie
Offline
Activity: 24
Merit: 0
|
 |
June 09, 2018, 05:01:51 PM |
|
V1.6.0- Added support for Haven new algo after fork (block 89200) - Added support for Masari new algo (fast) after fork (block 204000) - Job timeout default is now 20 minutes - More logging on miner startup - Added option 'persistent_memory' in gpu_conf + 2 new algos added : 'haven' and 'fast' So after the fork you can use them like : "cryptonight_type" : "fast" "cryptonight_type" : "haven"+ As some have issues with miner 'just waiting some time' on startup, i added more logging option so we can catch where it hangs, and i can possibly fix that + 'persistent_memory' parameter added to gpu_conf, basically what it does is tries to allocate some memory that is normally not available to the GPU. It can increase hashrate in some ocassions, by finding the right intensity and threads setup, but also it can make the gpu crash, so it's up to you to experiment  I am still looking for the cause of random miner crashes (mostly on new 'great' win 1803 update), also for the abnormality that causes higher hashrate on after X runs. Hi Doc! as I told you before, you have to take a good look at memory usage in task manager for the first run after reboot and all the next ones. There is something strange there! Behaviour is different. PS. This doesn't happening in other miners.
|
|
|
|
knittycatkitty
Newbie
Offline
Activity: 19
Merit: 0
|
 |
June 09, 2018, 05:25:34 PM |
|
hi brother i'm getting interminent crash with 1.60 on some of my machines? miner doesn't start up past
GPU MAX ALLOC
I have 1.5.2 files on them still and those are running fine, any ideas?
UPDATE: nevermind, i figured it out. disable windows defender on all your miners and make sure you make an exception for srbminer. if it's already flagged, allow the app.
|
|
|
|
goran89
Newbie
Offline
Activity: 13
Merit: 0
|
 |
June 09, 2018, 05:40:54 PM |
|
Hi all I am using this miner for few months already and wanted to share my results. I have rig with 3x XFX RX 570 Black Edition and 2x Sapphire RX 580 Nitro+ all 4GB version. For 570 clock are 1220/890 and 2030/905 For 580 clock are 1230/885 and 2130/890 and full rig consumption from the wall is around 530W. With all versions of the miner I was getting around same speed (cryptonight v7 algo) with I58-W8-T2 570 - 953 H/s 580 - 1008 H/s Total around 4873 H/s Today I try new version 1.6.0 with persistent_memory and manage to increase intensity to 59 (with 60 miner crashed) and get this results 570 - 956 H/s 580 - 1010 H/s Total around 4888 H/s Not a big increase but it is better Hvala doktore za odlican miner 
|
|
|
|
ragecage
Newbie
Offline
Activity: 13
Merit: 0
|
 |
June 09, 2018, 06:17:50 PM |
|
how persistent_memory works?
|
|
|
|
doktor83 (OP)
|
 |
June 09, 2018, 06:32:55 PM |
|
V1.6.0- Added support for Haven new algo after fork (block 89200) - Added support for Masari new algo (fast) after fork (block 204000) - Job timeout default is now 20 minutes - More logging on miner startup - Added option 'persistent_memory' in gpu_conf + 2 new algos added : 'haven' and 'fast' So after the fork you can use them like : "cryptonight_type" : "fast" "cryptonight_type" : "haven"+ As some have issues with miner 'just waiting some time' on startup, i added more logging option so we can catch where it hangs, and i can possibly fix that + 'persistent_memory' parameter added to gpu_conf, basically what it does is tries to allocate some memory that is normally not available to the GPU. It can increase hashrate in some ocassions, by finding the right intensity and threads setup, but also it can make the gpu crash, so it's up to you to experiment  I am still looking for the cause of random miner crashes (mostly on new 'great' win 1803 update), also for the abnormality that causes higher hashrate on after X runs. Hi Doc! as I told you before, you have to take a good look at memory usage in task manager for the first run after reboot and all the next ones. There is something strange there! Behaviour is different. PS. This doesn't happening in other miners. did you test this on one card, a rig, or multiple rigs? All behave same? We are talking about memory usage for the miner, not the gpu (as you say task manager). On start miner 'eats' more memory, after that it slowly decreases over time.
|
|
|
|
altsay
|
 |
June 09, 2018, 06:33:07 PM |
|
1.5.8 shouldnt be faster than 1.5.9, cause nothing was changed that could impact speed. Placebo  unbelievable but true. my RX 550 2gb at 1.5.8 gave out stably 6590 hashes at setting 26/8/2, and on 1.5.9 neither as more than 6510 hashes  what happens on 27/8/2? in this case, everything is not stable, or the cards do not start all at once, but only after a couple of reboots and after that in a couple of hours all the same 0 the hashes are shown and the reboot is going on. But on the other hand, the speed on version 1.5.8 strongly diverged by the indications on the pool, and 1.5.9 shows approximately equal values with the pool. So we stay on 1.5.9  I think 6500 with 13 RX 550 cards is a good result, the main thing is that there would be stability. Thank you for the miner. So as of today, can we expect ~500 H/s from a typical Rx 550?
|
|
|
|
livada
Newbie
Offline
Activity: 417
Merit: 0
|
 |
June 09, 2018, 07:59:21 PM |
|
how i use this for all card without gpu conf?
"gpu_conf" : [ { "id" : 0, "intensity" : 120, "worksize" : 16, "threads" : 2}, { "id" : 1, "intensity" : 120, "worksize" : 16, "threads" : 2}, { "id" : 2, "intensity" : 120, "worksize" : 16, "threads" : 2},
] }
this is not work
"intensity" : 120, "worksize" : 16, "double_threads" : true,
W alwys 8 not 16
|
|
|
|
YukiSG
Newbie
Offline
Activity: 4
Merit: 0
|
 |
June 09, 2018, 08:17:37 PM Last edit: June 09, 2018, 10:02:28 PM by YukiSG |
|
Kill windows 1803 update with fire: Here's what we have so far about win 1803 update effect on me, after applying all known fixes:
I can't get all 13 gpus to work above 900 h/s each, a very low intensity seems to work. I used to do stable 1040 h/s. Hash rate fluctuates badly. GPU-Z trick does NOT work.
tldr, Windows 1803 update is utter bullshit. I failed to prevent it from installing, so it's my fault. I'm thinking of leaving to a miner Os, I hope SRBMiner adds linux compatibility.
For those who are affected by Windows 10 1803 updates. Fix is here no worries. Roll back to previous version. 1.To get started, click Start and then Settings. 2.Click on Update & security. 3.In the sidebar, choose Recovery. 4.Click the Get Started link under Go back to the previous version of Windows 10. 5.Select why you'd like to go back to a previous build and click Next. ... 6.Click Next once more after reading the prompt 7. Wait for it to finish rolling back and reboot. Part 2 of the fix. (To disable windows update) Optional: Its actually better to update to latest AMD Adrenaline Driver as it actually performs better than Blockchain Beta Driver FYI. 1. Windows Button + R and run services.msc 2. type in "Services.msc" Without the quote. 3. Scroll down to Windows Update and right click it and select Properties. 4. Change Startup Type to Disabled and click Stop and go to Recovery tab and on First Failure change it to "Take no Action" 5. Click apply and followed by OK. 6. Reboot PC and ur windows update is disable ( you can re-enable it in the future by reversing step 4 in the future when they finally Microsoft fix their own shit) 7. Reinstall any programs you have installed AFTER the 1803 update as they will be missing. The benefit of rolling back also fixes AtiFlash as in Version 1803 u are unable to use ATIFlasher due to compatibility issues. Like my work/Discovery? Donate me to help me clear my debt. ETH: 0x052898045e73a56691eca5210EE6a2Aa15397295 Edit. Added step 7 into part 2.
|
|
|
|
wudafuxup
|
 |
June 09, 2018, 09:58:57 PM |
|
Kill windows 1803 update with fire: Here's what we have so far about win 1803 update effect on me, after applying all known fixes:
I can't get all 13 gpus to work above 900 h/s each, a very low intensity seems to work. I used to do stable 1040 h/s. Hash rate fluctuates badly. GPU-Z trick does NOT work.
tldr, Windows 1803 update is utter bullshit. I failed to prevent it from installing, so it's my fault. I'm thinking of leaving to a miner Os, I hope SRBMiner adds linux compatibility.
For those who are affected by Windows 10 1803 updates. Fix is here no worries. Roll back to previous version. 1.To get started, click Start and then Settings. 2.Click on Update & security. 3.In the sidebar, choose Recovery. 4.Click the Get Started link under Go back to the previous version of Windows 10. 5.Select why you'd like to go back to a previous build and click Next. ... 6.Click Next once more after reading the prompt 7. Wait for it to finish rolling back and reboot. Part 2 of the fix. (To disable windows update) Optional: Its actually better to update to latest AMD Adrenaline Driver as it actually performs better than Blockchain Beta Driver FYI. 1. Windows Button + R and run services.msc 2. type in "Services.msc" Without the quote. 3. Scroll down to Windows Update and right click it and select Properties. 4. Change Startup Type to Disabled and click Stop and go to Recovery tab and on First Failure change it to "Take no Action" 5. Click apply and followed by OK. 6. Reboot PC and ur windows update is disable ( you can re-enable it in the future by reversing step 4 in the future when they finally Microsoft fix their own shit) The benefit of rolling back also fixes AtiFlash as in Version 1803 u are unable to use ATIFlasher due to compatibility issues. Like my work/Discovery? Donate me to help me clear my debt. ETH: 0x052898045e73a56691eca5210EE6a2Aa15397295 You literally copy and pasted from laptomags article on how to roll back lmao. Gtfo... You also forgot to mention rolling back won't work after 7 days of the update.
|
I like crypto
|
|
|
|