laik2
|
|
March 03, 2019, 10:51:41 AM |
|
i get this on RX580 and Vega56 rigs running 15.1 on Hive
OpenCL Error '-11' in func 'InitializeCLEnvironment' line 51
how to solve it?
Ask them, and here is a hint: Experimental support Cuckaroo29 on AMD cards ( ROCM only).
|
|
|
|
|
|
|
If you see garbage posts (off-topic, trolling, spam, no point, etc.), use the "report to moderator" links. All reports are investigated, though you will rarely be contacted about your reports.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
cryptoyes
Member
Offline
Activity: 297
Merit: 10
|
|
March 03, 2019, 04:04:43 PM |
|
The malloc and CopyEdges errors are FINALLY gone in 15.1.0. Thanks! No need, this one works fine, it is a problem with pools depending on your geolocation. For me, luxor gives 99.98% accepted, f2pool is at 85%, grinmint is at 95%, and it is the same with any miner, so it is not the miner, but the pool.
Yep, it's now known that Luxor has close to 100% accepted share rate while all other are below 96-95%, sometimes much lower. I tested: - f2pool - sparkpool - grinmint - btc.com - mwgrinpool - grin-pool I haven't had a chance to test nanopool.org which recently added grin29 (but hasn't yet added grin31). Sadly, Luxor is underpaying by about 10-15% over a 24h window. You need to take the average network difficulty for the whole 24h to compute the pay that you should be getting. You can extract that from the blocks, or roughly extract it from the graphs on the online explorers.
|
|
|
|
|
sirkorro
Newbie
Offline
Activity: 29
Merit: 0
|
|
March 03, 2019, 08:11:50 PM |
|
Looks like internet provider issue.
|
|
|
|
topteam
Newbie
Offline
Activity: 157
Merit: 0
|
|
March 03, 2019, 08:51:22 PM |
|
Looks like internet provider issue.
no, outside red rectangle i use another miner
|
|
|
|
sirkorro
Newbie
Offline
Activity: 29
Merit: 0
|
|
March 03, 2019, 09:05:44 PM |
|
no, outside red rectangle i use another miner Got it. Less then 2% of rejects seems about right for bminer 15.1. Prior to 15.1 I've got up to 8%. ~25% is way to much. Which miner do you used before/after? BTW. which algo/card are we talking about?
|
|
|
|
pbfarmer
Member
Offline
Activity: 340
Merit: 29
|
|
March 03, 2019, 09:59:06 PM |
|
Just a quick benchmark and feedback on testing Vega64 with bminer-15.1.0(c29) with our OS.
Clocks: GfxClk 1250, MemClk 1050, Voltage: 850mV Hashrate c29: 3.60-3.80gps(Smart Tune set to auto). We experienced a bit high CPU usage for some reason which caused miner to hang on trying to kill it, eventually reboot was required to return to normal. Cheers for the good work!
Why so low on the gfx clock? Grin is core-intensive, so you want to have that as high as possible for your desired power-envelope. Also, you can likely lock out your top mem power state to get your SOC to downclock and save some power. Any chance you can post some numbers w/ at least 1300-1400Mhz measured (actual) core clock, and 800Mhz mem clock (p3 disabled)?
|
|
|
|
laik2
|
|
March 03, 2019, 11:31:43 PM Last edit: March 04, 2019, 12:52:10 AM by laik2 |
|
Just a quick benchmark and feedback on testing Vega64 with bminer-15.1.0(c29) with our OS.
Clocks: GfxClk 1250, MemClk 1050, Voltage: 850mV Hashrate c29: 3.60-3.80gps(Smart Tune set to auto). We experienced a bit high CPU usage for some reason which caused miner to hang on trying to kill it, eventually reboot was required to return to normal. Cheers for the good work!
Why so low on the gfx clock? Grin is core-intensive, so you want to have that as high as possible for your desired power-envelope. Also, you can likely lock out your top mem power state to get your SOC to downclock and save some power. Any chance you can post some numbers w/ at least 1300-1400Mhz measured (actual) core clock, and 800Mhz mem clock (p3 disabled)? Didn't quite get what you mean by SoC downclock, if you refer to soc state its irrelevant, if you refer to frequency, we set it just 1Mhz above memory clock, p3 doesn't need to be disabled, if you set memory to lower than P2 or equal it will simply go there. Power usage was the factor we were seeking with that low core and no, grin is not entirely core intensive, its memory bound algorithm(not hard) that can benefit of slight overclock of memory in some cases. We are preparing benchmarks on all algorithms supported by our OS and will post them sometime next week. P.S. Here are some tests with your settings: [GPU 0] Speed: 3.44 G/s Fidelity 0.784 Temp: 56C Fan: 40% Power: 105W 0.03 G/J - gfx 1220, mem 800, volt 850(seems stable between 3.40-3.44) [GPU 0] Speed: 3.80 G/s Fidelity 0.378 Temp: 48C Fan: 36% Power: 20W 0.19 G/J - gfx 1400, mem 800, volt 900(seems stable between 3.66-3.80) [GPU 0] Speed: 4.20 G/s Fidelity 1.810 Temp: 52C Fan: 37% Power: 21W 0.20 G/J - gfx 1400, mem 1050(smart tune to low), volt 900 [GPU 0] Speed: 4.00 G/s Fidelity 0.952 Temp: 56C Fan: 40% Power: 128W 0.03 G/J - gfx 1400, mem 1050(smart tune low), volt 900(stable) [GPU 0] Speed: 3.80 G/s Fidelity 2.423 Temp: 52C Fan: 22% Power: 18W 0.21 G/J - gfx 1220, mem 1050(smart tune low), volt 850 [GPU 0] Speed: 3.62 G/s Fidelity 0.993 Temp: 55C Fan: 40% Power: 108W 0.03 G/J - gfx 1220, mem 1050(smart tune low), volt 850(stable) Hope that reveals that cuckoo is not exactly core intensive
|
|
|
|
pbfarmer
Member
Offline
Activity: 340
Merit: 29
|
|
March 04, 2019, 02:51:39 AM |
|
Just a quick benchmark and feedback on testing Vega64 with bminer-15.1.0(c29) with our OS.
Clocks: GfxClk 1250, MemClk 1050, Voltage: 850mV Hashrate c29: 3.60-3.80gps(Smart Tune set to auto). We experienced a bit high CPU usage for some reason which caused miner to hang on trying to kill it, eventually reboot was required to return to normal. Cheers for the good work!
Why so low on the gfx clock? Grin is core-intensive, so you want to have that as high as possible for your desired power-envelope. Also, you can likely lock out your top mem power state to get your SOC to downclock and save some power. Any chance you can post some numbers w/ at least 1300-1400Mhz measured (actual) core clock, and 800Mhz mem clock (p3 disabled)? Didn't quite get what you mean by SoC downclock, if you refer to soc state its irrelevant, if you refer to frequency, we set it just 1Mhz above memory clock, p3 doesn't need to be disabled, if you set memory to lower than P2 or equal it will simply go there. Power usage was the factor we were seeking with that low core and no, grin is not entirely core intensive, its memory bound algorithm(not hard) that can benefit of slight overclock of memory in some cases. We are preparing benchmarks on all algorithms supported by our OS and will post them sometime next week. P.S. Here are some tests with your settings: [GPU 0] Speed: 3.44 G/s Fidelity 0.784 Temp: 56C Fan: 40% Power: 105W 0.03 G/J - gfx 1220, mem 800, volt 850(seems stable between 3.40-3.44) [GPU 0] Speed: 3.80 G/s Fidelity 0.378 Temp: 48C Fan: 36% Power: 20W 0.19 G/J - gfx 1400, mem 800, volt 900(seems stable between 3.66-3.80) [GPU 0] Speed: 4.20 G/s Fidelity 1.810 Temp: 52C Fan: 37% Power: 21W 0.20 G/J - gfx 1400, mem 1050(smart tune to low), volt 900 [GPU 0] Speed: 4.00 G/s Fidelity 0.952 Temp: 56C Fan: 40% Power: 128W 0.03 G/J - gfx 1400, mem 1050(smart tune low), volt 900(stable) [GPU 0] Speed: 3.80 G/s Fidelity 2.423 Temp: 52C Fan: 22% Power: 18W 0.21 G/J - gfx 1220, mem 1050(smart tune low), volt 850 [GPU 0] Speed: 3.62 G/s Fidelity 0.993 Temp: 55C Fan: 40% Power: 108W 0.03 G/J - gfx 1220, mem 1050(smart tune low), volt 850(stable) Hope that reveals that cuckoo is not exactly core intensive Maybe it's just that the other miners are unoptimized / not fully utilizing the GPU then, but on GGM/GrinPro for instance, dropping the mem clock from 1107 to 800Mhz results in only about a 3% h/r reduction. Core clock changes (esp that large) have a much more significant effect. Of course, GGM/GrinPro is only getting ~3.35 for a 1300 effective core clock, so again, maybe things are different w/ bminer having opened up the gpu a bit more. Regarding SOC, at least in windows, it appeared that each mem state has an allowable minimum for SOC clocks. For instance, setting 800MHz for mem P3 would still run 1107Mhz for SOC, so it was better to lock out P3, which would then allow SOC to drop down to 800Mhz. Setting duplicate/out-of-order clocks always seemed to cause strange or inconsistent behavior, so I tend to avoid it. And while SOC clocks should be modifiable via PPT, it simply never worked (in Windows) from my tests. Maybe things are different in linux, but the state disabling works, so I've stuck w/ it. I guess I'll get to experimenting w/ this myself - just wanted to make sure there was an appreciable difference worth spending time on.
|
|
|
|
topteam
Newbie
Offline
Activity: 157
Merit: 0
|
|
March 04, 2019, 05:39:31 AM |
|
no, outside red rectangle i use another miner Got it. Less then 2% of rejects seems about right for bminer 15.1. Prior to 15.1 I've got up to 8%. ~25% is way to much. Which miner do you used before/after? BTW. which algo/card are we talking about? C31, 1070+1070ti
|
|
|
|
laik2
|
|
March 04, 2019, 09:12:48 AM |
|
@pbfarmer Its complicated with vega powerplay table, but we managed to make it work, SoC state doesn't make difference now. The "Smart Tune" I am refering is exclusive feature in our OS that makes some adjustments to memory timings runtime so it speeds up memory bound/hard algorithms like ethash, equihash and possibliy cuckoo(as seen above).
|
|
|
|
RivAngE
Full Member
Offline
Activity: 728
Merit: 169
What doesn't kill you, makes you stronger
|
|
March 04, 2019, 11:21:20 AM |
|
Have you noticed any difference while mining Cuckoo (grin) 29 or 31 and having ETHpill on? For 29 I haven't noticed any difference with my 1080ti. For the 31 I haven't managed to try it since I don't know how to run ETHpill in Linux. On their GitHub ( https://github.com/admin-ipfs/OhGodAnETHlargementPill) the readme ("prescription" lol) is asking us to unzip the .gz file, but I don't see any .gz file. There's a "OhGodAnETHlargementPill-r2" without any extension but I don't know how to run it in Linux. I could keep trying and eventually figure it out, but I was hoping that someone might have tried it and could tell me if there's any change or how to run the ETHpill.
|
|
|
|
cybterpunk
|
|
March 04, 2019, 01:52:06 PM |
|
what's the current speed for C31 mining for 2080Ti card ?
thanks
|
|
|
|
surkoff
Newbie
Offline
Activity: 11
Merit: 0
|
|
March 04, 2019, 02:27:58 PM |
|
got weird problem. Hashrate on two of three of my 1080's dropped with bminer 15.1. Example: with bminer 15.0.2 each 1080 have 5.5 gps on C-29 with bminer 15.1 one 1080 (in X16) have 5.6 gps, two others 1080 have only 4.8 each Maybe someone got same problem and can help me to resolve it? @realbminer, some help for me?
P.S. HiveOS, driver 396.54
|
|
|
|
|
pbfarmer
Member
Offline
Activity: 340
Merit: 29
|
|
March 05, 2019, 02:55:15 AM |
|
@pbfarmer Its complicated with vega powerplay table, but we managed to make it work, SoC state doesn't make difference now. The "Smart Tune" I am refering is exclusive feature in our OS that makes some adjustments to memory timings runtime so it speeds up memory bound/hard algorithms like ethash, equihash and possibliy cuckoo(as seen above).
Ok - thanks for the info. FYI (and for anyone else looking for Vega #s), here's what I'm seeing averaged across 2 Sapphire Nitro 64s (ubuntu 18.04 + rocm 2.0 w/ atomics, i7 8700k, platinum psu): Core: 1325MHz actual (1500/1525 setting) Mem: 800Mhz (P2 state) Voltage: 831mv Speed: 3.77gps Power: 105w (dpm reported) / 140-145w (wall) 831mv is likely higher than necessary here, though any decrease will have to be paired w/ a core clock setting increase to keep the same gps, due to Vegas ACG / clock throttling behavior. Regardless - overall power could likely still be reduced a bit for the same performance. Regarding core vs mem clock importance... from this base point, I see a ~50Mhz (actual) core increase being equivalent to a 300Mhz mem increase, bringing the gps up to ~4, but i haven't measured the corresponding power increases (i would expect the latter to be higher.) Finally, I am unfortunately seeing a 4% (nanopool) - 6% (grinmint) reject rate due to invalid shares (not stales,) which I can't seem to address at all through GPU tuning.
|
|
|
|
laik2
|
|
March 05, 2019, 10:08:38 AM |
|
ACG activates on dpm5, lower than it you'll notice less freq volatility. Entry 4 AVFSOffset : 0 ACGEnable : 0 Entry 5 AVFSOffset : 0 ACGEnable : 1
|
|
|
|
pbfarmer
Member
Offline
Activity: 340
Merit: 29
|
|
March 05, 2019, 10:42:19 AM |
|
ACG activates on dpm5, lower than it you'll notice less freq volatility. Entry 4 AVFSOffset : 0 ACGEnable : 0 Entry 5 AVFSOffset : 0 ACGEnable : 1
Yeah - I tested that, and definitely saw more reliable clocks compared to settings, but it also caused a higher power draw even at the same voltage / effective clock.
|
|
|
|
Luisjc69
Member
Offline
Activity: 163
Merit: 10
|
|
March 05, 2019, 12:45:28 PM |
|
hello guys... anyone have also RX580 cards ? which miner you have for mining Cuckoo29? with AMD cards you have really low hash Maybe some one have alternative miner for AMD? Thank you
|
|
|
|
ztaz
Member
Offline
Activity: 602
Merit: 11
|
|
March 05, 2019, 02:38:35 PM |
|
Please correct the links to the Windows version 15.2.0 version on the site - both are broken ...
|
|
|
|
|