No issues with 2.8.3, been running several days w and w/o stratum.. Perfect version so far.  Great, thanks for that do_od. There are a few niggling issues that should make 2.8.4 even better, which is scheduled for release today. |
|
|
|
Got a chance to try the new dynamic difficulty changes and they are still less responsive than 2.7.5.
I got some numbers this time, started up a game and ran both at dynamic intensity:
2.7.5 stabilizes during game at ~270MH/s and stays at I=6 (Game graphics only slightly different than no mining)
2.8.3 at ~325MH/s and stays at I=6 (Game graphics are noticeably choppy and playability is significantly affected)
Setting the intensity manually to I=5 results in similar performance to 2.7.5, but obviously the point of d is to not have to do that.
I should also mention this effect is noticeable in other applications than just games, like videos.
For now I am happy with 2.7.5, just thought I would post my results to help out whenever time comes to do some more changes.
The point of the new changes is for the code to not go stupid and get stuck at something really high or really low and it is inevitable that these will be seen as fixes and will definitely be in the new code. Note the really loud message at startup saying how to tune the dynamic difficulty? Tune it if it's too aggressive or not aggressive enough... |
|
|
|
Linux is a PAIN IN THE ARSE
If you're not 100% versed in LINUX, just install windows. IT'S EASIER
Windows is a PAIN IN THE ARSE If you're not 100% versed in WINDOWS, just install linux. IT'S EASIER Blaming familiarity with one for lack of ease on the other works both ways. This is my version. |
|
|
|
cgminer can currently cope on stratum with 96 bits of the difficulty target since the first 32 bits are zeroes and I'm currently using a 64bit unsigned integer for diff calculation. So that allows a maximum difficulty of 18,446,744,073,709,551,616. So we've still got a while to go... and I can always revise it in the future.
If any of us are even alive at that point. Decades of doubling every 18 months before the _share_ targets would be that high. Even if your starting point is a "1 TH/s" ASIC. Right, I guess I left the sarcasm tag off my post. |
|
|
|
|
cgminer can currently cope on stratum with 96 bits of the difficulty target since the first 32 bits are zeroes and I'm currently using a 64bit unsigned integer for diff calculation. So that allows a maximum difficulty of 18,446,744,073,709,551,616. So we've still got a while to go... and I can always revise it in the future.
|
|
|
|
|
Alas the ztex code is in complete bitrot. The only code maintainer for it (nelisky) has long since disappeared and made no attempt to come back and maintain or bugfix it. So you're screwed.
|
|
|
|
|
Awesome stuff!
I suggest stratum + variable diff with an upper limit of 20 shares per minute since the groundwork for what constitutes a scaleable yet tolerable variance has been done by other pool 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.
I've created a (unnecessarily complex) workaround and committed it to git so it's always padded on the right by zeroes. I agree it looks better. |
|
|
|
ckolivas
I've just checked: 2.7.6 and 2.7.7 don't compile but 2.7.5 and before does
So from 2.7.6 it doesn't compile Thanks, that helps a lot. |
|
|
|
[2012-10-16 00:26:14] Creating extra submit work thread
[2012-10-16 00:26:14] Submitting share fdb15728 to pool 0
that is the last output from debugging after the miners dieded last night. The machines with miner 2.8.3 - win32 and started with --fix-protocol didn't die. so it seems it has todo with stratum and win32. Thanks! That at least helps me as to where I can look for potential bugs. I'm quite sure it's stratum related. |
|
|
|
|
I need a holiday villa in the south pacific.
|
|
|
|
[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. Found it, thanks. Will be fixed next version. |
|
|
|
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.
|
|
|
|
|
Show Posts
