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

I'm using an ancient ccminer so I'm not sure about the issue but it does sound like a simple soft crash to me when the card reverts back to lower P state with 405 Mhz. That is how my cards crash if I have too high OC on them or set too high intensity or accidentaly mine on the same card with 2 instances. Memory leak would imply a leak of some sort causing excess memory usage and/or slow performance degradation over time.

RESTORING DRIVER--

I use PrecisionX 16 to restore the driver without rebooting the system.  These are my steps for a card on Windows that has low hash (crashed driver):

     1) Start or re-open PrecisionX 16.
     2) Turn off K-Boost with the toggle switch (upper right-and corner).
     3) Turn on K-Boost with the same toggle switch.
     4) Re-select the boost profile that you prefer (important!).
     5) Verify that the fan profile and boost settings are again in place, and that temperature is appropriate.
     6) Close or minimize PrecisionX 16.
     7) Restart miner, it should again have appropriate hash readings for boost/overclock settings.

You may also have to open nVidia control panel and reset the display resolution if your graphics now "look odd".  It isn't every time, but frequently I have to reset display resolution for normal graphics.   This is for my work computer, Win 7 X64, with a GTX 960 that I mine with when not playing games.  The GTX 960 will get 10.6Mh/s on Quark, but if it crashes with a segmentation fault, it will only get 3Mh/s on miner restart.  I then perform the steps above and restart the miner.

There is a memory leak somewhere, but I was suspecting poorly programmed flash-media websites, like my local news site.  I need to reboot about once a day because of increasing memory bloat.       --scryptr

I see this problem almost daily but only on two specific cards. One of my 750ti's on a Windows machine is affected
but the other on a different Windows is not affected. My 970 on a Linux box is also affected. Both affected machines
have two cards but only one card is affected and always the same card.

I've only seen it on a couple of algos but they are the ones that I mine the most. It may have occurred on algos that
run less frequently and for shorter intervals without me noticing.

Given only some cards seem to have the problem if the devs don't have one it will be almost imposible to crack.
I would be willing to help troubleshoot on my systems if I'm provided instructions on data to collect. An instrumented
version of ccminer could be used to look for specific things like an unexepectedly low hash rate for the card type to
trigger specific data collection when the problem is detected. There could also be useful info gathered with tools
such as nvidia-smi, gpuz etc.

don't think it is related the control-c problem is a known issue in sp release (there is a fix in tpruvot)

You still can disable the card that attached to a monitor.  The screen will go blank for a couple of seconds but will be back again.  After that you can re-enable the card back. I have done it a number of times on my system when something goes wrong and my card stuck at low clock speed.  Didn't want to reboot so I guess the best method just disable and re-enable the card to recover.

I monitor the cards with Precision X and just wait till they drop below 400 before I begin a new session.  it never crashes for me if I wait till they drop down to below 400

Also you can just disable your video card in Control Panel > Hardware & Sound > Device Manager

then Re-Enable it after a couple of seconds and you wont have to reboot.




