Now you can really increase effeciency to the level of other pools.
ROFL. You're funny. Please prove that statement and post the # of getwork request and # of submitted shares (which you already do) for each round on your site, and that will show the efficiency of your pool. I'll show you mine if you show me yours....oh wait....we already do show that.  |
|
|
|
Even with long polling, the main version is still averaging 5 - 10 seconds before asking for more work, which prevents you from working through the entire getwork.
Are you sure about that ? It should request new getwork only after checking through all the nonce or 60 seconds of work, whatever comes first. All nonce is checked in ~7 seconds on 5870 GPU. Line 114 - 115 of BitcoinMiner.py self.askrate = max(int(askrate), 1)
self.askrate = min(self.askrate, 10) Yes, we're sure. If you use more than 10 seconds for the askrate, it will force a maximum of 10 seconds. So that great that it's ~ 7 seconds on that card, but not everyone uses the same card, and can take longer than 10 seconds to work through an entire getwork. Also, poclbm requests a new getwork when the first nonce is found, and doesn't keep working through the rest of the getwork looking for more nonce's. You can find more than 1 nonce in a getwork. These are just a few changes to our modified version. We thought that checking the miner's local bitcoind would be a viable way to detect when the block changed and request a new getwork, but that's not always the best solution. The reason that it is not the best solution is my local bitcoind may have been notified that the block count changed, but the pool's bitcoind may not have gotten the memo at the same time my local bitcoind did. So a race condition is in effect, and the miner requests a new getwork, then seconds later the pool's bitcoind got the memo and updated it's block count, and the getwork my miner just got becomes stale. But sometime's it's the other way around too. So long polling seems to be the better solution. |
|
|
|
I miss NullVoid. I miss it so much that I found a cached copy of the statistix php code on this forum and dropped it on our site. This is lacking the nice graphs that nullvoid had, but it's a start if you want some stats about the rate at which blocks are being found. http://bitcoinpool.com/statistix/If anyone else can dig up some more cached code from nullvoid and wants it hosted somewhere, find the cached code then point me at it. I'll do my best to get it up and working. |
|
|
|
Are you still accepting blocks from the previous round and giving credit for those blocks.
No, and we never have given credit for blocks from previous rounds. We only give credit currentBlock-1 to the current block of the bitcoin network in the current round. We will be changing this back to current block only this weekend. If so, I would be curious as to the percentage of credit from those blocks. I am running miners on three different pools right now as an experiment and bp isn't doing so well in comparison at present. Not statistically significant yet though. Was just curious if stale submitions are hurting the pool.
Stale submission's don't hurt the pool because we reject them, they just don't get counted by us which means the miner just wasted some time. I think it is far more likely that the other pools are doing "better" because they have more users and operates at a faster Ghash/s. I'm not sure as to the efficiency of those pools, but I can tell you that when our pool is running @ ~4 Ghash/s, it's only using up ~ 30KB of bandwidth...which is nothing on a 50/50 Mbps connection and quad-core server. To me, the extra bandwidth and server load isn't a big deal, hence why I wanted to start a server with no fees or forced donations. BTW, Geebus would be able to answer this better, but *i think* our modified miner supports long polling now too. He said yesterday he was working on it, but I'm not sure if he got it done yet. I know we have long-polling working server side right now, but it's been buggy and we're working on some changes we hope will make it better. Geebus, can you fill in the blanks here about poclbm-mod?? |
|
|
|
We just had another hiccup with python. For some reason it quit responding to some requests but not others. I double checked to make sure this wasn't a SYN flood, and it doesn't appear to be any sort of attack. I do find it curious how the server likes to do this right before I go to bed though. Go figure. Regardless, it's kinda of a strange phenomenon going on, but tomorrow I think I'll be working on a systems check script to run in the background to make sure that when this happens again, it gets detects the affected service at a reasonable rate, restarts the affected services, and sends me a SMS message so I know what's going on (which will improve response time and reduce down time). Gotta love the beta stage...mostly working, but sometimes broken. Thank you for your patience and tolerance, we do appreciate it. |
|
|
|
Port 8334? I'm connected on port 8332 which is the default....
We started with port 8334. Then we noticed several people trying on port 8332. So we redirected port 8332 to 8334 on the router. Now both ports 8332 and 8334 go to the same port on the server. |
|
|
|
1) How many people really want to be able to increase their payment threshold, and why?
Big number of small free transactions is not optimal for bitcoin network, they may be delayed if you get more users and more frequent blocks. That is a good point. Thanks. |
|
|
|
When clicking any link in stats page which shows solved blocks, http://bitcoinpool.com/block.php?block=112689Gives error "Direct access to this location is not allowed." How to logon to the site bitcoinpool.com with the user name & password, besides new user, there is no link to login to bitcoinpool.com. We got that fixed. Someone was trying to access one of the sub PHP files directly (the one that calls to the round duration timer) and it was causing problems. The error you saw was our way of fixing that, but we went a bit over board. Whoops. Thank you for reporting the problem. |
|
|
|
We are aware that the pool just quit responding to request. We are investigating and will let you know when it's back online.
Thank you for your understanding.
We're back online. Still investigating as to what the cause was. |
|
|
|
|
We are aware that the pool just quit responding to request. We are investigating and will let you know when it's back online.
Thank you for your understanding.
|
|
|
|
Why am I last seen 1hr in th future on my individual stats ?
The server's time is listed in UTC. I just looked at your profile, and nothing is listed in the future. You are in the New York area, which puts you in the EDT (UTC/GMT -5 hours) timezone. The server uses a UTC timezone. Since the time on the server is now 17:43 (UTC), subtract 5 hrs from that, and it's 12:43 your time. More information can be found here: http://www.dxing.com/utcgmt.htmAdd welcome back to the pool. |
|
|
|
I'd like to take a moment to thank all the miner's who have stuck it out in our pool. THANK YOUI know this round has been over 3 days now, and we don't have the amount of users that other pools do. The network difficulty went up recently, and that's not helping our cause any, hence why it is taking longer for us to find a block. If you haven't updated your miner to the newest version, you should do so. It can check against your local bitcoin instance for when the block count goes up. When this is detected, the miner drops the work it's doing and gets new work from the server. This helps you and the server by making sure we're working on the most current block. Thank you for your patience; we do appreciate it. Fingers crossed that we get a block soon. And please update your miners, it will help. |
|
|
|
Its working now, must have been some network issue between me and you.
Glad to hear it is working now. Thank you for reporting the issue initially. |
|
|
|
The Web server is back online now.
I'm getting: Problems communicating with bitcoin RPC I also don't seem able to traceroute to the server, although I can load the web page That's odd. I checked my remote miner and it's able to communicate with the server. What's the full command line your running? (Filter your username and password of course |
|
|
|
Here is an example output from the updated client. 03/14/2011 17:28:28, d68204e5, accepted at 84% of getwork[79]
03/14/2011 17:28:29, 34cf459f, accepted at 92% of getwork[79]
03/14/2011 17:30:15, Block has changed. Getting new work...
03/14/2011 17:31:06, 410b5070, accepted at 4% of getwork[86]
The new miner checks your local bitcoin instance for the block change. When the block change is detected, it will ask the server for a new getwork. |
|
|
|
The Web server is back online now. We are currently working on the web server. If the web page goes offline for a few minutes, don't worry, it will be back.
You're miners should be able to keep mining though.
|
|
|
|
1) It decreases load on the server by not asking for work as often, which benefits the server.
Seems like it would be better for the entire community, if you simply worked with other pool servers to accomplish the same goal. If you support long polling, then the default upstream poclbm (m0mchil's) -- and soon, every other miner -- will only ask for work once every ~60 seconds. Community standards like this benefit everyone. I just want to make sure I understand this correctly. I'm taking the definition of long polling from deepbit.net's page. Long polling protocol description
1) Miner initiates connection to the mining pool just as usual, requests getwork and starts working on it.
2) If mining pool does supports Long Polling, it should include a special header:
X-Long-Polling: /long-polling-url
where /long-polling-url is a path for long polling connection.
3) Miner starts a request to long polling URL with GET method and basic authorization (the same as on main connection).
This request is not answered by server until new block is found by bitcoin network. The answer is the same as getwork on the main connection. Upon receiving this answer, miner should drop current calculation in progress, discard it's result, start working on received data and make a new request to a long polling URL.
4) If all the nonce space is exhausted during calculation or 60 seconds passed since receiving the data, the miner should request new one by means of main connection. 60 seconds limit is set to allow adding new transactions into the block.
Would this be an accurate description? If so, I'm not sure exactly when we will be implementing it. Probably soon though for compatibility with other clients. In the mean time, people could use our modified miner and have it check against their local bitcoind or "bitcoin -server" for GUI's, and it would accomplish the same effect. |
|
|
|
|
We are currently working on the web server. If the web page goes offline for a few minutes, don't worry, it will be back.
You're miners should be able to keep mining though.
|
|
|
|
The operators of BitcoinPool actively DON'T want your client software to be compatible with other pools. They've recently changed it so that their miner doesn't run if it isn't connecting to BitcoinPool.com.
In my opinion, it makes them look like children who don't want to share, and personally I'd never do business with them.
NO, we just block Slush's pool. Deepbit.net or any other pool it works fine with our modified miner. Slush likes his getwork request once per second, which is inefficient. Not to mention he gave us a lot of crap over this, so I see no reason for him to get the benefits of this. Whether you use our miner or m0mchill's original poclbm, you will get the same number of shares submitted. Ours is just more efficient about it. |
|
|
|
For those of you who are running more than one PC for bitcoin mining on your LAN, here is an example of how to get more than one PC working with a single instance of bitcoin. This means you don't have to have a bitcoin instance running on each PC in order for your poclbm-mod to be able to check if the block count went up. For this example we will use 2 PCs. PC 1: IP: 192.168.22.2Runs "bitcoin -server" so I can have my GUI and run as a RPC server. In order to setup the RPC server, you have to create a bitcoin.conf file in the specificed user folder. Windows users: %APPDATA%\Bitcoin\bitcoin.conf Linux users: ~/.bitcoin/bitcoin.conf An example config for bitcoin.conf is as follows: rpcuser=yourusername
rpcpassword=somerandompassword
rpcallowip=192.168.22.* **Please note that you should create a random password here to make sure that unauthorized parties don't get access. You will also need change the rpcallowip value to match your local networks address mask. The "*" at the end means anyone on your local network can connect to your local bitcoin application. If you want the miner to use your local bitcoin to check the block count, your will need to modify the "poclbm-mod.cfg" file to reflect the settings of your bitcoin.conf on PC 1. The "poclbm-mod.cfg" file should be in the same directory as poclbm-mod. An example config is as follows: host=192.168.22.2
port=8332
rpcuser=yourusername
rpcpass=somerandompassword Make sure you set the host value to your PC's IP address. Now launch poclbm-mod: poclbm-mod.exe --host=bitcoinpool.com --port=8334 --user=username --pass=password -d 0 -f 120 -v -b --log Make sure you have the same "poclbm-mod.cfg" file on PC 2 that you have on PC 1. Then launch poclbm-mod: poclbm-mod.exe --host=bitcoinpool.com --port=8334 --user=username --pass=password -d 0 -f 120 -v -b --log That's pretty much it. Nothing too fancy. I hope you found this helpful. |
|
|
|
|
Show Posts
