Topic: [ANN]Bminer: a fast Equihash/Ethash/Cuckaroo29z miner for AMD/NVIDIA GPUs 16.4.9 - page 35. (Read 148347 times)

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

what's the current speed for C31 mining for 2080Ti card ?

thanks

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.

@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).

C31, 1070+1070ti

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.

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

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)?

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?

no, outside red rectangle i use another miner

Looks like internet provider issue.

not sure that it's pools problem
https://ibb.co/tCD83P6

The malloc and CopyEdges errors are FINALLY gone in 15.1.0. Thanks!



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.

Ask them, and here is a hint: Experimental support Cuckaroo29 on AMD cards (ROCM only).

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?

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.

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!

on all nvidia rigs

[FATA] [2019-03-03T09:14:24+03:00] Failed to initialize the AMDCL platform: AMDCL: No AMD devices are available
[WARN] [2019-03-03T09:14:24+03:00] Miner died! It will be restarted soon...

wtf?

so agressive amd support  

which drivers used for this result?    7.15 G/s on P102

i have 389.07 and 398( not find better) 15.1 version not work on 389 and drop hash to 3g/s on 398 driver

 i cannot get bminer to run on grin29 on amd. how am i going to do that with hive os?

Just hit yellow update button on console page.
If you picked specific version of miner previously, you need to go to mining template and pick right version (or choose to always use latests).