Continuum Mining Pool: No fees; Client uptime monitoring via twitter and email

[martok]

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.

[1713858281]

1713858281

[1713858281]

1713858281

[1713858281]

1713858281

[1713858281]

1713858281

[1713858281]

1713858281

[Meni Rosenfeld]

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]

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]

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]

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]

Can you add functionality to create and delete monitors to the website?

[memvola]

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]

How long after ticking over to 1 btc is the transfer made?

[Transcendental]

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]

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]

Got it, just for the record http://www.continuumpool.com/balance.php?worker=1LLdCXQohpJcZpKrwGc9ebgfKrDanYuwKC this has been this way for about 24 hours now.

Cheers

[Etherael]

Coming up on 72 hours now.. no payout and no response, something up?

[fsasa70]

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]

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]

Wow so this round has been over a week already 

So what's the pools total hashrate?

[Meni Rosenfeld]

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]

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]

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]

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]

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.