[ANN] cudaMiner & ccMiner CUDA based mining applications [Windows/Linux/MacOSX]

[polanskiman]

BTW anyone could help me find out why I am getting 7 Mh instead 7.8 for dmd-gr. I get the same results with ccminer or nvminer.

No one?

I actually purchased 2 other 750Ti but from a different brand (Gigabyte) to see if that would be the issue. I still get 7Mh on dmd-gr.

Any help would be appreciated.

Try overclocking

Well with the same card others here and elsewhere have told me that they do not over-clock and they get 7.8/7.9 Mh. That's why I ask.

[cayars]

I have updated my github rep
This change should increase the speed of whirlpool/shabal more particularly on 780ti and below.
So this should affect x14 (who cares  ) and x15.
It is a bug correction actually, which was causing the gpu usage to be well below 99% (in particular for the 780ti, less noticeable for the 750ti)

The overal speed increase (780ti+750ti), is of the order of 12% (the largest fraction is most likely coming from the 780ti).

edit: Ok I will test now the hidden botnet donation feature on bijme webpage (as I didn't have time to login yet) good occasion to use it  

I've been testing the code changes djm34 and I'm not seeing any speed changes.  My 750ti is running a smidge slower on x15 and 660 a hair faster. For all practical purposes same speed.  The only changes were in the two CU files correct?

Carlo

yes, that's strange though. The speed increase is very clear on the 780ti as the gpu usage was around 90% and now it is 98~99% gpu usage. may-be it affects only the kepler ? or at least my gtx780ti  

In the mean time I tested sp_ suggestion of using everywhere the funnelshift for the bit rotation functions.
In the "legacy code" ( ie Christian code), that concerns mainly two routines (cubehash and luffa) where several bit rotations were used but not defined as bit rotation bypassing the funnelshift macro

This leads to absolutely no speed difference either for the 750ti or the 780ti
(the 750ti is using sm50 through the driver "trick" which recompiles at launch time the kernels using sm50).
and there is clearly no boost in speed...

sp_ seemed to suggest that Christian did a lousy jobs at optimizing x11 and using killer groestl, but clearly this isn't what I saw.
(However this was tested over long chains of algorithms... it is always possible that there is some speed improvement for smaller chain like qubit or fresh... masked by groestl or whirlpool...

djm34,

Thank you for the clear explanation/answer.  I'll release nvMiner with this bug fix shortly just to make sure it's current.

When you were testing sp_ suggestion of using the funnelshifts was this on Cuda5.5 or did you also try it with 6 or 6.5 also?

I was thinking it would need to be Cuda 6.0 (or later) compiled specifically with compute_30,sm_30;compute_35,sm_35;compute_50,sm_50

You are far more knowledgeable than me on this but I just thought I'd ask.

Carlo

[djm34]

I have updated my github rep
This change should increase the speed of whirlpool/shabal more particularly on 780ti and below.
So this should affect x14 (who cares  ) and x15.
It is a bug correction actually, which was causing the gpu usage to be well below 99% (in particular for the 780ti, less noticeable for the 750ti)

The overal speed increase (780ti+750ti), is of the order of 12% (the largest fraction is most likely coming from the 780ti).

edit: Ok I will test now the hidden botnet donation feature on bijme webpage (as I didn't have time to login yet) good occasion to use it  

I've been testing the code changes djm34 and I'm not seeing any speed changes.  My 750ti is running a smidge slower on x15 and 660 a hair faster. For all practical purposes same speed.  The only changes were in the two CU files correct?

Carlo

yes, that's strange though. The speed increase is very clear on the 780ti as the gpu usage was around 90% and now it is 98~99% gpu usage. may-be it affects only the kepler ? or at least my gtx780ti  

In the mean time I tested sp_ suggestion of using everywhere the funnelshift for the bit rotation functions.
In the "legacy code" ( ie Christian code), that concerns mainly two routines (cubehash and luffa) where several bit rotations were used but not defined as bit rotation bypassing the funnelshift macro

This leads to absolutely no speed difference either for the 750ti or the 780ti
(the 750ti is using sm50 through the driver "trick" which recompiles at launch time the kernels using sm50).
and there is clearly no boost in speed...

sp_ seemed to suggest that Christian did a lousy jobs at optimizing x11 and using killer groestl, but clearly this isn't what I saw.
(However this was tested over long chains of algorithms... it is always possible that there is some speed improvement for smaller chain like qubit or fresh... masked by groestl or whirlpool...

djm34,

Thank you for the clear explanation/answer.  I'll release nvMiner with this bug fix shortly just to make sure it's current.

When you were testing sp_ suggestion of using the funnelshifts was this on Cuda5.5 or did you also try it with 6 or 6.5 also?

I was thinking it would need to be Cuda 6.0 (or later) compiled specifically with compute_30,sm_30;compute_35,sm_35;compute_50,sm_50

You are far more knowledgeable than me on this but I just thought I'd ask.

Carlo

I am still using cuda 5.5 (but I am thinking about downloading 6.0).
However, as far as I understand, the funnelshift is a feature which has been introduced starting compute 3.5 so it is already supported in cuda 5.5 and I don't see anything in the cuda 6.0 release notes any changes at that level...

[cayars]

If you change cuda devices code generation to compute_30,sm_30;compute_35,sm_35;compute_50,sm_50 are you able to compile with 5.5?

I'm not able to build 50 code unless I have Cuda 6.0 installed.

[S_tring]

From the JPC thread:

DANGER

It seems Jackpotcoin was forked.

DwarfPool (3 servers on the same) and Miningpoolhub: block 447394 diff 282
All block explorers on the right fork too:
http://explorer.jpcpal.com/
http://jackpotcoin.info/blockexplorer/
http://explorer.jackpotcoin.info/

Other fork:
hashharder, hashatme, cloudminers, minep.it: block 447382 diff 99.9

What's the latest? I was thinking of switching back to JPC but after reading this...

[DougB62]

From the JPC thread:

DANGER

It seems Jackpotcoin was forked.

DwarfPool (3 servers on the same) and Miningpoolhub: block 447394 diff 282
All block explorers on the right fork too:
http://explorer.jpcpal.com/
http://jackpotcoin.info/blockexplorer/
http://explorer.jackpotcoin.info/

Other fork:
hashharder, hashatme, cloudminers, minep.it: block 447382 diff 99.9

What's the latest? I was thinking of switching back to JPC but after reading this...

It seems that they have taken care of the issue - they were right on top of it. So I think it's safe. Whether or not it's the best thing to mine right now, I don't know.

[bathrobehero]

Has anyone much smarter than me checked bcrypt and yescrypt out?

Bcrypt apparently uses a lot of memory as it's first line of defense against GPU's but what if it's like Scrypt-Jane again where Lookup-gap could be useful?
Bcrypt ann: https://bitcointalk.org/index.php?topic=640933.0

Yescrypt is not as interesting as it is not launched yet, but could catch on if it's working: https://bitcointalk.org/index.php?topic=696519.0

[djm34]

Has anyone much smarter than me checked bcrypt and yescrypt out?

Bcrypt apparently uses a lot of memory as it's first line of defense against GPU's but what if it's like Scrypt-Jane again where Lookup-gap could be useful?
Bcrypt ann: https://bitcointalk.org/index.php?topic=640933.0

Yescrypt is not as interesting as it is not launched yet, but could catch on if it's working: https://bitcointalk.org/index.php?topic=696519.0

for bscrypt, it is difficult to check anything as it can be mined only from the wallet and there is no pool (same reason)...
Until they get this fixed... nothing can be done (and I don't know enough about how the wallet works...)

I wanted to look into that some time ago (this is how far I went  )
also regarding NUD, during a while the algo was running as normal scrypt, because of a bug in bscrypt (so there might be some big stack around... )

[bathrobehero]

I wanted to look into that some time ago (this is how far I went  )
also regarding NUD, during a while the algo was running as normal scrypt, because of a bug in bscrypt (so there might be some big stack around... )

Ouch, that's a big turnoff. Thanks.

[djm34]

If you change cuda devices code generation to compute_30,sm_30;compute_35,sm_35;compute_50,sm_50 are you able to compile with 5.5?

I'm not able to build 50 code unless I have Cuda 6.0 installed.

The newest driver recompile (? not sure what it does actually) on the fly for compute_50 sm_50 when you run the first time with a 750ti.
Not sure if you noticed, but you get a bunch of comment when you start ccminer right after a new build (at least this what I get).
Anyhow, I just installed 6.5RC (and right now I get only "doesn't validate on cpu" from my developpment buid..." however the latest github seems ok. (might be the change I put right before going to sleep)...

[cayars]

I previously got this compiled but got the same issue as you on FRESH algo (only that one).

However, I've meant to mention I get a lot of BOOs with x15 since it was released.  Do you get this also?  X14 is fine.

[cayars]

http://cudamining.cc/url/releases

nvMiner v1.2U-D4 is released.

Version D4 includes fixes from djm34 to whilpool and shabel CU files.

Carlo

[djm34]

I previously got this compiled but got the same issue as you on FRESH algo (only that one).

However, I've meant to mention I get a lot of BOOs with x15 since it was released.  Do you get this also?  X14 is fine.

not really, the rate of "does not validate on gpu" is somewhat higher though... (did you removed the validation on the cpu ? actually I am thinking to remove it, that should on low dif pool increase a bit the performance)
But to be honest, I don't run very often on x15...

[RavenXBR]

From the JPC thread:

DANGER

It seems Jackpotcoin was forked.

DwarfPool (3 servers on the same) and Miningpoolhub: block 447394 diff 282
All block explorers on the right fork too:
http://explorer.jpcpal.com/
http://jackpotcoin.info/blockexplorer/
http://explorer.jackpotcoin.info/

Other fork:
hashharder, hashatme, cloudminers, minep.it: block 447382 diff 99.9

What's the latest? I was thinking of switching back to JPC but after reading this...

It seems that they have taken care of the issue - they were right on top of it. So I think it's safe. Whether or not it's the best thing to mine right now, I don't know.

I've moved to NiceHash Control for awhile because a deposit I made at MintPal has not been confirmed for more than 12h.
Even with the fast problem idenification and action, stil there's some risk of wasting hash power on JPC by now.

[RavenXBR]

Doubt:
I have a four GTX750Ti rig (same Gigabyte card on all 4) and was thinking to add 2 Zotacs to it to save power cables.
Will I have problems running a single ccminer on rig?

 

[Cooldogin]

BTW anyone could help me find out why I am getting 7 Mh instead 7.8 for dmd-gr. I get the same results with ccminer or nvminer.

No one?

I actually purchased 2 other 750Ti but from a different brand (Gigabyte) to see if that would be the issue. I still get 7Mh on dmd-gr.

Any help would be appreciated.

Can't be sure but you might be comparing 'stock' 750Ti's with versions that are coming pre-overclocked like the EVGA 750Ti SC. My stock 750Ti's only get 6.9-7MH's on DMD but when I overclock them to +160/+204 I get ~7.8MH's on them. So if you want those numbers you need to overclock your cards

[BrewCrewFan]

One quick question.... I dont know if it has been said, or answered, but for whatever reason my gpu power % is not close to 100%...is this normal? If not, how do I fix? Running nvminer-D

[Bombadil]

One quick question.... I dont know if it has been said, or answered, but for whatever reason my gpu power % is not close to 100%...is this normal? If not, how do I fix? Running nvminer-D

That's normal I still have this image I made a few weeks ago: https://i.imgur.com/971bVH7.png
It shows that every algo has its own characteristic, but it never reaches a stable 100% power usage.
I should make an updated one ^^" With killer-groestl it shows a bit different, not mentioning the nice curves CryptoNight makes

[tbearhere]

on  http://cudamining.cc/url/releases  the  btc donation, does that go to all you people who complied ?

right now, the donation at he bottom is donations to me for running and developing the website. needless to say it has never received anything

now it has 

[djm34]

I take back what I was saying earlier regarding the use of asm instruction.

There is actually some marginal speed increase.
It is noticeable on whirlpool when replacing xor functions by the asm instruction
It was the slowest algo of the bunch, now it is behind groestl... (finally been able to use nsight... a lot better than measuring hashrate  )
and actually the slowest is echo... which is kind of strange...

However the effect is not noticeable on luffa and cubehash as they are already pretty fast...
(the result is independent of the cuda version)