[ANN] ccminer 2.3 - opensource - GPL (tpruvot)

[SS2006]

epsylon, i have a gtx 970 (5.2 right?)

but for some reason when i use ccminer50 instead of 52, i ALWAYS get better hashrate, less out of range errors, and just more accepts in general. This was the same case with SPminers betas etc..

any ideas why this happens?

[1714796979]

1714796979

[1714796979]

1714796979

[1714796979]

1714796979

[Epsylon3]

yes its 5.2, hmm i'm not sure about that for the moment maybe the right cuda sdk is required ? on windows ?

[SS2006]

is there any real advantage to downloading and installing the 1 GB large CUDA 6.5 SDK. I figure if the miner runs, then I have everything in place already

[djm34]

epsylon, i have a gtx 970 (5.2 right?)

but for some reason when i use ccminer50 instead of 52, i ALWAYS get better hashrate, less out of range errors, and just more accepts in general. This was the same case with SPminers betas etc..

any ideas why this happens?

registers... for some reason 5.2 doesn't like to allocate too much register...

[Epsylon3]

is there any real advantage to downloading and installing the 1 GB large CUDA 6.5 SDK. I figure if the miner runs, then I have everything in place already

no indeed, i dont think so...

API is almost ready (limited to localhost for the moment, will add the config key to change that)

[tbearhere]

is there any real advantage to downloading and installing the 1 GB large CUDA 6.5 SDK. I figure if the miner runs, then I have everything in place already

no indeed, i dont think so...

API is almost ready (limited to localhost for the moment, will add the config key to change that)

my read out for quark



did i compile wrong?
4 750ti  cards hashing at10mh/s      total 10mh ?

[Epsylon3]

2 algos hashrates were divided by 2... quark and jackpot, i dont really know why... I removed the divider

sample api output of php api-example.php :

Code:

{
"summary":{"NAME":"ccminer","VER":"1.4.8","API":"1.0","ALGO":"blake","KHS":"216674.14","ACC":"4","REJ":"0","ACCMN":"3.429","UPTIME":"70"},
"stats":{"GPU0":{"GPU":"0","TEMP":"0.0","FAN":"0","FANP":"0","KHS":"216674.15","HWF":"0","I":"0"}}
}

you can copy/paste that in http://json.parser.online.fr/

will change some keys... adding UP (uptime), ACM (accepted/minute)

v1.4.8 will be released today (to fix the multi gpu displayed hashrate)

[Epsylon3]

did i compile wrong?
4 750ti  cards hashing at10mh/s      total 10mh ?

fixed in 1.4.8 (else on git since this morning) release in a few minutes

[antonio8]

Not sure if Epsylon3 has asked but I'll will for him

PLEASE DONATE  to him for his work he has been putting in and improving his miner.

We should donate to all these devs that put out these miners and enhancements. Without them we would have nothing.

[tbearhere]

did i compile wrong?
4 750ti  cards hashing at10mh/s      total 10mh ?

fixed in 1.4.8 (else on git since this morning) release in a few minutes

Epsylon3 there is an improvement in hash.  on 1.4.7. waiting for 1.4.8. 

[tbearhere]

Not sure if Epsylon3 has asked but I'll will for him

PLEASE DONATE  to him for his work he has been putting in and improving his miner.

We should donate to all these devs that put out these miners and enhancements. Without them we would have nothing.

+1 on that
Look at all these people reading and are they donating?
3743
PLEASE DONATE to ALL involved in cuda and ccminer.

[BrewCrewFan]

Not sure if Epsylon3 has asked but I'll will for him

PLEASE DONATE  to him for his work he has been putting in and improving his miner.

We should donate to all these devs that put out these miners and enhancements. Without them we would have nothing.

+1 on that
Look at all these people reading and are they donating.
3743
PLEASE DONATE to ALL involved in cuda and ccminer.

Even at a fraction of a BTC per user it would all add up rather fast.

[tbearhere]

Epsylon3  1.4.8  still gives readout of 40mh/s, 4 750ti, when cards are doing 20mh/s quark.

