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

I've always been running 352.21.

I'm just expecting that it exits and that if I run it again afterwords, it works :-)
I always hit ctrl-c only once and wait for it to exit.
I perfectly understand gpu power saving mode: it should not stay while it's mining!

because there is a new commit in git and I wonna compile and run it :-)

At least 1000mh/s lost in Relase 67(970)

EDIT:
I haven't tried all algos but on lyra2v2 & quark its very choppy. I am assuming it will be so on other algos as well. Also in miner hashrate is obviously better for your miner but its obviously not stable enough, so its not about max hashrate but stability of that maximum. I dont think improved performance will solve choppiness but increase it as usage bumps into my temp limits. Please check out these 2 posts to see the difference between your & djm34's miner. I don't know what he is doing but its very stable for me.

https://bitcointalksearch.org/topic/m.12111544 (your miner)

https://bitcointalksearch.org/topic/m.12111898 (djm34 miner)

Is this the lyra2 algo? Release 67 has an improved performance on the 970.

Downgrade to what? Now 355.60.

@sp_ please fix the choppiness of GPU power/usage on your miner. I get 21.1 Mhash/s on your miner release 66 but this is what i get on nicehash.



I get 19.8 Mhash/s on djm 0.4 and on nicehash i get



I have noticed that djm34 ccminer has more stable Gpu usage & temps.

Everything is same in above two runs in terms of h/w & other s/w running, cpu usage etc. My gpus fluctuate between 0-100% usage every 2-5 secs when using your miner, i dont think its good for them so i am currently using djm's miner. Please look into this. you asked me to set GPU performance state to P0 using NV Inspector. I tried it but it wont change. My 970 runs P2 state all the time while mining. Also the problem is in the miner as djm's miner works fine for me with P2 state but your miner gets all choppy.

I am not sure if i am the only one having this problem. 

I'm leaning towards it being a driver issue (linux).  The issue is/was that when closing ccminer with ctrl-c after a few times, one of my cards (I have two different makes of 750Ti's in my box) would hash at a lower rate then normal.  This never happened with my bash auto-switcher script, but that uses "kill" to close ccminer.  (I only noticed the issue when testing changes to my bash auto-switcher, because I would use the ctrl-c command to close ccminer.)  I updated my driver to 355.06 this weekend and then tonight did a bunch of git checkouts / compiles going back to 1.5.50 , then skipping to 1.5.55 then skipping to 1.5.61 and then going up to present.  I would start ccminer, let it hash for a few minutes and then use ctrl-c to close it down.  I would get "Segmentation fault (core dumped)" using the .50 and .55 releases (and probably some of the .6x releases, though not after the nelson-t changes were committed), and with setting the intensity too high I would get "illegal memory" errors.  However, even after all these errors I never encountered slower hashing on the restart of ccminer.  I want to say I was using NVIDIA driver 340 (from ppa "xorg-edgers fresh X crack") before this weekend.  I guess the next step would be to downgrade my drivers and try testing ccminer again... but it is late.  For linux people having the "ctrl-c slower hashing" issue, what version drivers are you running?

I am still getting the

JSON call failed Invalid parameter
submit_upstream_work json_rpc_call failed

while trying to solo mine.

No issues solo mining with any other dev's miner.

Using the exact same bat on all dev's miner and same wallet.

Agreed on the driver issue. The following summary illustrates my experience and I believe the experience
of others. I'm sure I'll be corrected if not.

There are a few scenarios where the GPU will get stuck at low performance. It can happen if the GPU crashes
such as an out of memory error on launch. It can also happen if ccminer is killed with a Ctrl-C. Windows will
also pop up an error window when this occurs. I have seen the degradation on Linux although I'm not sure if
it was ever associated with Ctrl-C.

This seems to be a fairly new problem introduced sometime in the ccminer 1.5 branch (both tpruvot and sp_).
There was some work done around proper_exit when I first started noticing the problem. It's possible that is
just a coincidence and a driver update around the same time could have introduced it.

Ctrl-C is expected to kill the shell process without any side effects such as Windows errors or degraded HW.

For some reason the problem does not seem to occur if the process is killed from another shell
but I can't say it's never occurred. I don't know if any of the recent changes has resolved the Ctrl-C aspect
of the problem because I exclusively use taskkill/pkill.

It's clear that something is messing up the GPU under certain task termination situations. A messy recovery can be
forgiven when the GPU crashes but controlled terminations should be clean.

The old ccminer version slept for 10 seconds before they died. After the T nelson fix, they will quit faster.
In order to boost your profit, you need a good miner control software. I can write good miner control software on windows, but not on linux. The last distro I tested was Red Hat in the 90'ties. Had a botnet of university sun sparc stations though. Long time ago... We where mining passwords.

Do you or sp_ (or anyone else) know what method is the fastest and most reliable way to exit ccminer without:
waiting for the threads to finish and
without ccminer crashing?

Whatever I tried in my fork it either hangs until all the threads have their work finished which takes somewhere between a few seconds to a minute (probably up to diff) or ccminer will crash which would be fine except it sometimes crashes the driver and puts a card or two in different P-state (405 mhz).

Are there more details about this alleged ctrl+c issue?  It's not clear to me what you're doing, let alone what you expect.

Ctrl+C doesn't do anything but signal some loops to break in the control logic.  Which loops depends on if it's the first or second time you've pressed it.  It doesn't actually touch the GPUs at all.

I think you're either observing the intended behavior or a driver bug.

If you press ctrl+c once, then see GPUs drop to power-saving, that's expected behavior.  You've told the GPU worker threads to stop after they're done with current work.  So as the threads complete, you will see GPUs drop to low power modes, since they have nothing to do.  App is just waiting for the rest of the threads to finish before exiting.

If you're running ccminer, killing it with ctrl+c, then starting it again and seeing low performance until a reboot.  That sounds like a driver bug to me.

Why do you need to break with ctrl-c ? Seems to work fine in windows.

Two different brands, same behaviour.

Can you try build 67 please.

Do you have a cudart32_65.dll in the ccminer folder?

Downgrading the driver could increase by 200-300KHASH per 750ti. (Hot tip )

Don't forget to donate guys.

Don't think so. It's happened to me on 780ti, 750ti & 980, all EVGA.

I have reverted it now for compute 5.2. Looks bether.

Make and model of the card?  Maybe it is specific to a card and brand.  I'm almost positive it only affected one of my cards and not the other.