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

Anyone get this message on your wallet page for hashpower.co ?


I think I might move to FTC payouts for now.

will also donate some for the improved neoscrypt miner.

also, my miners are kept in an air conditioned room set to 80 deg. F.  They don't seem to have any trouble, even overclocked, never getting above 63 C on the hottest card.

hmm. Cuda 7.5 is shit. Need to find a way to improve the AES code.

x11 is down 30% on the 750ti mining at 2Mhash. (3Mhash with cuda 6.5)

1>  ptxas info    : Overriding global maxrregcount 80 with entry-specific value 64 computed using thread count
1>  ptxas info    : 0 bytes gmem, 1216 bytes cmem[3]
1>  ptxas info    : Compiling entry function '_Z29x11_echo512_gpu_hash_64_finaljjPKyPjj' for 'sm_50'
1>  ptxas info    : Function properties for _Z29x11_echo512_gpu_hash_64_finaljjPKyPjj
1>      528 bytes stack frame, 616 bytes spill stores, 628 bytes spill loads
1>  ptxas info    : Used 80 registers, 4096 bytes smem, 340 bytes cmem[0], 4 bytes cmem[2]
1>  ptxas info    : Compiling entry function '_Z23x11_echo512_gpu_hash_64jjPy' for 'sm_50'
1>  ptxas info    : Function properties for _Z23x11_echo512_gpu_hash_64jjPy

1>  ptxas info    : Overriding global maxrregcount 128 with entry-specific value 64 computed using thread count
1>  ptxas info    : Overriding global maxrregcount 128 with entry-specific value 64 computed using thread count
1>  ptxas info    : 0 bytes gmem, 1152 bytes cmem[3]
1>  ptxas info    : Compiling entry function '_Z26x11_shavite512_gpu_hash_80jjPv' for 'sm_50'
1>  ptxas info    : Function properties for _Z26x11_shavite512_gpu_hash_80jjPv
1>      528 bytes stack frame, 1268 bytes spill stores, 1484 bytes spill loads
1>  ptxas info    : Used 64 registers, 4096 bytes smem, 332 bytes cmem[0], 76 bytes cmem[2]
1>  ptxas info    : Compiling entry function '_Z26x11_shavite512_gpu_hash_64jjPy' for 'sm_50'
1>  ptxas info    : Function properties for _Z26x11_shavite512_gpu_hash_64jjPy
1>      248 bytes stack frame, 572 bytes spill stores, 660 bytes spill loads

I've said this before and say I say it again; software reported power consumption numbers cannot be trusted.
The smi reported 38, 45, 46 watt cap figures are not representative of how much the cards can pull regardless of having a 6-pin or not.

If Sp_'s SMI figures were correct the 750 Ti would be 48% more efficient than a 970. That is laughable. That would be 6.78 W per mhs for the 750 Ti and 10.06 W per mhs for the 970 (to be fair the 157 W is a low fluctuation and the 970 is using slightly more on average so it has lower efficiency or higher W/mhs).

750 Ti's without 6-pin, with stock speeds and unmodified BIOS with release 55 are using 57.5 watt per card which is a measured figure while SMI is showing 38W. The real and measured efficiency of the 750 Ti is therefore 10.26 watts per mhs which is more in line with the 970 as expected.

Use a kill-a-watt or a multimeter or a UPS that reports power consumption but do not take software reported figures for granted.

that's the standard wattage of the 750ti (nvidia design, not the custom ones...) if you edit the original bios that's what you will find, actually nvidia-smi, is probably just reading the bios info

Is this a particular 750ti that has such low wattage? Is there some way to find these specific models? Some people in here were reporting like 68w.

Also 750tis have ridiculous overhead as far as systems go, but given that efficiency is almost double the 970s, that's a eyebrow raiser.

No..but I was thinking of doing that with a timer..but now 1  750ti  making .0012 btc a day. It was working good with r43 but.
EDIT:I think I have a card going bad not sure yet.

Does your bat file loop?

No...it displays that it stopped working and then I click on that it stops the display then I click on to open bat file to run and it runs at normal levels. It's ccminer that crashes not the drivers.
ps forget the humidity ..it wasn't that.

Under windows just ccminer restart won't help. Cause after crash driver goes to some recovery mode (p1,p2 ?) with very low clocks. You'll need to restart driver also or a whole system.

No it's summer time..and at night it can go as high as 95%..but it crashed anyhow ... turning my rig off till sp puts in an auto start. I had enough. Crash..crash... crash...crash....'cuda_check_cpu_setTarget '  at line 28 : unknown error
'cuda_check_cpu_setTarget '  at line 28 : unknown error
'cuda_check_cpu_setTarget '  at line 28 : unknown error

Such high relative humidity is common reflection of increasing temperatures and little air renovation, and makes any ventilation system work harder to achieve the same results as with less humidity. Summer has arrived, but you do have various options: fans running faster, run the AC for lower ambient temperatures, lower clocks for less heat generation, etc...    

PS: Running the AC is my favorite pick, because it actually lowers the relative humidity when it is on cooling mode. In this particular case, you get double benefits: less humidity, and cooler ambient temperatures. Though overall mining efficiency goes out the window. 

92%???

where have you got those miners? ... in a swimming pool? ...

do you have any form of dehumidifier - or air conditioning for them? ...

ouch mate ...

#crysx

Well it seems the humidity at 92% was causing it. And ccminer doesn't have anything build in it to start mining again at crash.
thx

Yes, bios is modded to 65w cause default bios went throttle on high load even with stock clocks.
It's a cheap palit card without any power connector.
I used it in std pci-e x16 port before, now it is on pci-e x1 with rizer cable (with additional power rizer)

p.s. In fact i was lucky enough to get this one, it has only 1.125v voltage and ASIC quality rating (in gpu-z) more then 80%. I tried to find some other 750 or 750ti but all of them was with higher stock voltage and less ASIC quality - so i refused.

He has also done 0.5MH/s improvement on quark on the 750ti and 1MHS/s on the 980

Please donate some and he might share it with us?

+700

same here please ...

#crysx

no restart after crash usually points to the windows drivers crashing ...

have you reset the machine? ...

if not - do so ... it will more than likely still crash - but if it mines even for a little bit after the reboot - then it will most certainly be your drivers that you have installed ...

downgrade - or upgrade the drivers ... that may fix the issue ...

if it continues with the SAME crash - then downgrade the ccminer version you are using ( or recompile a previous ) ...

let us know what the results are ...

#crysx

+1

please :-)

Hope Djm34 will share his improvements.