Topic: SRBMiner Cryptonight AMD GPU Miner V1.9.3 - native algo switching - page 229. (Read 237263 times)
June 09, 2018, 11:51:08 AM
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
June 09, 2018, 11:46:08 AM
V1.6.0
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
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
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.
June 09, 2018, 11:24:20 AM
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
- 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
June 09, 2018, 10:57:47 AM
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
- 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!
June 09, 2018, 10:56:29 AM
[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
[2018-06-08 23:07:33] Error initing GPU's. Stopping miner process
what caused the error ?
June 09, 2018, 10:43:53 AM
[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
[2018-06-08 23:07:33] Error initing GPU's. Stopping miner process
what caused the error ?
June 09, 2018, 09:47:06 AM
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 !
Today v1.3.2 fixed temp & RPM readings on my rig, stability seems very good
Great job ! Thanks !
June 09, 2018, 09:15:29 AM
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
Thanks
June 09, 2018, 09:11:19 AM
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.
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?
June 09, 2018, 09:08:53 AM
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.
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
June 09, 2018, 09:05:51 AM
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.
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?
June 09, 2018, 08:59:06 AM
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.
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.
June 09, 2018, 08:46:51 AM
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.
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.
I think it's more easy to just go back to an earlier build of Windows 10, that solved my problem.
http://www.thewindowsclub.com/go-back-to-an-earlier-build-of-windows-10
Doing this as we speak, great tip, I honestly thought it was only possible with windows restore turned on, which I had turned off.
Awesome..
June 09, 2018, 08:21:30 AM
@ dok
I am so sorry, i saw you have done changes on DevFee.
I just wanted to report it was really never caused by DevFee, it was just a coincidence.
I don't use Windows 10 for personal use, i have used only Windows 7 before very well.
So i never looked in to the new Settings Panel of the "metro" gui, i just prefer to use old windows settings windows.
Seems to that i have to adopt the new Settings panels.
Sorry again, best miner we have ever seen, happy to know that you get your well deserved fees
I am so sorry, i saw you have done changes on DevFee.
I just wanted to report it was really never caused by DevFee, it was just a coincidence.
I don't use Windows 10 for personal use, i have used only Windows 7 before very well.
So i never looked in to the new Settings Panel of the "metro" gui, i just prefer to use old windows settings windows.
Seems to that i have to adopt the new Settings panels.
Sorry again, best miner we have ever seen, happy to know that you get your well deserved fees
June 09, 2018, 08:17:32 AM
I think I can confirm...
After the difficulty monitor is executed for 4th time the program closes itself
[2018-06-09 15:01:33] Connection to pool lost. Reconnecting in 10 seconds.
And the program is closed.
After the difficulty monitor is executed for 4th time the program closes itself
[2018-06-09 15:01:33] Connection to pool lost. Reconnecting in 10 seconds.
And the program is closed.
i will check it out.
Also it's not triggerring momentally when the set difficulty is reached. Check is made every 45 seconds.
No point setting it for ex 1 sec because it just eats up cpu resources, and i think its not THAT important to disconnect momentally.
But correct me if i am wrong.
June 09, 2018, 08:08:28 AM
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.
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.
I think it's more easy to just go back to an earlier build of Windows 10, that solved my problem.
http://www.thewindowsclub.com/go-back-to-an-earlier-build-of-windows-10
June 09, 2018, 08:06:42 AM
I think I can confirm...
After the difficulty monitor is executed for 4th time the program closes itself
[2018-06-09 15:01:33] Connection to pool lost. Reconnecting in 10 seconds.
And the program is closed.
After the difficulty monitor is executed for 4th time the program closes itself
[2018-06-09 15:01:33] Connection to pool lost. Reconnecting in 10 seconds.
And the program is closed.
June 09, 2018, 07:50:01 AM
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.
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.
June 09, 2018, 07:30:48 AM
Here is what is slowing down the startup:
[2018-06-09 13:52:22] CryptonightV7 mode enabled
[2018-06-09 13:53:46] DevFee pool SET
[2018-06-09 13:53:46] DevFee address SET
[2018-06-09 13:53:46] Starting init of mining threads
The difficulty monitor is slow responding & varies alot, the fastest I had after 4 times have been 12 seconds:
[2018-06-09 13:56:38] pool_have_job: Pool difficulty: 60000
[2018-06-09 13:56:38] pool_have_job: Pool sent a new job (ID: 487651957152411)
[2018-06-09 13:56:50] difficulty_monitor: Difficulty (60000) is higher than the defined max difficulty for this pool (40000)!
And the worst 42 seconds
Also, after running the program for a few minutes it closed without advice
[2018-06-09 13:52:22] CryptonightV7 mode enabled
[2018-06-09 13:53:46] DevFee pool SET
[2018-06-09 13:53:46] DevFee address SET
[2018-06-09 13:53:46] Starting init of mining threads
The difficulty monitor is slow responding & varies alot, the fastest I had after 4 times have been 12 seconds:
[2018-06-09 13:56:38] pool_have_job: Pool difficulty: 60000
[2018-06-09 13:56:38] pool_have_job: Pool sent a new job (ID: 487651957152411)
[2018-06-09 13:56:50] difficulty_monitor: Difficulty (60000) is higher than the defined max difficulty for this pool (40000)!
And the worst 42 seconds
Also, after running the program for a few minutes it closed without advice
June 09, 2018, 06:25:26 AM
[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
[2018-06-08 23:07:33] Error initing GPU's. Stopping miner process
Jump to: