Some numbers (my Intel Atom netbook):
Original sources: 10000 getworks generated in 26.482 sec, 377 gw/s
C extension: 10000 getworks generated in 3.481 sec, 2872 gw/s
Beagleboard XM (~equivalent of Raspberry Pi):
C extension: 10000 getworks generated in 12.270 sec, 814 gw/s
Xeon 3.2 (older) under ESXi/debian6 10000 getworks generated in 1.186 sec, 8430 gw/s Opteron 865 1.8ghz under openVZ/debian6 10000 getworks generated in 0.934 sec, 10709 gw/s Xeon W3505 under Mint12 10000 getworks generated in 0.529 sec, 18886 gw/s |
|
|
|
|
[EDIT: Found problem, when you push broken binary to 10 machines, they all fail the same way - fan control appears fine, sorry for the false alarm]
2.8.2 working just fine for me, DIFF >2 like a charm.
|
|
|
|
dlasher, can you confirm that this bug happen also when proxy is NOT in the chain? I'd like to know if there's something broken in proxy.
I can't confirm it, because I don't have any single miners fast enough to get above diff=2 without a proxy. |
|
|
|
Let me know if there's debug options/versions/etc I can try to identify the issue. What strikes me as useful is testing: - after 2.8+proxy goes bad, restart ONLY cgminer - no change in behavior
- cgminer 2.7 with proxy - didn't test
- cgminer 2.8 without proxy - works fine
My first step this morning was to shut off the proxy, and let cgminer fail down to stratum pools directly, and back to diff=1 shares. Which works fine, because, as it turns out, there's evidently a cgminer bug with 2.8.1, with miners getting stuck, when they're using >DIFF=4. Several users at btcguild have confirmed seeing the issue. https://bitcointalk.org/index.php?topic=28402.msg1263116#msg1263116 |
|
|
|
Slush: I think I've found a bug, but i have no idea how to identify or fix it. I've been mining with cgminer 2.8.1 + stratum behind proxy, to btcguild for a while.. (and with 2.7 behind proxy before that), and it's been very stable, solid. Once everything smooths out, my miners were all taking 16-diff shares. Last night about 20:30 PST, my reported hashrate dropped to half, and cgminer was only working 4-diff shares. All cgminer derived graphs (cacti/etc) showed no change, but btcguilds page showed the drop:  Graphs from btcguild.com btw --- love that pool!I left it alone for a couple hours, thinking it would stablize, and it didn't, so about midnight, I dropped back to cgminer 2.7.6, no stratum, and bypassed the proxy. Voila, hashrate resumes. Let it run that way all night, then shifted back to proxy+stratum again this morning. Hashrate dropped to half, and I'm stuck at 4-diff shares. Talked to Eleuthria at length, initially blaming the btcguild in some way. He's convinced that cgminer/proxy are 'disconnected' somehow on share-diff. The proxy is submitted 2-diff, but handing-out 4-diff shares to my miners. His logs show half my normal rate of submitted shares. At present I'm back to bypassing the proxy, and running a non-stratum version of cgminer. This behavior has survived proxy restart/reboot, cgminer restart/reboot,etc. I'm on latest GIT of both cgminer and mining-proxy. Let me know if there's debug options/versions/etc I can try to identify the issue. |
|
|
|
|
Thanks again for the proxy, loving it.. two small feature requests:
1. Fail over/back/load balance/etc for multiple servers.
2. syslog facility/target?
|
|
|
|
Interesting error thrown tonight, not sure what to make of it: 2012-10-09 20:06:58,826 INFO proxy stratum_listener.submit # [59ms] Share from 'my-miner6' REJECTED: (-2, u'stale', None)
2012-10-09 20:06:58,827 ERROR protocol protocol.process_failure # [Failure instance: Traceback (failure with no frames): <class 'stratum.custom_exceptions.RemoteServiceException'>: (-2, u'stale', None)
]
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/Twisted-12.2.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1043, in _inlineCallbacks
result = result.throwExceptionIntoGenerator(g)
File "/usr/local/lib/python2.7/dist-packages/Twisted-12.2.0-py2.7-linux-x86_64.egg/twisted/python/failure.py", line 382, in throwExceptionIntoGenerator
return g.throw(self.type, self.value, self.tb)
File "/usr/src/stratum-mining-proxy-rev1.0/mining_libs/stratum_listener.py", line 163, in submit
result = (yield self._f.rpc('mining.submit', [worker_name, job_id, tail+extranonce2, ntime, nonce]))
RemoteServiceException: (-2, u'stale', None)
|
|
|
|
|
Thanks, will read up.. Managed to brick a wrt610n trying to get openWRT running.. time for jtag.
|
|
|
|
cgminer will add http:// if it can't connect to whatever url you gave it. Yes it does look like it shouldn't have done it in this case  The stratum+tcp:// is optional and it will always try stratum on that port first. If it did that then perhaps there was something wrong with the url/port put in or the pool was not responsive at the time. perhaps an additional field for "pool-type" with "stratum, http, both" as options, to allow the user the option to control, including following the x-stratum header? Can you think of a reason you wouldn't want to use stratum mining? I can come up with a couple, I'm sure others could as well. Mine was more of a question of choice. Maybe I don't want to automatically promote to stratum? - if multiple servers return a single IP address for statum server
- if you're working around/through a proxy and you want to not use stratum?
- if you'd like to treat stratum and http as different options from a pool-handling standpoint
btw, if I haven't said it lately, I appreciate VERY much both the product (cgminer) and the author (you).. and your commitment to listening to users like I, asking for changes in a free product!  |
|
|
|
|
P_Shep, thanks for doing this!
What are you doing for a compile env? are you actually compiling on your openWRT box, or did you build an Env on a i386/x64 machine? If the later, any links/guidance to doing the same?
|
|
|
|
cgminer will add http:// if it can't connect to whatever url you gave it. Yes it does look like it shouldn't have done it in this case The stratum+tcp:// is optional and it will always try stratum on that port first. If it did that then perhaps there was something wrong with the url/port put in or the pool was not responsive at the time. perhaps an additional field for "pool-type" with "stratum, http, both" as options, to allow the user the option to control, including following the x-stratum header? |
|
|
|
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.. |
|
|
|
New version - 2.8.0, 7th October 2012
This version is a massive upgrade compared to the stable 2.7 releases and involves over 1000 lines of changed code and a lot of new work implementing the stratum protocol for pooled mining, which is currently only implemented on slush's and btcguild pools. With such a massive change, breakage is likely but there have been numerous people who have graciously tested along the way paving the way for a much more bug tested release to the public.
<looked, didn't find this answer in the readme/notes/etc>In the case of X-Stratum headers, what's the behavior on failure of the "promoted" stratum pool? Does it fail back to "demoted" pool, or mark the entire "pool" dead and fall down to the next one? |
|
|
|
|
which tag/target in the makefile makes a bundle ready for binary download (precompiled) without .o files, etc?
|
|
|
|
|
Slush, I'm testing the new version of cgminer+stratum behind the proxy and I ran into an interesting question/issue.
BTCGuild returns stratum information in it's header, which the proxy passes through to cgminer. Cgminer then takes that IP and bypasses the proxy.
In theory, shouldn't the proxy be able to relabel the header response to keep itself in the chain? (maybe make that behavior a command-line-switch?)
|
|
|
|
Right, a question without an obvious answer. The point of the stratum header on the regular getwork pools is to redirect them to a better protocol pool. The fact that btcg redirects all pools to the same one stratum pool is more a sign of early days with btcg having only one stratum server. I'm guessing with time btcg will have 3 stratum servers to match its 3 getwork servers.
I'll be updating the BTC Guild getwork-based backends to use different X-Stratum redirects this week, now that we're starting to see integration in the most widely used miner. Thank you! |
|
|
|
|
Interesting behavior/question with stratum version..
On my test machine, I have pools set up the following way:
0 - stratum proxy
1 - btcguild #1
2 - btcguild #2
3 - btcguild #3
cgminer talked to pool0 (the proxy) and immediately punched right through to the real IP address for the stratum server, not using the proxy any more.
So should bypass the proxy when it sees the header, or should it stay pointed there? (IE what if the stratum server is diff hostname/IP than the configured pool?)
(as a side note, it immediately reduced all 4 pools to a single IP address, based on the headers it received from each server, since btcguild only has 1 stratum server today, but that will change has they add more)
|
|
|
|
Stratum update
<snip>
If you're on linux, and can use git, checkout the stratum branch and build from that.
git pull -a && git checkout stratum
Grabbed, compiled, playing with it on a single machine. (wish it had a subversion# or something so I'd know which was running..) Didn't change a single line of my config file, and it's working for multiple host entries and pools, including moving away from the stratum proxy directly to the stratum pool. Too soon to tell if there are any issues, but I'll let you know. Thanks again for all your hard work! btw, what happens if stratum+tcp fails.. does it drop back to http or eliminate the pool# alltogether? |
|
|
|
|
Show Posts