(I dont have my monitor connected to my Mining GPU's either so disabling the card does not prevent me from seeing what I am doing. I am not sure what will happen if you disable the card you are using with your Monitor )

has anyone figured out a solution to the memory leak on the newer builds?  it seems to happen for most of the popular algos.  

here's what happens:  reboot, start a fresh mining session. Stop the miner using CTRL+C, get a seg fault message almost all the time, restart the miner, and almost instantly, one GPU crashes (hash shows about 1/3 normal speed), exact same speed everytime the hashes pop up.

rebooting will always fix the issue.

Yeah, from I've seen ASIC doesn't mean a whole lot. Sometimes you like to give things meaning that seem like they should. I've had good and bad OCers with high and low ASIC values.

As a comparison, my i7-4790K is achieving close to 228H/s on 8 threads at 4GHz (Turbo disabled).  However, I still think it doesn't justify for the amount of power my CPU consumed.
https://bitcointalksearch.org/topic/m.12060791

your intel rig is using an amd processor... on an amd board
(but yeah, nobody can stop you from putting an intel sticker on it  )

Had expect more out of 32 cores, but core speed is 1Ghz below my Intel rigs. Still not to bad I guess.  

Cuda 7.5 is broken. Try to compile shavite.
With 6.5 the kernal compiles with 64 registers 0 spill stores 0 stack.
In cuda 7.5 the stack and memory usage explodes. The x11  performance is down 30%. I have tried to tweak it with register count and launchbounds, but just small gains.

same here... (with an additional crash on the 780ti)
you can try to add that to the compilation option: -Xptxas --def-load-cache=cs -Xptxas --def-store-cache=cs, haven't really try on neo, the problem it is 1hour to recompile each time... might help (however it is rather for the 780ti...)

I wanted to try cuda 7.5 and here's my experience with it and neoscrypt mining.

On cuda 6.5 I'm working on an optimized version which does about 560 Mh/s on 970.
Simply switching to cuda 7.5 brought it down to 420.
So I wanted to try to reach at least the same hashrate as before, but I failed: after tuning it for the new cuda version for half a day, I was only able to bring it up to about 460.

Any suggestion on how to do better than that? Or should I just leave 7.5 alone? :-)

I gotta say, I'm not a believer in that ASIC thing, that just seems to be a bunch of horse.

I've had lower and higher ASIC cards, both OC quite well, and also the higher hasn't always been the best. Basically, most of these cards OC till a certain limit, regardless of how well they're made.

From what I've seen, extremely bad cards can't even hold their factory boost clock, but then again, it's got nothing to do with ASIC.

Bit off topic but in GPU-Z there's an ASIC quality estimation tool and I checked all of my GPUs and it seems there is a correlation between the estimated quality and overclocking capabilities.

It apparently takes into account the voltage requires to operate and some other factors to generate a number that doesn't change with overclock or anything.
Higher ASIC quality cards require less voltage to operate and they also naturally boost higher and can take the most OC without overvolting.

So I started incrementally overclocking all cards in a rig with 6 x Asus non-6-pin cards which had a wide spectrum of ASIC quality (62.7% 69.4% 70.6% 70.7% 72% 80.6%) and sure enough the highest quality was the last to crash by a large margin.
Here's a picture showing how to check it. (source)

My highest card is a Gigabyte GTX 750 Ti Windforce with 83.8% and my lowest is my main card I'm not mining with but kept for the occasional gaming with 66.6% which is a 780 Ti and it overclocks absolutely terribly. The average of all my cards is 75%.


So ideally cards should be overclocked based on these figures for maximizing efficiency and stability.
High quality high end cards might even have a decent value for enthusiast gamers.

tanx hashbrown9000,

that would be great ... is it a usb stick install? ...

im not familiar with debian based distros - though i have tinkered with them ...

im more a rhel based ( rhel - fedora ) user and admin guy ...

but i would really like that - yes ... please share ...

i have a great deal of running around to do today - so ill pop in when time permits ...

tanx ...

#crysx

@chrysophylax , if you'd like i could try to upload an image to Mega when I had an HDD installation with overclocking working on the 750ti's. It's Ubuntu 14.04 with CUDA 6.5 and 346.xx nvidia drivers.  The thing was very stable and I have the HDD saved for a backup in case one of my USB sticks goes down.

That's not how a Makefile is supposed to work.
When I modify a file, the files that include it should be recompiled on the next build.
Otherwise you need to find all that files and touch them manually. And if you don't remember to do it, the changes will not be reflected in the binary.

they are exluded to speedup the build. If you save the file in the editor, they will recompile.

1>------ Build started: Project: ccminer, Configuration: Release Win32 ------
1>  Skipping CUDA source file bitslice_transformations_quad.cu (excluded from build).
1>  Skipping CUDA source file groestl_functions_quad.cu (excluded from build).
1>  Compiling CUDA source file quark\cuda_quark_compactionTest.cu...