I dont know, both are compiled the same, on the same system. I seriously begin to hate these Anti virus

Maybe they need to test it before, or are waiting user feedback, i dont know and i dont care about that.

You said to download ? from github ?

heuristics used in all current antivirus applications will ALWAYS have false positive responses to those apps that have similar type signatures to the viral signature ...

this does NOT mean its a virus - but of a pain in the backside when releasing new code that the heuristics engine does not know ...

so the machine that you are using to compile these windows packages is probably clean epsylon3 - its just the anti-virus packages need to 'learn' that you package is not a virus ( or contains one ) ...

I've always gone with what was stated in the wiki. I'm pretty sure the same info is stated on the nVidia web site as well. I will gladly try compiling for 3.0 and see if it works. Probably not till tomorrow though. Will report back my results. thanks all for chipping in to help.

Z

Just reporting back that yes indeed, building for SM3.0 for my card that nVidia and the Wiki both state is 3.5 did the trick. Looking through the makefile of ccminer 1.2 I see that it was building for both 3.0 and 3.5 so that's why it worked. Some bitquark (quark algo) hashrate comparisons from that machine:

ccminer 1.2 = ~1200KH/sccminer 1.6.6 = ~950KH/s

A little disappointed with that. Hoping the share rates are higher to compensate but that's harder to gauge. I'll be trying 1.7 tonight.

I've always gone with what was stated in the wiki. I'm pretty sure the same info is stated on the nVidia web site as well. I will gladly try compiling for 3.0 and see if it works. Probably not till tomorrow though. Will report back my results. thanks all for chipping in to help.

Z

Just reporting back that yes indeed, building for SM3.0 for my card that nVidia and the Wiki both state is 3.5 did the trick. Looking through the makefile of ccminer 1.2 I see that it was building for both 3.0 and 3.5 so that's why it worked. Some bitquark (quark algo) hashrate comparisons from that machine:

ccminer 1.2 = ~1200KH/sccminer 1.6.6 = ~950KH/s

A little disappointed with that. Hoping the share rates are higher to compensate but that's harder to gauge. I'll be trying 1.7 tonight.

Glad to see you got it sorted out and thanks for sharing your results, even though they weren't as you hoped.

One of the side effects of optimized code is it's more specialized. Another example of an older miner being betteron older HW is neoscrypt. A new optimed neoscrypt kernel was added to 1.5.59-SP_MOD that significantlyimproved performance on Maxwell but lowered kepler (780ti) performance. I'm not sure which version isincluded in the TPruvot fork.

I tried analyzing the code to see where the significant differences were and made a few changes where I thoughtit would affect perfomance but I couldn't find the critical code. I guess my c++ skills and cuda knowledge aren'tgood enough.

I have 5 ways to fix this it, listed in increassing order of sophistication.

1. Simply use an older miner when mining neoscrypt on older HW.

2. Replace the neoscrypt source directory with an older version before compiling for 3.5.

3. I managed to put together a hack to select the appropriate neoscrypt kernel based on the architecture.It's a run time switch meaning that both kernels need to be compiled into every SM version binary and theappropriate kernel is chosen at run time.

4. A compile time solution would be preferable where only the appropriate neoscrypt kernel is built into each SM binary.It seems only device code can make use of __CUDA_ARCH__ at compile time so the differences in host code needto be handled differently.

5. A unified kernel where only the critical code is architecture dependant.

I've done 1, 2 & 3 successfully and take a look at 4 when I get motivated. I think 5 is beyond my skill level. I'm currenly using 1 because my 780ti is in a rig all by itself and I don't need to support multiple architectures.I think this contributes to my lack of motivation along with age and rust. However if there is interest it mightbe enough to get me out of my rocking chair and put on my old coding hat.

I've always gone with what was stated in the wiki. I'm pretty sure the same info is stated on the nVidia web site as well. I will gladly try compiling for 3.0 and see if it works. Probably not till tomorrow though. Will report back my results. thanks all for chipping in to help. Z

Just reporting back that yes indeed, building for SM3.0 for my card that nVidia and the Wiki both state is 3.5 did the trick. Looking through the makefile of ccminer 1.2 I see that it was building for both 3.0 and 3.5 so that's why it worked. Some bitquark (quark algo) hashrate comparisons from that machine:ccminer 1.2 = ~1200KH/sccminer 1.6.6 = ~950KH/sA little disappointed with that. Hoping the share rates are higher to compensate but that's harder to gauge. I'll be trying 1.7 tonight.

With the current prices you will make $0,05775 of mining quark 24 H @ 1MHASH

Old hardware is a waste of power. Supporting the old hardware is a waste of time...

Old hardware is a waste of power. Supporting the old hardware is a waste of time...

Well there are plenty of "hobbiest" miners, like myself who are just playing around with older kit, who'd would be very happy with the updated software and its features

FYI on my Nvidia GT430 (Compute 2.1) on a Win7 PC, mining X11 I get 235 Kh/s (reported by the software) using ccminer21 ver 1.0 beta and 202Kh/s using ccminer 1.7-dev (so if you can tweak it a little I'd be very happy!). The video card is also running at a higher overall utilisation running the newer software while delivering the lower reported hashing rate.