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? 
Topic: [ANN] ccminer 2.3 - opensource - GPL (tpruvot) - page 169. (Read 500112 times)
curl lib is inside the compat folder :p else read the README
ok compiling with curl 7.29 see if that works.
still very new at compiling, where can i get curl to 7.38.0 windows 8.1 from a safe site please.
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
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
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
telnet is just a socket with carriages return support lol ... you can do http requests with telnet if you want
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 but it was important to do that (its read-only and will stay like that). But i will add some history/debug features later
telnet is just a socket with carriages return support lol ... you can do http requests with telnet if you want
but it was important to do that (its read-only and will stay like that). But i will add some history/debug features later
but it was important to do that (its read-only and will stay like that). But i will add some history/debug features later
ok, will do something for that in the 1.4.9, differently
else i finished the telnet compatibility :
telnet ?! Anybody still using telnet ? (totally unsecured protocol)... I haven't used telnet in more than 13years... 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.
Awsome. can you add splitscreen support as well ? 
ok, will do something for that in the 1.4.9, differently
else i finished the telnet compatibility :
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.
you see this speed on a pool right ?
pool speed is 20mh. readout is 40mh.from 1.4.8
you see this speed on a pool right ?
No, It displays 10mh/s per 750ti but im still getting 5.15mh/s on quark. Display is wrong with 1.4.8
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
sample rig (multi pc) monitoring : http://epsy.linuxd.org/ccminer/sample.htm
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
sample rig (multi pc) monitoring : http://epsy.linuxd.org/ccminer/sample.htm
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 for X11 we dont multiply them by 11
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
for X11 we dont multiply them by 11
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
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.
for jpc, using bernouilli functions, it is exactly a factor 2
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
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.
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
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...
Jump to: