Luke do you think that the fact that I have both Icarus and Bitforce miners is somehow relevant? It shouldn't be, but I can try it I guess... Only have 1 Icarus though - what's your environment like? Could you also try cgminer 2.10.4 to see if you get any Comm errors from one of your Bitforce singles? That definitely happens for me with the latest cgminer build - the whole reason that caused me to look for an alternative to see if the same thing happens (ie to bfgminer). cgminer's Bitforce driver is based on bfgminer's, except they've added a bunch of bugs. I could try it next, but as long as bfgminer works, I don't see a point... |
|
|
|
Here is what I found. With cgminer 2.10.4 the comm error shows up. With bfgminer 2.9.4 it works but I believe the system is restarting so it's causing a system crash. bfgminer 2.10.1 is misreporting the hash rate for the bfl singles (at random) I've been running 2.10.0 on my pi since it was released (with MMQ), and it seems to work fine with BFL (though I only just now moved it from my development system to the pi). I built 2.9.7, and will let that run for a bit to test. How long does it usually take to reboot your pi? After that, I can test the latest 2.10.x, but I don't expect any change from 2.10.0... 2.9.7 takes about 2 hours to cause a system reboot. Hmm, well it's been 5 hours on 2.9.7 and no problems of any sort... trying BFG 2.10.2 now. |
|
|
|
Luke jr, I thought you were anti stratum last I checked  I'm anti-stratum for the pool<->miner connection, because it is* harmful to Bitcoin's security. In this case, the p2pool daemon is running locally, so it makes sense. (It also makes more work for me, and slush did it behind closed doors instead of contributing to the open developement of GBT) * slush added a get_transactions method to allow for more transparent stratum use, but in this usage, it just consumes more bandwidth than GBT with none of the benefits |
|
|
|
Here is what I found. With cgminer 2.10.4 the comm error shows up. With bfgminer 2.9.4 it works but I believe the system is restarting so it's causing a system crash. bfgminer 2.10.1 is misreporting the hash rate for the bfl singles (at random) I've been running 2.10.0 on my pi since it was released (with MMQ), and it seems to work fine with BFL (though I only just now moved it from my development system to the pi). I built 2.9.7, and will let that run for a bit to test. How long does it usually take to reboot your pi? After that, I can test the latest 2.10.x, but I don't expect any change from 2.10.0... luke-jr@raspberrypi /opt/vc/bin $ ./vcgencmd version
Nov 22 2012 18:09:58
Copyright (c) 2012 Broadcom
version 352766 (release)
luke-jr@raspberrypi /opt/vc/bin $ uname -a
Linux raspberrypi 3.2.27+ #285 PREEMPT Tue Nov 20 17:49:40 GMT 2012 armv6l GNU/Linux |
|
|
|
I can't help but wonder why p2pool isn't more popular than it is? From what I'm seeing in the various pool threads, most, if not all pools, keep having problems. Either namecoin crashes, hardware issues, or DDOS attacks. Why not use p2pool? Eligius has been pretty stable for a while, and offers most of p2pool's features without its limitations (high variance, high bandwidth/CPU, more maintenance, more vulnerable to DDoS, etc). Anyone who can manage setting up a mining farm, large or small, shouldn't have any difficulty setting up a p2pool node. Then you can do your own namecoin merged mining if you wish (most pools seem to be dropping namecoin support), but most importantly, you're then part of a decentralized pool. If someone gets DDOSed, that node goes down, but the rest keeps working, unlike a conventional pool. It takes less bandwidth to DDoS every p2pool node, than to DDoS some of the non-p2p pools. A number of these non-p2p pools also support decentralized mining.Yes, there are public p2pool nodes. I don't suggest using them unless you have a really small operation, as they are no better off than normal public pools. They're worse, in fact, since they are centralized. While GBT's bandwidth usage is reasonable for ordinary Bitcoin mining, it's massive for p2pool's 10 second blockchain, so not a viable option there (yet). |
|
|
|
EDIT: You can disable cgminer's auto-switching to Stratum if you think Stratum is worse by using --fix-protocol on cgminer Or --disable-stratum in BFGMiner. But note that in general, stratum is better than getwork and makes good sense for local stuff like p2pool. |
|
|
|
i have add {target2bdiff(target)} and get this error
Traceback (most recent call last):
File "/xxxxxxxxxxxxxxxxxxxxx/jsonrpcserver.py", line 200, in _doJSON_i
rv = getattr(self, method)(*params)
File "/xxxxxxxxxxxxxxxxxxxxx/jsonrpc_getwork.py", line 44, in doJSON_getwork
return self.doJSON_submitwork(data)
File "/xxxxxxxxxxxxxxxxxxxxx/jsonrpc_getwork.py", line 81, in doJSON_submitwork
self.server.receiveShare(share)
File "/xxxxxxxxxxxxxxxxxxxxx/eloipool12.py", line 579, in receiveShare
logShare(share)
File "/xxxxxxxxxxxxxxxxxxxxx/eloipool12.py", line 568, in logShare
i.logShare(share)
File "/xxxxxxxxxxxxxxxxxxxxx/sharelogging/logfile.py", line 60, in logShare
logline = self.fmt.formatShare(share)
File "/xxxxxxxxxxxxxxxxxxxxx/util.py", line 55, in formatShare
(stmt, params) = self.applyToShare(*a, **ka)
File "/xxxxxxxxxxxxxxxxxxxxx/util.py", line 62, in applyToShare
params.append(f(share))
File "/xxxxxxxxxxxxxxxxxxxxx/util.py", line 115, in <lambda>
return lambda s: target2bdiff(subfunc(s))
File "/xxxxxxxxxxxxxxxxxxxxx/util.py", line 44, in target2bdiff
bdiff = bdiff1target / target
TypeError: unsupported operand type(s) for /: 'int' and 'NoneType'
so it look like {target2bdiff(target)} is buggy but {target2pdiff(target)} seems to be ok  what means when someone have 1 ? and other user None ? as a result {target2pdiff(target)} in share log ? Some errors/rejects occur before the pool knows the target the share is being submitted at, so those get None. As you noticed, target2bdiff doesn't like this currently... should be an easy fix. |
|
|
|
but eloipool does not log share difficult by default ? how to enable this feature ?
or I have to swith off dynamic target/difficult (DynamicTargeting =0 ) to get correct PPS calculation ...
or it does not depends from DynamicTargeting variable, and PPS calculation (and in fact other method ?) is impossible in eloipool ?
Eloipool doesn't log anything by default. You have to configure it. Take your pick (add to share log statement - note the difference between curly braces and normal parenthesis): - {target} - Full target as a number (up to 256 bit; you probably don't really want this)
- {target2pdiff(target)} - Target converted to "pool difficulty" (pdiff 1 = first 32 bits of target are 0, rest is 1; this is what pools used before vardiff)
- {target2bdiff(target)} - Target converted to truncated "bitcoin difficulty" (bdiff 1 = first 32 bits of target are 0, next 16 are 1, then the rest are 0; this is what bitcoind reports as the difficulty)
|
|
|
|
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. FWIW, the cgminer problem here was fixed in BFGMiner 2.9.2 (Nov 5, 2012), so there should be no need for a new version to use p2pool + stratum. |
|
|
|
is it possible to use PPS reward shares count to use with GBT/stratum/dyntarget ? does GBT/stratum/dyntarget/proxy affects shares count ?
i want to use eloipool with PPS reward method (count shares in database) is it correct ? or wrong method with eloipool and GBT/stratum/dyntarget/proxy enabled ?
Eloipool just handles the miners. It's up to you how you pay them. As long as you log the share target/difficulty, you should be able to calculate the correct PPS value for each share. |
|
|
|
Those are wrong data from client.
thanks for very fast answer is it danger (someone try to mess (steal 25 BTC? fake shares ?) , or DoS pool ? ) ?or just ignore this messages ? Nah, I just ignore them. The error is caught and ignored in Eloipool, but logged just in case the admin cares (like when I'm debugging it or BFGMiner ) whish database should I use ? (mysql is useless... exception, disconnections etc.) whish version sql lib should i use ? which do you prefer on jour computer ? I use sqlite+flatfile for testing, and Eligius uses Postgres. I think EclipseMC figured out the MySQL mess... |
|
|
|
|
Those are wrong data from client.
|
|
|
|
NEW VERSION 2.10.2, DECEMBER 27 2012Human readable changelog:- There is now a [Z]ero stats option under the display menu which resets all the visible statistics.
- The current pool target diff is now shown in the status line like so:
Connected to mining.eligius.st diff 1 with LP as user 16kNKa7WUg8QAPFy8dJRv7USSu2fAG2pkW - The current block target diff is now shown in the status line like so:
Block: 00000599115b83cd... Diff:2.98M Started: [11:15:11] Best share: 7.73k - Block solve detection is now supported with scrypt mining as well (BLOCK! written at end of share and solved blocks listed under pool stats).
- Stratum support for scrypt mining.
- Numerous subtle bugfixes.
Full changelog- Update documentation to include block difficulty
- Reset all stats when requested
- Reset total diff1 shares when zeroing stats as well to show correct work utility.
- Update documentation.
- Parse anything in the stratum socket if it's full without waiting. Empty the socket even if a connection is not needed in case there are share returns.
- Provide a mechanism to zero all the statistics from the menu.
- Display the current pool diff in the status line.
- Display block diff in status line.
- Generalise the code for solving a block to enable block solve detection with scrypt mining.
- Generate the output hash for scrypt as well and use the one function to set share_diff.
- Use one size for scratchbuf as a macro in scrypt.c
- Remove the unused sha224 functions.
- Check staged_rollable under staged lock, when cloning available work.
- scrypt_diff uses a uint64_t as well.
- Correct target for stratum support with scrypt mining.
- Bugfix: Ensure nonces are put in data as little-endian in test_nonce*
- Add low-level debugging info for data_buffer (some only enabled with -DDEBUG_DATABUF)
- Make all_data_cb fwrite-compliant by returning nmembs, and check for unlikely overflows
- Bugfix: Need to do extract_sockaddr before trying to initiate stratum (erroneous http URI usage, except at startup)
- Bugfix: Update last GBT work in pool_active before staging it, since otherwise it could possibly be consumed before we copy it
- Bugfix: Address Windows-specific formatting issues (including lack of support for %ll*)
- Bugfix: ztex: Correct formatting for reset failure error
- ztex: Fix formatting in a debug message
- cairnsmore: Don't bother timing dynclock detection, since there's no standard way to log it accurately
- Correct formatting in FPGA drivers
- opencl/adl: Fix formatting to fit strict rules
- Explicitly cast all_data.buf to char* for debug printing
- Follow strict time_t handling rules
- Use GNU format-checking attribute when available for applog
|
|
|
|
.....
But, overall, CPPSRB works best with any consistent miner.
-wk
Are you certain about that? How are intermittent miners penalised? I'd thought CPPSRB was fine for all miners, big or small, consistent or intermittent. There's no penalty. But a intermittent miner would throw all their shares within a certain part of the share log, so the possibility that part of the sharelog goes unpaid would mean a higher % lost than if the same shares were spread out over the sharelog more. |
|
|
|
I thought it's a very popular feature used by a lot of people.
Is there a reason why Coderrr or you (I think you released a test version with the coincontrol patch) dropped this? You'd have to ask coderrr. I was only making minor changes to rebase it on the latest master, not really maintaining it. |
|
|
|
Will the coin control feature be added to the official client?
I really got used to this very useful option. Only if someone is actually interested in porting it to the current code and fixing the remaining issues. It's gone months, and nobody has stepped up. |
|
|
|
BTW: When people say chances of collision is low they don't mean 'low' as people use the word in normal everyday life. In reality the chances are infinitely small. The chance of Sol going supernova in the next microsecond is considerably larger then the chance of a collision ever occurring. For a properly generated address, right. But this one came from a closed source vanity address generator of dubious design. |
|
|
|
Probably a good idea to take all funds out of keys generated with this program until this risk is resolved... Can you elaborate? Is the risk lack of entropy in the RNG? the other thread doesn't mention this tool explicitly... I don't think anyone knows for sure what's up yet. I spoke to TheButterZone on IRC and he said it was this tool. |
|
|
|
Also, "the other day" I had said I use brainwallet.org saved to a USB key for offline use. This doesn't actually make brain wallets safe. |
|
|
|
Probably a good idea to take all funds out of keys generated with this program until this risk is resolved... |
|
|
|
|
Show Posts
