Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 570. (Read 2347641 times)

with public 1.8.1 I couldn't keep my 5 x 1070 rig stable even at stock clocks, worked fine with 4 cards

I've only had SP's for a couple hours and its been 100% stable so far, about 1410 MHs at 872watts at the wall, probably can be tweaked further

is there much I should be tweaking on 1070s other than core clock, power limit and intensity?

I haven't completely migrated over to the new miner, but as I mentioned this happens with Epsylons. I talked with MRR months ago and they said this was a issue with the miner not supporting stratum redirection. I reported this both in Nanashi's, Epsylons, and in this thread... no one looked into it.

The go around right now is to use the dynamic port that is listed in the 'reconnecting' dialogue. That's not a fix though. Here is the response I received from MRR.

MRR: "Your miner needs to be able to handle client.reconnect command, which in this case it looks as if it does not. there may be an option to enable it, please consult your miner software. please note that the rig port may change if it has not been active in two days."

So the dynamic port changes if you change off the algo and back again.

That aside, it looks like the miner works fine with the dynamic port if you type it in manually. You may not have the same issues as me. I have a pretty good internet connection, so I don't get a lot of reconnects.


SP if 'everytime there is a reconnect the dev fee restarts' is the code you're using right now, why not just make the dev fee restart if the reconnect happens during the dev fee mine? Furthermore, you could just 'suspend' the time when it disconnects until a reconnect. So if it disconnects for a second, you +1 second to dev fee mine. There are a lot of ways to fix this.

Totally agree. Same results on the 970 as you.

What makes me think it's the behaviour, these stratum reconnection issues are simply weird. I should test with a better internet connection but given my actual configuration, wifi sticks, this private kernel from sp it's worse than the opensource from tpruvot, due the fee and the instability caused by the stratum reconnections. The kernel from tpruvot it's rock solid, tested on 5 platforms with different kinds of 1070's since a month.

I highly suggest to remove the fee, which is the source of the issues. I would be willing to pay more, without having such an instable kernel. If this is the tipology of software from now on sp, I won't be purchasing more. Sorry.

I understand that's what you're telling everyone to do, but I'm not going to readjust all my overclocks which work with any algo for Lbry. If I want to switch off Lbry I'll have to change them all back again.

Sorta surprised you can't make the cards work harder and use up that free TDP besides having users manually OC. To be fair Epsylons Lbry miner is the 'hardest working' miner I've had to use as far as stability of clocks, even though the watt usage isn't that high compared to say NeoS. I had clocks that were stable with NeoS that I had to readjust for Lbry.

I'll still probably use it and it will probably pay off shooting me a extra 5% and energy savings over the course of a month billing period for energy, but I wouldn't recommend this for small miners with a couple GPUs in a rig. The upfront cost is too high for what it's doing. Although if you have a small farm it would be much easier to manage your OCs and you'll be able to get more out of this.

SP_mod3: running 150x GTX970 @ ~ 1200 Clock / TDP ~50%

= 100 Watt for 135-155 MH/s, for me its the best watt/hash ratio so far.. i can put 5 rigs(with 6 cards each) on one 230V/16(A) wire...

Testing sp_#3 at MRR with 4x970. TDP 92-97%, minerside 178MH/ gpu.

I will just let it run and see where it goes.

http://rig.rent/rigs/33298

Run the 970 on 1550 and lower the memclock. What do you get?

Bit disappointed. Initial experience with SPs LBRY miner, on a 970 it does 6% more and on a 1070, it does 9% more without changing clocks (this does not include the 3.3% dev fee). Tried messing with intensity, it didn't really change anything.

On a 970 I get 156@1450 with Epsylons and with SP I get 167@1450.

Each 970 does use 17w less of power and have less TDP as has been reported, in addition to MCU being at 0%. However I don't intend in creating special configurations for each one of my miners to mine this algo, so the 'hidden potential' of this miner seems to be lost on my setup.

My kernel does -i 29 stable on the 980ti. -i 23 is low in a no memory algo.

I will never buy a build that the dev can mine with... maybe I have and that maybe part of why my miners crashs.
-i 23 to high.

2 minutes per hour donation mining. Fixed intensity at -i 23 so perhaps lower hashrate and power than you would like to have.

Ok thx  I can't oc them. And just curious would you mine with that 2% of the time?

300 on the 980ti is with OC. Coreclock set to 1550-1600, with the opensource you cannot set the core to 1550. it will crash. The highest I got was around 1450.

Sorry for the late response sp. Are those hashrates at stock clocks? And do you hash with it?

There might be an issue in #3. If you loose connection for a long time, it will switch to donation mining and do another 4mins.

4 minutes for me 116 for you. if you loose connection within the 116mins, the process restarts. (if you use the -R reconnect parameter in the bat, you should put it to a high value or remove it.)

With -R 5 it will try to reconnect to your pool 5 times.

I agree, but with the kernel from epsylon you haven't got a fee, and a "forced donation" the first 4 minutes it starts (or reconnects)

sp, not scryptr.

the issue of sp kernels about miningrigrentals it's very serious, because of the "donation" it's 100%, not 3.3.

Apart this, if you loose connection, it restarts with the donation.

If every time that the kernel starts you "donate", these are the kind of issues that you're forced to cope with, and not easy ones.

I hadn't such issues with claymore.

yep, there is a hardcoded range in the card bios i think

advanced nvapi support was added in the 1.8... but as i said in "my" readme beware with clocks, the cards use offsets and when already changed, its the mess to find the original one prefer only --plimit and --tlimit for pascal

and before you ask.. no, tlimit doesnt exist on linux. nvapi is windows only (same api used by oc tools)

Then you are left with a bios mod for your card model. You need a modified version of nvflash in order to bypass the certificate checks..

I check that it is in p2 state mode with nvidia inspector and try to change memory clock both with nvidia smi and nvidia inspector. It is still limited -1000 resulting in 1400mhz (5600 effective)