This can allow miners to know precisely when to give up on it and get new work. How would the pool provide a sane value, since it doesn't know when the next block will be found? |
|
|
|
What are "shares" anyways? Are they not simply difficulty 1 proofs? If the difficulty level is at 45 then theoretically shouldn't I find a block every 45 shares created? There are 1200 shares sitting in my MySQL DB so if that was true then I should have about 26 blocks by now, no? Indeed, a share is a difficulty 1 proof, which has a small percentage chance of also meeting the real difficulty (45 in this case). You'll find a block every Target Difficulty (45 in this case) shares on average. So yes, as you quoted in my post, I generated 1000 shares, and at difficulty 38 I should have gotten approximately 26 blocks. But I only found 2 blocks. Whereas when I pointed my miners at bitcoind directly I began finding blocks at the expected rate. Obviously something was screwy. |
|
|
|
Yay! Looks like all the blocks have confirmed and payments have been sent  |
|
|
|
DE0-Nano is $80 USD for a Cyclone 4 CE22. I haven't used one before, but it seems like a pretty good price point and the board is very spartan. There are also small Xilinx boards out there that are cheap; just the chip, USB, and GPIO. I can't remember the name of it ... the FPGA mining thread lists it somewhere, amongst lots of other options.
|
|
|
|
|
Wow, this pool has been crazy lucky after that first monster round. 4 blocks now! WOO!
|
|
|
|
|
PM'd bitcoinaddict, but didn't hear anything back yet.
|
|
|
|
thanks for all your hard work so far, is there anyway you could have a sof file preconfigured at 80Mh/s for my de2-115? You are most welcome  Do you have appropriate cooling on your DE2-115? 80MHz on the DE2-115 will damage your FPGA without proper cooling, and will also fail to generate correct shares. I can make a SOF regardless and let you know the cooling requirements, but I want to make sure you are fully aware of the dangers (like the loss of $600 when your FPGA dies from heat). |
|
|
|
During the course of the first round, I noticed I was mining at 5-6% rejection rate. After seeing that, I started to investigate. Long story short I came to an odd conclusion. Some shares were being rejected for no obvious reason whatsoever. Here are the circumstances of those rejected shares: 1) Lots of accepted shares surrounding it. 2) No new blocks recently found. 3) Timestamp adjustment disabled. 4) Work shouldn't be much older than 13 seconds. 5) Share verified on CPU by poclbm (so the GPU isn't to blame). BurningToad: Any idea why these shares might have been rejected? I used my local long polling patch, which verifies #2 above. #3 means that the only thing the miner is fiddling with is the nonce, in case changing the timestamp was causing a weird bug on the pool. #4 means the share wasn't rejected because its timestamp was too old. The only other thing I can think of is the pool giving me duplicate work. I have vague memory of other pools running into this problem; where they were seeing high rejected share rates and discovered the pool was giving out duplicate work. EDIT: Found the thread I remember. http://forum.bitcoin.org/index.php?topic=14483.0. Bitcoins.lc was having duplicated work problems, and it turned out to be a bug. BurningToad you could check your DB and see if a lot of rejected shares are due to duplicate work. |
|
|
|
|
I think the finder should get an extra reward for cracking such a difficult block!
|
|
|
|
poclbm is a Python miner, and as such doesn't need to be compiled. Are you using Linux or Windows? If Linux, you just need to have PyOpenCL installed and you should be good to go (./poclbm.py) If you're on Windows, you have a few options. 1) Find a pre-compiled version of PyOpenCL for your installed version of Python and use that. 2) Compile PyOpenCL yourself 3) Use my version of poclbm, for which I built a Windows EXE: http://forum.bitcoin.org/index.php?topic=19169.msg254264#msg2542644) If you have Python 2.6 installed, you might be able to just use the compiled version of PyOpenCL included in poclbm binary releases. Also of particular note are Luke Jr's modifications to poclbm: http://forum.bitcoin.org/index.php?topic=19051.0 |
|
|
|
Mining software must communicate with a pool/proxy/bitcoind for two reasons; to get work and to submit work. The most common protocol (supported by every mining software I've seen) for that is JSON-RPC: http://en.wikipedia.org/wiki/JSON-RPC. This is the request a miner makes to the server to get new work: {"params": [], "method": "getwork", "id": "json"}An example response by the server: {"id":"json","error":null,"result":{"midstate":"b07ab2ccf48b89a0217384c1299d8b7e7cc9bb7ac16dd1366d9955669cb253aa","target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000","data":"0000000146f6a6158418099f9c3a68ffec435166cfdb9eef51479153000001ee000000004d3a3c9c00dc8b69df7c0e9b4f3fa4ea587cddd2392d186e9dca1b5ea1669ea74e03844d1a13218500000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000"}}An example of the request made by a miner to submit results: {"params": ["000000019a086f0290f4b6d34a6e1b8a4b9974d585819abcd8e8f3d400000b5d00000000aaf9271bb6c2892dd5f96a71da1ed4be9b234f74a8de246acd91851a6639e1904e0384731a132185d1684680000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000"], "method": "getwork", "id": "json"}And the server's response (if the result was correct): {"id":"json","error":null,"result":true} |
|
|
|
How do I implement this in Ubuntu 10.10, SDK-2.1 and Cat-11.2? From memory, so I may mis-type somethinggit clone git://github.com/progranism/poclbm fpgaminer-poclbm
cd fpgaminer-poclbm
git checkout with-luke-jr-mods
./poclbm.py
|
|
|
|
This supports my theory, that there has to be another or additional reason for the client to fetch new work, me thinks. From a technical perspective, the client doesn't need to request work more often than has been outlined. However, the reality is that a lot of mining software will request work at fixed intervals anyway (in addition to Long Polling). This is for two reasons. Historically, Long Polling didn't exist; so asking for work frequently was the only way to prevent a large number of stale shares. A lot of mining software stuck to keeping that "askrate" functionality, and adding Long Polling alongside it. "If it isn't broken, don't fix it," sort of mentality. The second reason is, well, things break. Long Polling may fail, and the software may not even know that it failed. So asking for work every so often, despite what the Long Polling functionality may have indicated, is a good backup plan to prevent stale shares. But, in the end, a lot of getworks are not bad for me, but for the pools, because they get more requests, right? Correct, extra getworks really only affect the pools. If your ISP has strict bandwidth limitations then maybe it has an impact on you as well. But it doesn't cost you extra processing power and memory, like it does the servers. I don't think i should have to care about that too much any further, should I? I've only seen one pool that has explicitly made the "efficiency" of the miner an issue; BitcoinPool.com. It's commendable, for sure; waste is waste, no matter how you look at it. But achieving 100% efficiency while keeping stale shares to a minimum is a technically difficult challenge, and the mining software developers aren't getting paid for their work  |
|
|
|
That's what I do too but it raises the error. Yikes, yeah. Well, to be honest, pyopencl looked like a bit of a pain to compile when I took a look at it last, and I couldn't find anything pre-compiled. Hopefully someone else can chime in here. Other than that, you may want to take a look at my branch, for which I did put together a ready to run Windows exe: http://forum.bitcoin.org/index.php?topic=19169.msg254264#msg254264For that one I copied over the pyopencl binaries from the original poclbm packaging, so I didn't have to compile pyopencl.  My branch includes luke jr's modifications, but it also uses the phatk kernel (which may give you a speed boost). |
|
|
|
poclbm does not work, it gives an error about access rights and I did not bother to look at it more deeply.
I've made a few more tests with your work and it always freezes or traps after a few minutes of work. The longest run has been less than half an hour. Did you chmod +x poclbm.py? Either way, sounds like your setup doesn't like poclbm for some reason. I can't think of anything else to try. I normally don't develop GPU miners works great in win7 32bit
better than phoenix
send you 0.1 Thank you, wahbasah. That is very much appreciated. I hope it helps you make more Bitcoins  |
|
|
|
Just to give credit, where credit is due. One of the extenders I ordered and received last week was bad. I contacted Cablesaurus and they promptly shipped a new one. Got it today and works great. So, thank you and keep up the great work! Buy things with Bitcoins is lots of fun. |
|
|
|
poclbm looks like python too, but has binaries. and how do i use the source? The Windows release of poclbm uses py2exe to create an EXE for us lazy Windows users You use it by doing "python2.7.exe bitcoin-luke-jrs-poclbm\poclbm.py" Luke-Jr: Great work! I merged this with my branch and it seems to be working wonderfully so far. I haven't measured connection performance, but it's very nice to have it tally up the rejected statistics and such. Thank you for this great improvement to poclbm |
|
|
|
|
Show Posts