[Epsylon3]

hmm... no... one 750Ti card do 10MH

[tsiv]

hmm... no... one 750Ti card do 10MH

That would be a 100% boost compared to ccminer 1.2, either you're a wizard or there's something funky with your rate calculations. Not to say you and sp_ haven't done a good job on optimizing various algos, but I do find the latter a lot more likely

[djm34]

hmm... no... one 750Ti card do 10MH

That would be a 100% boost compared to ccminer 1.2, either you're a wizard or there's something funky with your rate calculations. Not to say you and sp_ haven't done a good job on optimizing various algos, but I do find the latter a lot more likely

not sure I really followed...
but the hashrate in jpc is divided by two, because it hashes only on certain chain where it is faster and doesn't look at the slowest one... (because of large imbalance is hashrate of the various chain of algo, it is globaly faster to ignore few algo combination rather than computing everything blindly...)
Therefore the total hashrate before the division isn't the total hashrate for every possible algo combination but only those computed by ccminer.
Hence the reason why it is divided by two...
(I will spare you the probability calculation which says it is the right thing to do  )

Don't know the reason for quark (ask Christian), could be a similar reason since there are also various random chains...

[tsiv]

hmm... no... one 750Ti card do 10MH

That would be a 100% boost compared to ccminer 1.2, either you're a wizard or there's something funky with your rate calculations. Not to say you and sp_ haven't done a good job on optimizing various algos, but I do find the latter a lot more likely

not sure I really followed...
but the hashrate in jpc is divided by two, because it hashes only on certain chain where it is faster and doesn't look at the slowest one... (because of large imbalance is hashrate of the various chain of algo, it is globaly faster to ignore few algo combination rather than computing everything blindly...)
Therefore the total hashrate before the division isn't the total hashrate for every possible algo combination but only those computed by ccminer.
Hence the reason why it is divided by two...
(I will spare you the probability calculation which says it is the right thing to do  )

Don't know the reason for quark (ask Christian), could be a similar reason since there are also various random chains...

Sounds dead-on correct, didn't actually think of that. Quark starts with two relatively fast algos, third would be groestl or skein depending on one bit in the second algos output but the nonces that lead down the groestl branch get discarded. Dividing by two isn't exactly right but it's a statistically fair estimate of the actual hashes finished.

[djm34]

hmm... no... one 750Ti card do 10MH

That would be a 100% boost compared to ccminer 1.2, either you're a wizard or there's something funky with your rate calculations. Not to say you and sp_ haven't done a good job on optimizing various algos, but I do find the latter a lot more likely

not sure I really followed...
but the hashrate in jpc is divided by two, because it hashes only on certain chain where it is faster and doesn't look at the slowest one... (because of large imbalance is hashrate of the various chain of algo, it is globaly faster to ignore few algo combination rather than computing everything blindly...)
Therefore the total hashrate before the division isn't the total hashrate for every possible algo combination but only those computed by ccminer.
Hence the reason why it is divided by two...
(I will spare you the probability calculation which says it is the right thing to do  )

Don't know the reason for quark (ask Christian), could be a similar reason since there are also various random chains...

Sounds dead-on correct, didn't actually think of that. Quark starts with two relatively fast algos, third would be groestl or skein depending on one bit in the second algos output but the nonces that lead down the groestl branch get discarded. Dividing by two isn't exactly right but it's a statistically fair estimate of the actual hashes finished.

kind of silly to put groestl and skein in a uniform random choice 
for jpc, using bernouilli functions, it is exactly a factor 2

[Epsylon3]

The main problem is not the reported speed, but the hashdone reduced value (by 2), which can make problems on the next loop (recomputing the same nonces)

for X11 we dont multiply them by 11

[djm34]

The main problem is not the reported speed, but the hashdone reduced value (by 2), which can make problems on the next loop (recomputing the same nounces)

for X11 we dont multiply them by 11

should'nt be done on hashdone for sure, but only on the displayed hashrate