Topic: WildRig Multi 0.35.1 beta 2 multi-algo miner for AMD & NVIDIA - page 30. (Read 92264 times)
Any help how to best settings for mining on Algo HoneyComb _BeeNode_ on RX 470 , thanks
0.16.3 beta
- continue improve some hashorders for x16 family(JH512 in middle, SIMD at start)
- special improvement for Vega on almost all algorithms(bcd, x16-fmaily, hex, x22i, etc.)
- honeycomb optimization
- added parameter --no-extranonce
- added parameter --scratchpad-full-update
- continue improve some hashorders for x16 family(JH512 in middle, SIMD at start)
- special improvement for Vega on almost all algorithms(bcd, x16-fmaily, hex, x22i, etc.)
- honeycomb optimization
- added parameter --no-extranonce
- added parameter --scratchpad-full-update
SORRY FOR THE DELAY--
I just installed and started the new miner with the same launch parameters as yesterday, "auto" and no overclocks, and "safe scratchpad update". The launch went the same as usual, same hashrate, etc. I'll post on progress. Thanks! --scryptr
EDIT(S): After ~90 minutes, 270 accepts / 2 rejects (270/2), 12MH/s for the rig, ~95W and 0.972V per GPU reported at console.
After ~3 hours, 567/9, 12MH/s for the rig, ~95W and 0.972V per GPU reported at the console.
After ~4.5 hours, 790/9, 12MH/s for the rig, ~95W and 0.972V per GPU reported at the console.
After ~6 hours, 995/33, 12MH/s for the rig, ~95W and 0.972V per GPU at the console.
So, looks like definitely something wrong with calculation code when compiling it with old GCC... I will release 0.16.3 final build today, with parameter --scratchpad-full-update. That should help, but will slightly decrease avg. hashrate on low-speed reisers. I just installed and started the new miner with the same launch parameters as yesterday, "auto" and no overclocks, and "safe scratchpad update". The launch went the same as usual, same hashrate, etc. I'll post on progress. Thanks! --scryptr
EDIT(S): After ~90 minutes, 270 accepts / 2 rejects (270/2), 12MH/s for the rig, ~95W and 0.972V per GPU reported at console.
After ~3 hours, 567/9, 12MH/s for the rig, ~95W and 0.972V per GPU reported at the console.
After ~4.5 hours, 790/9, 12MH/s for the rig, ~95W and 0.972V per GPU reported at the console.
After ~6 hours, 995/33, 12MH/s for the rig, ~95W and 0.972V per GPU at the console.
Rainforest v2 coming soon?
Unfortunately no. MBC market is dry, no sense to spend time on it. Also don't forget about how many coins were mined before by private pool, and at start of rf2 fork. I am eagerly awaiting v16.3!
Are you reading my messages? %) I have already uploaded 0.16.3 for you and gave a link to test with parameter --scratchpad-safe-updateNO MESSAGE--
If you sent something by forum mail, I did not receive it. I checked yesterday and today. Today I also checked my forum mail options, and you should not be blocked. Please re-send, thanks. --scryptr
Rainforest v2 coming soon?
SORRY FOR THE DELAY--
I just installed and started the new miner with the same launch parameters as yesterday, "auto" and no overclocks, and "safe scratchpad update". The launch went the same as usual, same hashrate, etc. I'll post on progress. Thanks! --scryptr
EDIT(S): After ~90 minutes, 270 accepts / 2 rejects (270/2), 12MH/s for the rig, ~95W and 0.972V per GPU reported at console.
After ~3 hours, 567/9, 12MH/s for the rig, ~95W and 0.972V per GPU reported at the console.
After ~4.5 hours, 790/9, 12MH/s for the rig, ~95W and 0.972V per GPU reported at the console.
After ~6 hours, 995/33, 12MH/s for the rig, ~95W and 0.972V per GPU at the console.
After ~12 hours, 1880/103, 12MH/s for the rig, ~95W and 0.972V per GPU at the console.
I had to leave the console for a few hours. Good to hear about the release of v16.3! --scryptr
I just installed and started the new miner with the same launch parameters as yesterday, "auto" and no overclocks, and "safe scratchpad update". The launch went the same as usual, same hashrate, etc. I'll post on progress. Thanks! --scryptr
EDIT(S): After ~90 minutes, 270 accepts / 2 rejects (270/2), 12MH/s for the rig, ~95W and 0.972V per GPU reported at console.
After ~3 hours, 567/9, 12MH/s for the rig, ~95W and 0.972V per GPU reported at the console.
After ~4.5 hours, 790/9, 12MH/s for the rig, ~95W and 0.972V per GPU reported at the console.
After ~6 hours, 995/33, 12MH/s for the rig, ~95W and 0.972V per GPU at the console.
After ~12 hours, 1880/103, 12MH/s for the rig, ~95W and 0.972V per GPU at the console.
I had to leave the console for a few hours. Good to hear about the release of v16.3! --scryptr
I am eagerly awaiting v16.3!
Are you reading my messages? %) I have already uploaded 0.16.3 for you and gave a link to test with parameter --scratchpad-safe-updateNO MESSAGE--
If you sent something by forum mail, I did not receive it. I checked yesterday and today. Today I also checked my forum mail options, and you should not be blocked. Please re-send, thanks. --scryptr
I am eagerly awaiting v16.3!
Are you reading my messages? %) I have already uploaded 0.16.3 for you and gave a link to test with parameter --scratchpad-safe-updateNO MESSAGE--
If you sent something by forum mail, I did not receive it. I checked yesterday and today. Today I also checked my forum mail options, and you should not be blocked. Please re-send, thanks. --scryptr
Giving boolberry a wirl now.
2mhs for rx570
4.3mhs for vega.
21.5mhs for 890W at the wall.
2mhs for rx570
4.3mhs for vega.
21.5mhs for 890W at the wall.
I am eagerly awaiting v16.3!
Are you reading my messages? %) I have already uploaded 0.16.3 for you and gave a link to test with parameter --scratchpad-safe-update
LOOK MA, NO CLOCK SETTINGS! --
I started WildRig-Multi v16.2 with no clock settings in the configuration in order to see what happened. As before, "opencl-threads" and "opencl-launch" were set to "=auto", and the "safe-scratchpad-update" flag was used. This is what I got:
WildRig v16.2 clean launch
When I checked my statistics, the cards were running at 1266/2000 at about 95W per GPU. As you can see, the rig has run for only a short time. The rig was hard-rebooted prior to this launch. The first two cards (0,1) have Samsung memory. The hardware self-adjusted on launch.
Prior runs always resulted in a greater amount of rejects after an extended period. --scryptr
EDIT: After 2 hours and a few minutes:
Smooth run so far.
I am beginning to have hopes! --scryptr
EDIT After 4 hours and a few minutes:
Rejects begin to occur.
More than 10% rejects again, with no configuration changes. I am eagerly awaiting v16.3! Thanks... --scryptr
I started WildRig-Multi v16.2 with no clock settings in the configuration in order to see what happened. As before, "opencl-threads" and "opencl-launch" were set to "=auto", and the "safe-scratchpad-update" flag was used. This is what I got:
WildRig v16.2 clean launch
When I checked my statistics, the cards were running at 1266/2000 at about 95W per GPU. As you can see, the rig has run for only a short time. The rig was hard-rebooted prior to this launch. The first two cards (0,1) have Samsung memory. The hardware self-adjusted on launch.
Prior runs always resulted in a greater amount of rejects after an extended period. --scryptr
EDIT: After 2 hours and a few minutes:
Smooth run so far.
I am beginning to have hopes! --scryptr
EDIT After 4 hours and a few minutes:
Rejects begin to occur.
More than 10% rejects again, with no configuration changes. I am eagerly awaiting v16.3! Thanks... --scryptr
+1 for Rainforest v2, the first Rainforest made my 290X profitable at 195TH
Man, new version is 0.16.3, you tested old one. Please update to that I sent you. What about a crash - looks like problem of new version of libuv library... %)
OK--
I need to download and set up the program. I currently have 320 accepts with 4 rejects after the restart that I captured. Thanks for working with me.
--scryptr
INITIAL RESULTS--
I ran v16.2 at 1100/2000 for about 75 accepts, with both "opencl_threads" and "opencl-launch" set "=auto". No rejects occured. I watched a movie on the monitor, and rechecked the rig. When I looked, about 2 hours after launch, there were more than 10% rejects.
I stopped the miner with the ethOS command "minestop". The miner stopped and immediately relaunched. After 51 accepts (just now) there are no rejects. Hash rate is 11.4MH/s for the rig and 1.9MH/s per card. If I run the rig with no clock ettings I get 11MH/s for the rig, but I have not done so for an extended period.
Does this point to a memory leak? --scryptr
This point to some unknown problem, but with known symptoms - rejects after hour or so. Probably something wrong with gcc I use on Ubuntu 16.04 when compile the miner %) Because no problems on Windows so far. And strange that you didn't get same problem with 0.10.5, some people were reporting the same. Can you please try this build with parameter --scratchpad-safe-update?I ran v16.2 at 1100/2000 for about 75 accepts, with both "opencl_threads" and "opencl-launch" set "=auto". No rejects occured. I watched a movie on the monitor, and rechecked the rig. When I looked, about 2 hours after launch, there were more than 10% rejects.
I stopped the miner with the ethOS command "minestop". The miner stopped and immediately relaunched. After 51 accepts (just now) there are no rejects. Hash rate is 11.4MH/s for the rig and 1.9MH/s per card. If I run the rig with no clock ettings I get 11MH/s for the rig, but I have not done so for an extended period.
Does this point to a memory leak? --scryptr
WILL DO--
After 110 accepts, 0 rejects, I got 4 rejects before 120 accepts. Different cards produced the rejects. I will edit the config and use your suggestion.
--scryptr
DONE--
This is what I got:
Error message with restart after 2 rejects.
I hope this helps. I was able to capture this after the first rejects once I included "--scratchpad-safe-update" in the configuration file.
--scryptr
EDIT: There is a post in the BoolBerry thread. It may apply. Here is the link: https://bitcointalksearch.org/topic/m.50650017
--scryptr
INITIAL RESULTS--
I ran v16.2 at 1100/2000 for about 75 accepts, with both "opencl_threads" and "opencl-launch" set "=auto". No rejects occured. I watched a movie on the monitor, and rechecked the rig. When I looked, about 2 hours after launch, there were more than 10% rejects.
I stopped the miner with the ethOS command "minestop". The miner stopped and immediately relaunched. After 51 accepts (just now) there are no rejects. Hash rate is 11.4MH/s for the rig and 1.9MH/s per card. If I run the rig with no clock ettings I get 11MH/s for the rig, but I have not done so for an extended period.
Does this point to a memory leak? --scryptr
This point to some unknown problem, but with known symptoms - rejects after hour or so. Probably something wrong with gcc I use on Ubuntu 16.04 when compile the miner %) Because no problems on Windows so far. And strange that you didn't get same problem with 0.10.5, some people were reporting the same. Can you please try this build with parameter --scratchpad-safe-update?I ran v16.2 at 1100/2000 for about 75 accepts, with both "opencl_threads" and "opencl-launch" set "=auto". No rejects occured. I watched a movie on the monitor, and rechecked the rig. When I looked, about 2 hours after launch, there were more than 10% rejects.
I stopped the miner with the ethOS command "minestop". The miner stopped and immediately relaunched. After 51 accepts (just now) there are no rejects. Hash rate is 11.4MH/s for the rig and 1.9MH/s per card. If I run the rig with no clock ettings I get 11MH/s for the rig, but I have not done so for an extended period.
Does this point to a memory leak? --scryptr
WILL DO--
After 110 accepts, 0 rejects, I got 4 rejects before 120 accepts. Different cards produced the rejects. I will edit the config and use your suggestion.
--scryptr
DONE--
This is what I got:
Error message with restart after 2 rejects.
I hope this helps. I was able to capture this after the first rejects once I included "--scratchpad-safe-update" in the configuration file.
--scryptr
EDIT: There is a post in the BoolBerry thread. It may apply. Here is the link: https://bitcointalksearch.org/topic/m.50650017
--scryptr
INITIAL RESULTS--
I ran v16.2 at 1100/2000 for about 75 accepts, with both "opencl_threads" and "opencl-launch" set "=auto". No rejects occured. I watched a movie on the monitor, and rechecked the rig. When I looked, about 2 hours after launch, there were more than 10% rejects.
I stopped the miner with the ethOS command "minestop". The miner stopped and immediately relaunched. After 51 accepts (just now) there are no rejects. Hash rate is 11.4MH/s for the rig and 1.9MH/s per card. If I run the rig with no clock ettings I get 11MH/s for the rig, but I have not done so for an extended period.
Does this point to a memory leak? --scryptr
This point to some unknown problem, but with known symptoms - rejects after hour or so. Probably something wrong with gcc I use on Ubuntu 16.04 when compile the miner %) Because no problems on Windows so far. And strange that you didn't get same problem with 0.10.5, some people were reporting the same. Can you please try this build with parameter --scratchpad-safe-update? I ran v16.2 at 1100/2000 for about 75 accepts, with both "opencl_threads" and "opencl-launch" set "=auto". No rejects occured. I watched a movie on the monitor, and rechecked the rig. When I looked, about 2 hours after launch, there were more than 10% rejects.
I stopped the miner with the ethOS command "minestop". The miner stopped and immediately relaunched. After 51 accepts (just now) there are no rejects. Hash rate is 11.4MH/s for the rig and 1.9MH/s per card. If I run the rig with no clock ettings I get 11MH/s for the rig, but I have not done so for an extended period.
Does this point to a memory leak? --scryptr
INITIAL RESULTS--
I ran v16.2 at 1100/2000 for about 75 accepts, with both "opencl_threads" and "opencl-launch" set "=auto". No rejects occured. I watched a movie on the monitor, and rechecked the rig. When I looked, about 2 hours after launch, there were more than 10% rejects.
I stopped the miner with the ethOS command "minestop". The miner stopped and immediately relaunched. After 51 accepts (just now) there are no rejects. Hash rate is 11.4MH/s for the rig and 1.9MH/s per card. If I run the rig with no clock ettings I get 11MH/s for the rig, but I have not done so for an extended period.
Does this point to a memory leak? --scryptr
P.S The movie was played on a separate DVD player, not the PC with the mining rig. And, 100 accepts with no rejects. --scryptr
I ran v16.2 at 1100/2000 for about 75 accepts, with both "opencl_threads" and "opencl-launch" set "=auto". No rejects occured. I watched a movie on the monitor, and rechecked the rig. When I looked, about 2 hours after launch, there were more than 10% rejects.
I stopped the miner with the ethOS command "minestop". The miner stopped and immediately relaunched. After 51 accepts (just now) there are no rejects. Hash rate is 11.4MH/s for the rig and 1.9MH/s per card. If I run the rig with no clock ettings I get 11MH/s for the rig, but I have not done so for an extended period.
Does this point to a memory leak? --scryptr
P.S The movie was played on a separate DVD player, not the PC with the mining rig. And, 100 accepts with no rejects. --scryptr
I am connected by ssh and my rig is headless. The use of Pause (p) and Resume (r) does not seem to work. The miner keeps mining, and rejects are not lessened. I am gettig at least 10% rejects.
Idea was to wait when you get rejects. Remember their number, then press p and r and check will that amount increase or not in next 20-30 minutes.Got it stable on beenode. 1380 core 930mv 41mhs.
Have no idea if its good or not but doesn't look too bad profit wise
My rx550s get 4.5mhs so I will keep them on XMR instead
Yeah, low-end cards are good only on memory-hard algorithms, and almost useless when you need compute power Have no idea if its good or not but doesn't look too bad profit wise
My rx550s get 4.5mhs so I will keep them on XMR instead
Try 1150/1750, so memory will be stock. No sense to reduce core(core can provide wrong results as I remember only on Vega).
DEFAULT/STOCK IS 1350/2000--
I tried 1150/1750 and the hash rate dropped to 1.6MH/s per GPU, ~10MH/s for the rig. After changing the configuration to 1150/2000 and rebooting, the rig seemed to behave well. While I was outside it was mining ok at 1100/2000 clocks, with 345 accepts and 6 rejects at 11.5MH/s for the rig.
Currently, the rig shows 100 accepts with 1 reject at 1150/2000, and the rig is hashing at 11.75MH/s. It has been mining for about 40 minutes. Maybe it can be pushed harder somehow, but it seems ok. The wattage per card is less than 90W in the console report. --scryptr
I WILL TRY THAT--
Just getting my coffee today, and taking a look at the rig. Generally, I am seeing more rejects than with WildRig 10.5. I will download the latest release and work with it rather than my currently installed v16.0 WildRig-Multi.
Bottom line: I get higher hashrates but produce less BoolBerry since using WildRig-Multi. --scryptr
PAUSE AND RESUME DO NOT HELP--
I am connected by ssh and my rig is headless. The use of Pause (p) and Resume (r) does not seem to work. The miner keeps mining, and rejects are not lessened. I am gettig at least 10% rejects.
If I start with only "auto" sttings, the hash rate is about 11MH/s, and less than the stable 11.4MH/s when running WildRig 10.5. With clocks at 1100/2000 and intensity at 21x0, the hash rate is 11.5MH/s with v16.2, but the rejects are a problem (10%+). I have not run the miner at just "auto" and default intensity for a long period, I will do so overnight just to get a baseline.
--scryptr
Got it stable on beenode. 1380 core 930mv 41mhs.
Have no idea if its good or not but doesn't look too bad profit wise
My rx550s get 4.5mhs so I will keep them on XMR instead
Have no idea if its good or not but doesn't look too bad profit wise
My rx550s get 4.5mhs so I will keep them on XMR instead
Jump to: