I am having some issues compiling 2.10.4. I've been following the same steps to compile for months and can compile 2.9.7 and prior versions without issue, it's just 2.10.x versions. I think it might be a dependency, but I'm not that linux savy. I have run "apt-get update && apt-get upgrade" to make sure things are current. This is running on a Atom based Mini-ITX MB running Debian 6 with 7 BFLs. (Other than this new compile issue, it's been running great for 6 months) I did read back around 15 pages to the point where 2.10.0 was released and did not see anyone having any issues with compiling. I also checked the README.txt and it looks like I have all the dependencies. If anyone can point me in the right direction, I'd appreciate it. Thank you. CFLAGS="-g -O2 -W -Wall" ./autogen.sh --enable-bitforce --with-libudev
Returns the following: curses.TUI...........: FOUND: -lncurses Looks OK, but then I get these errors when running "make": (I have tried make clean first as well) util.c:207: error: āCURLOPT_TCP_KEEPALIVEā undeclared (first use in this function) That looks like your curl installation is a version that somehow should support CURLOPT_TCP_KEEPALIVE (version 7.25.0+) but then actually doesn't. That should not happen since it is supposed to detect what version of curl you have installed and choose appropriate support. Perhaps you have only a partly installed or mixed installation of libcurl development libraries. |
|
|
|
|
Don't forget his ultimate hypocrisy. He hates alt-coins yet when I wrote the scrypt support for cgminer, he still pulled the scrypt code into his hostile fork of my code since he couldn't stand not having a feature that cgminer has.
|
|
|
|
|
The honest answer is a combination of effort required to get it up and running and stay in sync with p2pool changes, profit margins being lower due to the altered block nature and higher effective rates of lost work, and the intermittent issues that seem to repeatedly plague p2pool during development. Most people use pools to avoid the rolling release/change cycle at the pool end since that adds yet another potential point of failure on top of getting your client right. Setting up 3 or 4 regular pools with failover is mostly a fire and forget thing for miners by comparison.
|
|
|
|
|
If mining is not profitable, people will not do it. Mining will always parallel the difficulty/BTC value relationship and will always be slightly profitable with people coming and going to stick to that equation over time with some lag time to stay in sync with it.
|
|
|
|
After two hours on p2pool/cgminer/Stratum, I got a block http://blockchain.info/block-index/329787 and Best Share reads 9.69M Current difficulty is 2.98M. Shouldn't I get credit for at least three blocks on that?  Cool! Wrong reward system  |
|
|
|
Upgraded. Doesn't seem to have decreased cgminer stales though.  M Maybe not, but at least if you had >50GH devices it wouldn't struggle with keeping it busy. |
|
|
|
BTW, Stratum support is finished and will be released later today.
Great. I just released a new version of cgminer, 2.10.4, as a hotfix to ensure it works with p2pool stratum. |
|
|
|
|
New version: 2.10.4, 29th December 2012
Mainly a hotfix release supporting the upcoming stratum implementation in p2pool.
Human readable changelog:
p2pool is about to release their stratum support, and cgminer would just crash on it. This version fixes it.
It was possible to mine on a stratum pool before the actual stratum structures were set up depending on when the pool sent out its notify details after authorisation.
The WU: value was not being reset when Zero stats was being used.
Full changelog:
- Change the pool stratum socket buffer to be dynamically allocated to
accomodate any size coinbase and keep receiving data in recv line for up to 60s
if no end of line has been received.
- Differentiate socket full from sock full.
- Allow stratum to startup without notify but check it is valid before creating
stratum work.
- Do not try to generate stratum work unless the notify command has succeeded.
- Reset total diff1 shares when zeroing stats as well to show correct work
utility.
|
|
|
|
Updated to cgminer 2.10.3 and now all is stable! No more "SICK" shares, and no re-starts needed! Thanks a million ckolivas!!
You're welcome  |
|
|
|
woooo hoooooo 49.4M
[Found Blocks] => 1
[Best Share] => 49402097
Nice!  Were you running PoT on ozcoin? If so, at what diff and did you check the pot calculator to see how much that one share was worth? http://tradebtc.net/potcalc.php |
|
|
|
Ha ok, I missed it, sorry. Preorder ? Maybe BFL build these ? They're already offering them, with a lead time of 4-6 weeks. |
|
|
|
Love it * ckolivas keeps playing with manual diff settings to try and hedge his bets accordingly. |
|
|
|
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.
Bump? Suggest stratum + share rate of up to 24/min. Would be nice to mine here once again, but at 50 times the reject rate of a modernised pool, I'm finding it hard to justify. (2% stales on mtred versus .04% on ozcoin) |
|
|
|
I see some people connected on stratum but most people aren't sending any shares. Plase make sure your cgminer is atleast 2.10.3 ! Otherwise the share difficulty in cgminer ill be for bitcoin difficulty and you won't be sending any shares Latest bin can be found here http://ck.kolivas.org/apps/cgminer/Use the client.get_version feature of stratum from the pool to detect miners that are on cgminer 2.10.2 and you can drop their connection almost instantly, making them investigate and hopefully upgrade. |
|
|
|
I am a little bit confused. What difficulty is this, 2.6M or 40? "target": "00000000000000000000000000000000000000000000000000fb650600000000",
"data": "00000001bece016f6cd7b6168a5b686840c2184e4de9dadcb5b0fd269687d8a9cbcd25945179969c324587aeca65baba6f8c60eed93f96c2e4c66c5adcfc5e2c1560226650db22e91c0665fb00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000"
This is getwork from my Litecoin client. Cgminer thinks this is 2.6M difficulty. Check last FAQ in readme. |
|
|
|
Thinking about continuing trial and lowering a=0.8 to 0.75 or 0.7 reduces variance a little and raising cap to 5*D instead of 1.5*D feedback welcome I'd consider coming back if a stayed at 0.8 and the cap increased. Lowering it lowers the max payout. Honestly, though, with difficulty decreasing significantly for both btc and nmc, I'm leaning towards staying on p2pool for a while. M The higher the cap goes, the more risk the pool takes. The miner's per share income drops ever so slightly when the cap is raised, but almost a non-noticeable amount. So really, the miners should have nothing against raising the cap, it's up to the pool op to decide how much risk to take. On the other hand though, the a value changes dramatically how much variance the miner is likely to see (and then how high the reward would be at the max cap). I'm quite happy with a high a and the cap being equal to difficulty since I'm actually unlikely to find a block at my hashrate, but others may see things differently |
|
|
|
Binaries no longer included?
You mean linux binaries I guess. I made them but forgot to upload them. There now. |
|
|
|
New version of cgminer, 2.10.3 should finally have fixed the "best share" displayed bug  . It also offers a Zero statistics button in the Display menu allowing people to reset stats. |
|
|
|
|
New cgminer release with scrypt goodies, including block solve detection and fixed stratum support.
|
|
|
|
|
Show Posts
