I open cgminer 2.8.2 and type in btcguild.com:8332, then my username and then I leave password blank. My gpus start working and i get 360 mhash per gpu which is normal however no shares are accepted. Any ideas? Ive never used stratum before
It appears the windows stratum support doesnt work. Try using --fix-protocol to prevent it using stratum. Linux users are unaffected by this bug, stratum works fine there. It works fine for me with 2.7.5. What advantages would swtiching to 2.8.2 do for me if I use normal mining method? It would only be helping me to debug where the problem might be to see if it only affects the stratum code.
|
|
|
I open cgminer 2.8.2 and type in btcguild.com:8332, then my username and then I leave password blank. My gpus start working and i get 360 mhash per gpu which is normal however no shares are accepted. Any ideas? Ive never used stratum before
It appears the windows stratum support doesnt work. Try using --fix-protocol to prevent it using stratum. Linux users are unaffected by this bug, stratum works fine there.
|
|
|
Looks like cgminer's stratum support doesnt work properly on windows yet. You can bypass it by using http and --fix-protocol options but that defeats the purpose and you may as well use 2.7.7. Linux users stratum should work fine (I use it myself).
|
|
|
Tried a windows version of 2.8.2 on 1 x CM1 + 1 x BFL Single on Win7 x64. It starts as usual, attaches to stratum and makes a look of hard working, but never makes any shares, just takes Icarus Re-estimations periodically. Ran it for 5 minutes - U is still 0, no shares.
O_o
Got back to 2.7.6 through mining proxy - it works well as usual.
I get this result as well. Each single shows a hashrate and cgminer reports about 35 work units, but U is a constant 0. Pointed to mine2.btcguild.com:8332, using the Windows binary. That's most unusual. I assume it only happens with stratum? What does cgminer say when you run it with -D -P -T (note the output will be very verbose so try it only on a single device first)?
|
|
|
New version of cgminer, 2.8.2, fixing the variable difficulty bug has been released. Also new to this version of cgminer is support for the stratum commands client.reconnect and client.get_version.
|
|
|
WARNING TO CGMINER USERS A bug has been reported by two users so far with cgminer 2.8.1. This bug is so far only being shown to affect workers that are very fast (> 4 GH/s). There seems to be a bug in cgminer 2.8.1's difficulty targetting, and when a miner either hits difficulty=4, or is supposed to hit difficulty=8 (not yet confirmed which part is causing the problem), it is having drastically reduced share submissions.
If you are having this problem, downgrade to a 2.7.x version of cgminer and use the stratum proxy, or regular getwork pools. I've posted on the cgminer thread and am waiting for a response from ckolivas.
There is a hotfix update of cgminer to version 2.8.2 which fixes this bug. Anyone mining on btcguild with cgminer 2.8.0 or 2.8.1 is strongly encouraged to update.
|
|
|
New release - 2.8.2, 11th October 2012
The code is getting close to a point where I can declare the stratum support stable. Those testing stratum support are strongly recommended to upgrade since the variable diff support is broken on earlier releases.
Human readable changelog
Fixed a scenario where stratum might declare a pool dead and never try to reconnect to it. Fixed the broken target support for difficulties >2 Add a --fix-protocol option to prevent cgminer from redirecting to stratum if you wish to stick to http / getwork. Added support for mining.reconnect in stratum for when pools wish to move their stratum server. Added support for client.get_version in stratum. Try again to fix the dynamic intensity support on windows by adding long term history but limiting the amount it can change at any one time. If a pool is switched to its stratum version, the original config version is reported (which helps puppetmaster control).
Full changelog
- Reinstate the history on dynamic intensity mode to damp fluctuations in intensity but use an upper limit on how much the value can increase at any time to cope with rare overflows. - Create a fix-protocol option which prevents cgminer from switching to stratum if it's detected. - Simplify target generation code. - Add support for client.get_version for stratum. - Use a 64 bit unsigned integer on the diff target to generate the hex target. - Update reconnect message to show whole address including port. - Look for null values and parse correct separate array entries for url and port with client reconnect commands for stratum. - The command for stratum is client.reconnect, not mining.reconnect. - Only copy the stratum url to the rpc url if an rpc url does not exist. - Implement rudimentary mining.reconnect support for stratum. - Ignore the value of stratum_active on calling initiate_stratum and assume we're always trying to reinitiate it, and set the active flag to false in that function. - stratum auth can be unset if we fail to authorise on subsequent calls to auth_stratum which undoes the requirement of setting it in one place so set it in pool_active.
|
|
|
Going to stratum with variable difficulty on pools will use less bandwidth and cpu for the pool, no matter what the hashrate is, compared to current hardware and protocols. In fact, stratum with a properly tuned variable diff server, the amount of traffic is static regardless of hashrate. The only real issue is what happens at the start of mining as currently they start at diff 1 and then increase. I doubt that will be the case long term as the software will deliver expected hashrate and/or desired start difficulty.
|
|
|
LOL good choice. Remember he's in Australia too, and no way would he be paying for his own airfare.
|
|
|
There is definitely something wrong in 2.8.1's release and dynamic difficulty adjustments. It seems to happen at diff=4 (or possibly when they move to diff=8). The users reporting the problem are getting stuck at difficulty of 4, on rigs that were at difficulty=8 or difficulty=16 prior to upgrading to 2.8.1. This is reflected by a drastic drop in their hash rates (50% or 75% drop).
My best guess is the integer difficulty isn't adjusting to the proper target. So users are working on a harder target than what they should be, reducing their share submissions.
Bug acknowledged. Working on a fix and hopefully will release a 2.8.2 in the near future correcting this and the reconnection issues.
|
|
|
For me, whatever changes happened to dynamic in 2.7.6 have made it work poorly again. It is back to being really unresponsive to lowering when I am using the gpu for other things. It will lower one intensity or even stay the same as when I am not using the gpu for something else. I am on Windows 7 with two 5870s. What specifically changed with the algorithm in 2.7.6?
(2.7.5 is running smooth, and responds quickly when other programs use the gpu, and all I have to do on that version is set the intensity to fixed then back to dynamic and I never get the negative intensity bug anymore. 2.7.5 is the first version since 2.1.2 that I can get high performance when not using the gpu for other things and still have really responsive backing off of intensity when I do).
I got rid of the long term history in dynamic intensity going into 2.7.6, as the long term history was occasionally getting a dud result and pegging intensity to some small value indefinitely. I guess I'll just have to keep reworking this till it works everywhere.
|
|
|
Is there much difficulty when adding stratum support to a pool? I like the changes in the newest cgminer for native Stratum support At this stage, likely the mtred pool software does not has native support for it, nor is there any code to draw it from, so it would need to actually be written (slush and btcguild use different pool software). Thanks I like the principle behind stratum, and although it's been a lot of work, and probably still a bit rough around the edges, I can only see it as positive going forward for pooled mining.
|
|
|
Heh, amazing in just how many places just how much damage one person can cause...
|
|
|
Last time this happened it was a packaging error on my part. I'll reupload shortly. I've reuploaded it.
ckolivas I've just downloaded the last zipped source from your git but the problem is OpenCL...............: NOT FOUND. GPU mining support DISABLED That's a different one and a problem with your installation lacking the AMD APP SDK, or you lack including the directories (with -I) you have the sdk installed into. ckolivasCompiling under Win7 x64 is ok after modification of configure.ac elif test "x$AMDAPPSDKROOT" != x; then OPENCL_FLAGS="-I$AMDAPPSDKROOT/include $OPENCL_FLAGS" OPENCL_LIBS="-L$AMDAPPSDKROOT/lib/$ARCH_DIR $OPENCL_LIBS"
this code was commented and I have no error What do you say about that?What I say is it works for me. From git you usually need ./autogen.sh first. Not sure on a zipball from git, might be the same. Try a source tarball from my server instead of from git.
|
|
|
I have problem with mining litecoins on some my rigs. My 6 rigs mining very great. For example: GPU: 6870, 6870, 6770, 6770 Mobo: Asrock 890 FX Deluxe 5 RAM: 2 GbOS: Win7 64 Drivers: 11.12 with OCL libs from 11.11 (for mining bitcoins when it more profitable) cgminer.cmd (I use same copies of cmd's on all my rigs and it works very well) cgminer --scrypt --worksize 256 --shaders 1280 --lookup-gap 2 -g 1 --thread-concurrency 8192 --intensity 17 -o http://ltc.xurious.com:9332 -u user -p pass Screenshot (the picture is clickable): Хостинг фотографийBut there is one problem rig: GPU: 6870, 6770 Mobo: Asus P5KPL AM SE RAM: 1 GbOS: Win7 64 Drivers: 11.12 with OCL libs from 11.11 This rig mining bitcoins without any problems (I use phoenix 2.7.5). But there are problems with mining litecoins. I tried also reaper (it works better on my rig with 7970) but not good too. When I start cgminer.cmd it does not work: Хостинг фотографийIf I change cgminer.cmd to cgminer --scrypt --worksize 256 --shaders 1280 --lookup-gap 2 -g 1 --thread-concurrency 2048 --intensity 12 -o http://ltc.xurious.com:9332 -u user -p pass it work, but hashrate is very very low. If I up --thread-concurrency, it does not work. If I up --intensity, it makes HW and not makes accepted shares: Хостинг фотографийI tried versions 2.7.4, 2.7.5, 2.7.6 and 2.8.1. Help me, please. While my GPU can't mining litecoins I am very unhappy. Thank you. System ram is required for litecoin mining as well. Your 2nd machine only has 1GB ram.
|
|
|
I'm running 2.8.1 now. It seems to me that stratum+tcp pools that fail once are marked as dead and never will become alive again. cgminer version 2.8.1 - Started: [2012-10-09 22:36:17] -------------------------------------------------------------------------------- (5s):11.3 (avg):11.1 Mh/s | Q:3376 A:158 R:6 HW:0 E:5% U:0.1/m TQ: 0 ST: 3 SS: 1 DW: 575 NB: 109 LW: 5813 GF: 5 RF: 1 WU: 0.1 Connected to http://mining.eligius.st:8337 with LP as user <user> Block: 000003b4be07550c78f0b88a71d20b77... Started: [17:32:35] -------------------------------------------------------------------------------- [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit GPU 0: 71.0C | 11.2/ 11.1Mh/s | A:158 R:6 HW:0 U:0.14/m I: 9 --------------------------------------------------------------------------------
0: Enabled Dead Priority 0: api-stratum.bitcoin.cz User:<user> 1: Enabled Dead Priority 1: stratum.btcguild.com User:<user> 2: Enabled Alive Priority 2: http://mining.eligius.st:8337 User:<user>
Current pool management strategy: Failover [F]ailover only disabled [A]dd pool [R]emove pool [D]isable pool [E]nable pool [C]hange management strategy [S]witch pool [I]nformation Or press any other key to continue
When I stop cgminer and start it again, the first stratum pool in my list is alive again. The second stratum pool in the list is always dead. 0: Enabled Alive Priority 0: api-stratum.bitcoin.cz User:<user> 1: Enabled Dead Priority 1: stratum.btcguild.com User:<user> 2: Enabled Alive Priority 2: http://mining.eligius.st:8337 User:<user>
Yep, could be a bug. Investigating to see why that would be the case because it's meant to try reconnecting regularly.
|
|
|
[2012-10-09 15:10:46] Rejected ed5dd272 Diff 1 MM 4 pool 0 (lowdifficulty) [2012-10-09 15:10:46] Rejected 1c494208 Diff 1 MM 2 pool 0 (lowdifficulty) [2012-10-09 15:10:48] Rejected c1b3226d Diff 1 MM 3 pool 0 (lowdifficulty) [2012-10-09 15:10:48] Rejected 25398ba3 Diff 1 MM 8 pool 0 (lowdifficulty) [2012-10-09 15:10:48] Rejected 1507a8f3 Diff 1 MM 3 pool 0 (lowdifficulty) [2012-10-09 15:10:48] Pool 0 rejected 11 sequential shares, disabling! [2012-10-09 15:10:48] Switching to stratum+tcp://50.31.149.59:10332 [2012-10-09 15:10:48] Rejected 65f05b02 Diff 1 MM 2 pool 0 (lowdifficulty) [2012-10-09 15:10:48] Rejected 454e85fe Diff 1 MM 10 pool 0 (lowdifficulty) [2012-10-09 15:10:49] Rejected e3379b73 Diff 1 MM 6 pool 0 (lowdifficulty) [2012-10-09 15:10:49] Rejected 5ea8c46e Diff 1 MM 0 pool 0 (lowdifficulty) [2012-10-09 15:10:50] Rejected 8bc9d1a6 Diff 1 MM 7 pool 0 (lowdifficulty) [2012-10-09 15:10:50] Rejected a6f05450 Diff 1 MM 1 pool 0 (lowdifficulty) [2012-10-09 15:10:50] Rejected e447138f Diff 1 MM 10 pool 0 (lowdifficulty) [2012-10-09 15:10:52] Rejected df3e89a8 Diff 1 MM 10 pool 0 (lowdifficulty) [2012-10-09 15:10:52] Rejected 0c93beef Diff 1 MM 1 pool 1 (lowdifficulty) [2012-10-09 15:10:52] Stratum from pool 1 requested work restart [2012-10-09 15:10:53] Rejected 0ba592a1 Diff 1 MM 0 pool 1 (lowdifficulty) [2012-10-09 15:10:53] Rejected 5cedef55 Diff 1 MM 11 pool 1 (lowdifficulty) [2012-10-09 15:10:54] Rejected 29fdaac6 Diff 1 MM 2 pool 1 (lowdifficulty) [2012-10-09 15:10:54] Rejected b41da195 Diff 1 MM 0 pool 1 (lowdifficulty) [2012-10-09 15:10:54] Rejected 2d612681 Diff 1 MM 2 pool 1 (lowdifficulty) [2012-10-09 15:10:55] Rejected 10b690af Diff 1 MM 1 pool 1 (lowdifficulty) [2012-10-09 15:10:56] Rejected ca76b883 Diff 1 MM 11 pool 1 (lowdifficulty) [2012-10-09 15:10:56] Rejected 7d0f83d0 Diff 1 MM 5 pool 1 (lowdifficulty) [2012-10-09 15:10:57] Rejected ff00f1aa Diff 1 MM 8 pool 1 (lowdifficulty) [2012-10-09 15:10:57] Rejected 79b66986 Diff 1 MM 6 pool 1 (lowdifficulty) [2012-10-09 15:10:57] Pool 1 rejected 11 sequential shares, disabling! [2012-10-09 15:10:57] Switching to http://pool.50btc.com:8332 [2012-10-09 15:10:57] Long-polling activated for http://pool2.50btc.com:8331/LP
I am using 2.8.1 with an own Driver for my own Mining Hardware. With Stratum i am not able to connect to BTCGuild. My Hardware generates 12GH/sec. Also switching to an other Username on the pool doesn't help. Seems that my Diff is not increasing. Any Ideas. Going now back to 2.7.5. That's interesting... Think about it.
|
|
|
I've been mining and donating and happy with mtred for quite a while, and I know there is only limited time to dedicate to this pool. However I'd like to ask if there are plans to modernise it in light of likely upcoming changes to the bitcoin mining scene at large? Specifically if stratum support and higher difficulty shares would be considered, as the current hardware seems to struggle under the existing load and with a huge boost in hashrate it cannot be reasonably expected to survive. These 2 changes would likely make it survive 10x the hashrate without any change to the hardware.
|
|
|
Okay, once again I have reuploaded the source tarballs, for 2.8.1 this time.
Thanks a lot. Up and running. There's just a little thing I've noticed with previous versions too. I have some pools in my configuration. At cgminer startup, it starts contacting pools. If it finds a dead pool, it locks for quite a while (minutes) before trying with next pools. The worst case is when the first pool is dead, beacuse cgminer doesn't mine for minutes. I've noticed this thing since I have as my second and third (backup) pools two mtred servers: 1: Enabled Alive Priority 2: http://mtred.com:8337 User:lem98 2: Enabled Dead Priority 3: http://pa.mtred.com:8337 User:lem98 One of them is often dead, so I'm used to see that cgminer waits long before contacting next pools. Yes that's intentional. It is real hard to know if a pool is absolutely down unless you give it enough time. Some just refuse the connection immediately and it's easy to tell it's down. Others will wait 60 seconds and then abort if there's no response. It tries them in order and mines as soon as one is alive, and then tries contacting the other pools at its leisure, waiting 60 seconds at most before moving on to the next pool.
|
|
|
How do you add a stratum only pool? Input server details. URL: stratum+tcp://X.X.X.X:3333/ Username: miner-name Password: miner-pass [2012-10-08 14:27:13] Pool 5 slow/down or URL or credentials invalid <snip> 5: Enabled Dead Priority 5: http://stratum+tcp://X.X.X.X:3333/ User:miner-name Not what I typed.. Ah now I see what the issue is - the trailing slash. There should be no slash after the port number or my code gets confused trying to guess what it is...
|
|
|
|