martok (OP)
|
|
June 02, 2011, 04:17:34 PM |
|
Ok, balancecurrent is really expensive in terms of performance and RPC is timing out with this long a round. I am trying to figure a faster way to do this.
Assuming the problem is summing over all the shares of the worker, note that shares older than the last 10,000 or so will have negligible score, so you can just find out the ID of the last share and use "where ID > X-10000" or similar. Great, that's a big help. Yeah, it's the big table scan that's bogging it down. Edit: balance updated to only scan last 10,000 shares. Note that the final round payment calculation still scans all shares. There's still room for improvement in the final calculation. At the current r, shares older than 17,000 will have score less than double-precision granularity, so they won't have any effect anyway. Hmm, you mean no material affect? Round 4 payment calc: select max(score) from share = 646.164449020304 shares = select count(*) from share where score is null = 281610 maxid = select max(id) from share 828713 totscore = select sum(exp(score-max))+exp(score-os) from share = 436.318039783311 payment calc select exp(score-totscore) from share order by id values: 5.43924628175081e-284 5.45174116086077e-284 5.46426474284596e-284 5.47681709364117e-284 ... So they're very small, enough so that we could ignore them but they don't underflow the double precision type.
|
|
|
|
Meni Rosenfeld
Donator
Legendary
Offline
Activity: 2058
Merit: 1054
|
|
June 02, 2011, 04:37:11 PM |
|
Ok, balancecurrent is really expensive in terms of performance and RPC is timing out with this long a round. I am trying to figure a faster way to do this.
Assuming the problem is summing over all the shares of the worker, note that shares older than the last 10,000 or so will have negligible score, so you can just find out the ID of the last share and use "where ID > X-10000" or similar. Great, that's a big help. Yeah, it's the big table scan that's bogging it down. Edit: balance updated to only scan last 10,000 shares. Note that the final round payment calculation still scans all shares. There's still room for improvement in the final calculation. At the current r, shares older than 17,000 will have score less than double-precision granularity, so they won't have any effect anyway. Hmm, you mean no material affect? Round 4 payment calc: select max(score) from share = 646.164449020304 shares = select count(*) from share where score is null = 281610 maxid = select max(id) from share 828713 totscore = select sum(exp(score-max))+exp(score-os) from share = 436.318039783311 payment calc select exp(score-totscore) from share order by id values: 5.43924628175081e-284 5.45174116086077e-284 5.46426474284596e-284 5.47681709364117e-284 ... So they're very small, enough so that we could ignore them but they don't underflow the double precision type. I was talking about granularity (precision), not minimal representable number. If you add 1 + 1e-17 you'll get back 1, because double has only 52 bits of precision, or roughly 16 decimal digits. So scores less than this will have no effect on the final numerical score.
|
|
|
|
Transcendental
Newbie
Offline
Activity: 14
Merit: 0
|
|
June 02, 2011, 11:16:07 PM |
|
Ok, balancecurrent is really expensive in terms of performance and RPC is timing out with this long a round. I am trying to figure a faster way to do this.
As for hashrate, did the miner submit an unusually low number of shares during the interval you checked?
no, I have been watching it today and while it was normal for most of the day again it's listing me at Client hashrate 372230498 just 20 mins ago it was Client hashrate 1417339207
|
|
|
|
Transcendental
Newbie
Offline
Activity: 14
Merit: 0
|
|
June 02, 2011, 11:18:20 PM |
|
J after posting my last reply now I am getting the following error message File "/usr/local/poclbm/BitcoinMiner.py", line 259, in longPollThread (connection, result) = self.request(connection, url, self.headers) File "/usr/local/poclbm/BitcoinMiner.py", line 222, in request response = connection.getresponse() File "/usr/lib/python2.6/httplib.py", line 990, in getresponse response.begin() File "/usr/lib/python2.6/httplib.py", line 391, in begin version, status, reason = self._read_status() File "/usr/lib/python2.6/httplib.py", line 355, in _read_status raise BadStatusLine(line) BadStatusLine 02/06/2011 18:16:37, long poll exception: Traceback (most recent call last): File "/usr/local/poclbm/BitcoinMiner.py", line 259, in longPollThread (connection, result) = self.request(connection, url, self.headers) File "/usr/local/poclbm/BitcoinMiner.py", line 221, in request else: connection.request('GET', url, headers=headers) File "/usr/lib/python2.6/httplib.py", line 914, in request self._send_request(method, url, body, headers) File "/usr/lib/python2.6/httplib.py", line 951, in _send_request self.endheaders() File "/usr/lib/python2.6/httplib.py", line 908, in endheaders self._send_output() File "/usr/lib/python2.6/httplib.py", line 780, in _send_output self.send(msg) File "/usr/lib/python2.6/httplib.py", line 739, in send self.connect() File "/usr/lib/python2.6/httplib.py", line 720, in connect self.timeout) File "/usr/lib/python2.6/socket.py", line 561, in create_connection raise error, msg error: [Errno 101] Network is unreachable
|
|
|
|
martok (OP)
|
|
June 02, 2011, 11:35:20 PM |
|
J after posting my last reply now I am getting the following error message File "/usr/local/poclbm/BitcoinMiner.py", line 259, in longPollThread (connection, result) = self.request(connection, url, self.headers)
Brought down the server to add HTTP keepalive support. Also, found the hashrate bug.
|
|
|
|
Meni Rosenfeld
Donator
Legendary
Offline
Activity: 2058
Merit: 1054
|
|
June 03, 2011, 01:24:11 PM |
|
Can you add functionality to create and delete monitors to the website?
|
|
|
|
memvola
|
|
June 04, 2011, 11:24:33 AM |
|
I can now see a hashrate being reported for 1LLdCXQohpJcZpKrwGc9ebgfKrDanYuwKC, that's good enough for me, I assume the balance probably won't show till > 1btc?
Balance is updated in realtime. And now it is for PPS as well. Your new address's balance should climb each time you submit a share. Note that the hashrate is over a 5 minute window so if you haven't submitted a share within that window, it goes to 0. I see my balance with a faster miner but I have a slower one connected as well and can't see its balance, although I've been submitting shares for some time and see the hash rate. ... OK, now I switched to PPS and saw my balance after submitting a share. I guess share!=score and doesn't have to lead to a positive balance? Anyway, what I was meaning to ask is, what happens if I want to leave the pool for some reason? Do you pay the remaining balance after a week of absence as Eligius does?
|
|
|
|
Etherael
Newbie
Offline
Activity: 19
Merit: 0
|
|
June 04, 2011, 12:10:09 PM |
|
How long after ticking over to 1 btc is the transfer made?
|
|
|
|
Transcendental
Newbie
Offline
Activity: 14
Merit: 0
|
|
June 04, 2011, 09:40:42 PM |
|
How long after ticking over to 1 btc is the transfer made?
martok has said as soon as 1btc is reached (I believe), however I myself have noticed that the smallest payments I have receieved have been in 3btc increments. Sometimes it has taken 24 hours, but the last payment I received (this is purely anecdotal) was instantaneous as soon as I started an instance of bitcoin. Also: martok, current balance and client hashrate is down once again.
|
|
|
|
martok (OP)
|
|
June 04, 2011, 11:14:28 PM |
|
How long after ticking over to 1 btc is the transfer made?
martok has said as soon as 1btc is reached (I believe), however I myself have noticed that the smallest payments I have receieved have been in 3btc increments. Sometimes it has taken 24 hours, but the last payment I received (this is purely anecdotal) was instantaneous as soon as I started an instance of bitcoin. Payments should be close to when you tick over 1 BTC but there are potential delays. The payment script runs from an hourly cron so there is a bit of slack there. This allows the pool to combine transactions when possible IE I can send payments to 5 workers using 1 nonstandard transaction. It's also potentially possible for PPS miners to get delayed if the bitcoind on the pool lacks a balance. I need to fix that manually when it happens though that has only occured once thus far. Not an issue for regular pool mining.
|
|
|
|
Etherael
Newbie
Offline
Activity: 19
Merit: 0
|
|
June 04, 2011, 11:50:19 PM |
|
|
|
|
|
Etherael
Newbie
Offline
Activity: 19
Merit: 0
|
|
June 06, 2011, 05:10:14 AM |
|
Coming up on 72 hours now.. no payout and no response, something up?
|
|
|
|
fsasa70
Newbie
Offline
Activity: 47
Merit: 0
|
|
June 06, 2011, 05:26:20 AM |
|
Coming up on 72 hours now.. no payout and no response, something up?
Go PM martok (the pool operator). His been helping me solve my problem (payout) and what not. Sometimes the payout is delayed too.
|
|
|
|
Transcendental
Newbie
Offline
Activity: 14
Merit: 0
|
|
June 06, 2011, 05:37:21 AM |
|
It is possible that you are not receiving payment for your pps because the current round started 5-30, this is the longest it has been since we have found a block since I joined. PPS was implemented during this time, so there may not be any coins to payout yet.
|
|
|
|
fsasa70
Newbie
Offline
Activity: 47
Merit: 0
|
|
June 06, 2011, 01:27:03 PM |
|
Wow so this round has been over a week already So what's the pools total hashrate?
|
|
|
|
Meni Rosenfeld
Donator
Legendary
Offline
Activity: 2058
Merit: 1054
|
|
June 06, 2011, 06:42:59 PM |
|
It is possible that you are not receiving payment for your pps because the current round started 5-30, this is the longest it has been since we have found a block since I joined. PPS was implemented during this time, so there may not be any coins to payout yet.
PPS means payment is received for every share regardless of blocks found. If what martok implemented is different then he's wrong to call it PPS.
|
|
|
|
martok (OP)
|
|
June 07, 2011, 12:47:51 AM |
|
To PPS-mode miners.
My appologies for the payout delays. The good news is, PPS-mode has found a block and all payouts will be dispatched as soon as it matures tomorrow. Additionally, I am moving more BTC over to the pool to hopefully eliminate this in the future.
For regular pool, I nearly have the database dump scripts complete and share/score traces will be made available on the website shortly to provide some needed pool integrity. You will be able to verify scores, solutions and the payouts.
|
|
|
|
martok (OP)
|
|
June 07, 2011, 06:17:03 PM |
|
All payments have been sent. There is now plenty of BTC in reserve so hopefully a delay like this won't happen again. Once again, sorry for the inconvenience.
|
|
|
|
Dronix
Newbie
Offline
Activity: 1
Merit: 0
|
|
June 08, 2011, 05:30:01 AM |
|
Brand new to BTC but I noticed this thread in my initial research and decided to join the pool earlier this week. So is it normal for a pool to go this long without finding a block? I've thrown my 1.15 Gh/s into the hat (score-based), but seeing as the round hasn't ended since I joined I have yet to see my first bitcoin.
|
|
|
|
martok (OP)
|
|
June 08, 2011, 05:46:40 AM |
|
Brand new to BTC but I noticed this thread in my initial research and decided to join the pool earlier this week. So is it normal for a pool to go this long without finding a block? I've thrown my 1.15 Gh/s into the hat (score-based), but seeing as the round hasn't ended since I joined I have yet to see my first bitcoin.
This is an abnormally long round. At current hashrates, we should on average find a block every 3 or so days. However, the more people who join the pool, the lower our time to find a block and the more even the payouts. So hopefully the situation improves over time.
|
|
|
|
|