Author

Topic: [ANN] ccminer 2.3 - opensource - GPL (tpruvot) - page 169. (Read 500193 times)

legendary
Activity: 3164
Merit: 1003
curl lib is inside the compat folder :p else read the README
thank you  do i have to install it or will the compiler know?
legendary
Activity: 1484
Merit: 1082
ccminer/cpuminer developer
curl lib is inside the compat folder :p else read the README
legendary
Activity: 3164
Merit: 1003
ok compiling with curl 7.29 see if that works.
legendary
Activity: 3164
Merit: 1003
still very new at compiling, where can i get curl to 7.38.0 windows 8.1 from a safe site please.

legendary
Activity: 1484
Merit: 1082
ccminer/cpuminer developer
you see this speed on a pool right ?
pool speed is 20mh. readout is 40mh.


from 1.4.8

I divided by 2 the hashrate of Quark and Jackpot in the upcoming 1.4.9... i really need to talk to Christian to understand why that was made like that before Wink
legendary
Activity: 1484
Merit: 1082
ccminer/cpuminer developer
nvml seems to be very limited (most functions are reporting "not supported")

nvapi seems to be also mostly read only except for display tuning.

I will work on shares history and then cpuminer-multi api today, to be able to monitor them all Wink
legendary
Activity: 1400
Merit: 1050
telnet is just a socket with carriages return support lol ... you can do http requests with telnet if you want Wink

but it was important to do that (its read-only and will stay like that). But i will add some history/debug features later
do you have a way to change the p-state ? from nvml, that would be interesting
legendary
Activity: 1484
Merit: 1082
ccminer/cpuminer developer
telnet is just a socket with carriages return support lol ... you can do http requests with telnet if you want Wink

but it was important to do that (its read-only and will stay like that). But i will add some history/debug features later
legendary
Activity: 1400
Merit: 1050
ok, will do something for that in the 1.4.9, differently

else i finished the telnet compatibility :
Code:
ubuntu14:/work:# telnet 127.0.0.1 4068
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
help
summary
stats
Connection closed by foreign host.
telnet ?! Anybody still using telnet ? (totally unsecured protocol)... I haven't used telnet in more than 13years...
sp_
legendary
Activity: 2926
Merit: 1087
Team Black developer
Awsome. can you add splitscreen support as well ? Smiley
legendary
Activity: 1484
Merit: 1082
ccminer/cpuminer developer
ok, will do something for that in the 1.4.9, differently

else i finished the telnet compatibility :
Code:
ubuntu14:/work:# telnet 127.0.0.1 4068
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
help
summary
stats
Connection closed by foreign host.
legendary
Activity: 3164
Merit: 1003
you see this speed on a pool right ?
pool speed is 20mh. readout is 40mh.


from 1.4.8
legendary
Activity: 1484
Merit: 1082
ccminer/cpuminer developer
you see this speed on a pool right ?
legendary
Activity: 3164
Merit: 1003
No, It displays 10mh/s per 750ti but im still getting 5.15mh/s on quark. Display is wrong with 1.4.8
legendary
Activity: 1484
Merit: 1082
ccminer/cpuminer developer
im ok with that...

else check my git, i added the api and nvml, and a new win32 compatible method (nvapi)

I think we can tune power states with that, maybe also the OC

time to explore the interesting features Smiley

sample rig (multi pc) monitoring : http://epsy.linuxd.org/ccminer/sample.htm
legendary
Activity: 1400
Merit: 1050
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 Wink
should'nt be done on hashdone for sure, but only on the displayed hashrate
legendary
Activity: 1484
Merit: 1082
ccminer/cpuminer developer
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 Wink
legendary
Activity: 1400
Merit: 1050
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 Smiley
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  Grin)

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  Grin
for jpc, using bernouilli functions, it is exactly a factor 2
full member
Activity: 137
Merit: 100
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 Smiley
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  Grin)

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.
legendary
Activity: 1400
Merit: 1050
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 Smiley
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  Grin)

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