This is the sum total of the configure changes git diff v2.7.7 v2.8.3 configure.ac
diff --git a/configure.ac b/configure.ac
index d0de0c8..0d77b97 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,8 +1,8 @@
##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##
##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##
m4_define([v_maj], [2])
-m4_define([v_min], [7])
-m4_define([v_mic], [7])
+m4_define([v_min], [8])
+m4_define([v_mic], [3])
##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##
m4_define([v_ver], [v_maj.v_min.v_mic])
m4_define([lt_rev], m4_eval(v_maj + v_min))
@@ -92,6 +92,7 @@ case $target in
PTHREAD_FLAGS=""
DLOPEN_FLAGS=""
WS2_LIBS="-lws2_32"
+ AC_DEFINE([_WIN32_WINNT], [0x0501], "WinNT version for XP+ support")
;;
powerpc-*-darwin*)
CFLAGS="$CFLAGS -faltivec"
@@ -351,8 +352,7 @@ fi
PKG_PROG_PKG_CONFIG()
-PKG_CHECK_MODULES([LIBCURL], [libcurl >= 7.15.6], [AC_DEFINE([CURL_HAS_SOCKOPT], [1], [Defined if version of curl supports sockopts.])],
-[PKG_CHECK_MODULES([LIBCURL], [libcurl >= 7.10.1], ,[AC_MSG_ERROR([Missing required libcurl dev >= 7.10.1])])])
+PKG_CHECK_MODULES([LIBCURL], [libcurl >= 7.18.2], ,[AC_MSG_ERROR([Missing required libcurl dev >= 7.18.2])])
AC_SUBST(LIBCURL_LIBS)
dnl CCAN wants to know a lot of vars.
See anything? Otherwise, yeah of course scrypt can only do scrypt when scrypt cpu mining. Besides, cpu mining is deprecated and unsupported. Please stick to the main cgminer thread with issues. |
|
|
|
|
Nice, but it doesn't actually achieve any demonstrable performance advantage.
|
|
|
|
|
That's still only accounting for the simultaneous nonce problem, not the similar bitmask or zero bitmask cases. You certainly make a good argument for not using atomic ops.
|
|
|
|
|
Yes but that would make my 2.722 Gh only appear as 2.7GH which is not accurate enough. Significant digits is the key.
|
|
|
|
|
Don't forget modern GPUs have up to 2048 shaders...
|
|
|
|
I'm using 2.8.3 with Linux. I mine on many pools, and I do hop on some of them, having the others as backups, so pool switches are common here. My only stratum pool is Slush. I have it in my configuration file as: "url" : "http://api.bitcoin.cz:8332" so I leave it to cgminer to recognize ad activate the stratum protocol, which it does: Switching pool 7 http://api.bitcoin.cz:8332 to stratum+tcp://api-stratum.bitcoin.cz:3333 But after a few hours that cgminer is running, I always find this stratum pool as "Enabled Dead". While mining on another pool, in the log I see things like: [2012-10-15 01:31:50] Pool 7 http://api.bitcoin.cz:8332 not responding!
[2012-10-15 01:31:51] Pool 7 http://api.bitcoin.cz:8332 alive but, checking immediately after that, in the Pools section the pool is showed as "Enabled Dead", and it will remain dead forever. As soon as I restart cgminer, the pool is alive again (so it's not a pool problem). I don't know if it happens every time the pool doesn't respond for a while, or whenever my box changes its IP address. I'm just sure it happens at least every few hours. HTH. I noticed this also when I used BTC Guild as a backup for a while. I just assumed they were sick of me using them for detecting new blocks sooner without actually giving much work back; I had just as many getworks with them as I did with my primary pool.  I haven't seen this myself but there could well still be a bug in there. I'll keep auditing code. |
|
|
|
ckolivas
Can you fix the issue with compiling on Windows machines in next releases?
It compiles fine on windows. There is an extensive readme on how to do it included in the source. Don't guess, follow the instructions. |
|
|
|
|
None of those matter for scrypt mining. No CPU mining in cgminer is optimal, and that's intentional as it is only there for legacy reasons and testing and I don't wish anyone to mine on CPU with cgminer for anything other than an academic experience.
|
|
|
|
About the global worksize bitmasked problem, if not using bitmasks, the only way for overwrites to happen would be if 2 identical bitwise nonces were found, correct? Btw, since I haven't yet, 1btc donation sent!  I can only imagine the number of hours you spent writing and optimizing cgminer's code! With bitmasked ones, if the bitmask is only 127, 7 bits need to be in common with anything out of the 4 billion nonces. Again rare but not 2^64 rare. With non bitmasked, 2 or more nonces need to be found in a "wavefront" concurrently and can race on the array variable in FOUND. They can be completely different nonces in that case since they're just trying to access exactly the same variable at the same time without protection. Instead of there being 2 nonces flagged as existing, it could be 0,1,2 or a much larger number, and the slots used for the nonces could be anywhere. In other words, the only "strictly correct" way to do it without there being any chance of error is with the atomic ops. Now how well implemented the atomic ops are in hardware and how much they depend on software is a totally different equation that I can't answer, and AMD is unlikely to tell us. Thanks for the donation |
|
|
|
|
Speculation. Expect a rise and then a crash and then a correction...
|
|
|
|
lot of factors coming into play.
-popularity of ASIC mining
- assumptions that ASIC miners won't hold
- reward halving.
anyone who says they know what's going to happen
to the value of btc post reward halving
is just a speculator.
Last I checked, this subforum was called "mining speculation"  |
|
|
|
Are you sure you would even need extra servers with variable diff? You already have rollNTime support so the most requests coming to the pool server are share submissions. With a variable diff solution that uses X-Mining-Hashrate you could greatly reduce the pools current load. You could also fall back to the server calculating the var diff to keep share submission below a maximum threshold of say 24 shares per minute.
I guess my main point is that IMHO it is a higher priority to have variable difficulty working with either GBT or stratum than to have multiple pool servers. You might never need an extra pool server with these other pieces in place.
Yeah, but a US server would be nice. I can easily hit < 0.01% rejects on MaxBTC just because my ping to their server is ~30ms. The ping time factor is overrated. I've tried different servers from the same pool located at 250ms and 50ms ping times and the reject rate was identical. On the other hand, changes to the pool setup itself cause larger changes to the reject rate. |
|
|
|
Yes that is interesting. I'm guessing you have underclocked your memory exceptionally low, as that was found to be an issue with use of atomic ops. Some people found a bump of 15 in memory was enough to correct it. Lack of atomic functions there could lead to HW errors and loss of shares. It's a tradeoff either way. The change was put in there to make sure no shares were lost, which can happen with the old opencl code (though it's only a very small number that would be lost).
Ah, ok! Thanks for the info. Yep, I'm at 150MHz mem clock. It's to prevent the case of simultaneous nonce finds on different vectors to overwrite the result on the same address, right? I prefer the tradeoff tbh, I did the math a while ago on the probability of that happening (P=1/(2^32)*1/(2^32)=1/(2^64). On a 1GH/s card, that will happen on average once every ~585 years) I'm still using that optimization tradeoff I posted for more than a year now!  #elif defined VECTORS2
uint result = W[117].x ? 0u:W[3].x;
result = W[117].y ? result:W[3].y;
if (result)
SETFOUND(result);
No, you're not quite right there btw. There are a few issues that made me use the atomic ops instead. There is no way to return a nonce value of 0. Bitmasked nonce values can also be zero meaning they get lost. It is not just vectors that find nonces at the same time, it's a whole wave front of threads finding nonces at the same time and corrupting both values. Bitmasked nonce values from results found in the same global worksize can come out the same value and overwrite each other. It's to consolidate the return values from different kernels and decrease the CPU usage of the return code that checks the nonce values. Again, very small but far from 2^64. Since bitcoin mining is a game of odds, I didn't see the point of losing that - provided you don't drop the hashrate of course. It's unusual that some devices need higher memory speed just for one atomic op but clearly it's a massively memory intensive operation that affects the whole wave front. Considering increasing ram speed by 15 or 20 would not even register in terms of extra power usage and temperature generated, to me at least it seems a better option. But the beauty of free software is you can do whatever you like to the code if you don't like the way I do it  |
|
|
|
Just updated to 2.8.3. I have to say I really don't like the new precision on numeric output: GPU 0: 73.0C 2900RPM | 604.2M/661.2Mh/s | A:3 R:0 HW:0 U: 7.03/m I: 9
GPU 1: 74.0C 2912RPM | 595.1M/659.3Mh/s | A:5 R:0 HW:0 U:11.72/m I: 9
GPU 2: 74.0C 2922RPM | 611.8M/658 Mh/s | A:10 R:0 HW:0 U:23.44/m I: 9 Could you put a .0 on there instead of all that blank space? It's a minor thing, but I like it better that way. This is a side effect of trying to find a generic format that is aligned on the screen and fits values from 0 to 18,446,744,073,709,551,616 in a generic way, while still maintaining adequate precision for the relative rate for that device. It is not entirely straight forward and what to do about zeroes is not ever going to be to everyone's satisfaction. 001.0 or 01.00 or 1.000 ? By the way, that massive value would show up as 18.45EH/s with that current scheme, so that it could show up aligned on the same screen as something with 0.001 H/s. |
|
|
|
Sorry if this has been asked many times, but why is one version stable, and another version is simply latest, what does it take to get a version to be stable.
I ask because 2.8.3 is crashing about every 3 days.
I think you answered your own question... I will only call 2.8.x stable once it is stable everywhere. I'm trying hard to find the remaining bug(s) in 2.8.3, and it appears to only be affecting windows users, but the bug is eluding me. |
|
|
|
I was running cgminer 2.5.0 till today, as the latest versions had a performance hit on my 5850's (win x64, SDK 2.5 on Cat 12.1), since the last phatk update (~400MH/s to ~320MH/s). Since I had some free time today I went to check what had changed from phatk120223 to phatk120823 and found what was causing me that performance hit. Commenting the problematic lines fixed it: //#if defined(OCL1)
#define SETFOUND(Xnonce) output[output[FOUND]++] = Xnonce
//#else
// #define SETFOUND(Xnonce) output[atomic_add(&output[FOUND], 1)] = Xnonce
//#endif
I still find it strange how the atomic_add could be responsible for that much of a mhash hit, since it will only be called on found nonces. (Running 2.8.3 now, will keep monitoring performance for any issues) Yes that is interesting. I'm guessing you have underclocked your memory exceptionally low, as that was found to be an issue with use of atomic ops. Some people found a bump of 15 in memory was enough to correct it. Lack of atomic functions there could lead to HW errors and loss of shares. It's a tradeoff either way. The change was put in there to make sure no shares were lost, which can happen with the old opencl code (though it's only a very small number that would be lost). |
|
|
|
This post is the most interesting and do you know why? The GPU code is UNCHANGED between 2.7.6 and 2.8.3. The only thing that is different is the stratum code. Now why would that make your GPUs SICK now when they didn't previously? Because with the stratum code, the device is busier than ever. There is no possible way to keep the device as busy as doing it in the c code internally in cgminer. So your devices are no longer getting any rest between work.
EDIT: This is precisely why stratum was developed by the way; in order to be able to keep much higher hashrate devices busy. If you want to test this theory, use version 2.8.3 and connect to the proxy in http mode by using --fix-protocol.
That is quite interesting, i must admit. My GPUs are mostly at 99% load, i have the CCC open all the time, but must admit i don't look all the time. Is it that the load drops sometimes for a short period and that makes the GPU cool or recover so it can look like lasting longer, and on stratum it is on 99% load 24h a day? Also, i have a request: Is it possible to show the fan percentage with the rpm's? I use CCC to monitor fan percentage, because that is my measure when and if my computers need to be air condititoned. As long as fan percentage is below my set max of 55% i declare them sufficient and do not reduce engine clock. (But on the other hand it seems i need to to have stratum work?) Yes but it is only absolutely tiny amounts of time the load drops and may not even visible in the reported GPU load which isn't an accurate measure anyway. I only show fan percentage when fan RPM is not available for that particular device. The reason? The fan percentage is just the value you have told the device to run... it could happily say 55% and the fan may have stopped spinning for some reason which is inherently dangerous. The fan speed rpm is a monitor, it is not a setting. |
|
|
|
In the night all my cgminers on win32 died all at the same time.
I believed you the first time. What I don't have, as yet, is an explanation or anything in particular to debug since I can't reproduce it yet. Maybe if you run one instance in debug mode (-D -T) you can see what the last thing is that is logged. |
|
|
|
I've always been confused on how deepbit was so large to begin with. People have been asking about it for a long time, a logical answer is never given. I'm guessing the pool will disappear unless they lower fees.
2 major things. The non English speaking miners (mainly Russia and China) and inertia. The time deepbit took off was when bitcoin mining exploded in popularity and all the other pools were struggling under the load. Tycho took a chance and kept throwing lots of hardware at the problem which was an investment on his part that paid off, and it was the only reliable pool at the time. That reliability has kept a lot of users there since then, even though most other pools have since caught up and offer lower fees. It is the least modernised pool out there despite being the largest for almost 18 months and having changed very little in design or features and having high fees since then in spite of the bitcoin mining scene changing substantially in that time. All that will change dramatically with ASICs because throwing lots of pool hardware at the server end (which was the deepbit way) is just not going to cut it when we're talking about things being 50x the current demand. Even if the server will be able to take it, miners' internet connections will not be able to take it. Either deepbit will change its business plan to revolve around being an ASIC provider and slowly but surely shut down their mining pool, or they'll totally revamp their pool to support a new mining protocol (hopefully stratum) and start again to support their hardware. |
|
|
|
@ckolivas
is there any reason to leave 2.7.7 behind if i`m mining on a pool which doesn`t support stratum ?
There are a few minor changes, but basically no. |
|
|
|
|
Show Posts
