Bitcoin Forum
December 07, 2016, 04:36:58 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Poll
Question: The pool currently runs at a 0 expected fee. Would you prefer a 1 percent fee in exchange for the pool paying out for all solved blocks including those that fail to mature? Majjority rules.
No, keep it the way it is.
Yes, impose a 1% fee and pay out for all blocks including those that fail to mature.

Pages: « 1 2 3 4 5 [6] 7 8 9 10 11 12 13 14 15 »  All
  Print  
Author Topic: Continuum Mining Pool: No fees; Client uptime monitoring via twitter and email  (Read 47815 times)
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
June 02, 2011, 08:09:34 AM
 #101

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.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
1481128618
Hero Member
*
Offline Offline

Posts: 1481128618

View Profile Personal Message (Offline)

Ignore
1481128618
Reply with quote  #2

1481128618
Report to moderator
1481128618
Hero Member
*
Offline Offline

Posts: 1481128618

View Profile Personal Message (Offline)

Ignore
1481128618
Reply with quote  #2

1481128618
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481128618
Hero Member
*
Offline Offline

Posts: 1481128618

View Profile Personal Message (Offline)

Ignore
1481128618
Reply with quote  #2

1481128618
Report to moderator
martok
Full Member
***
Offline Offline

Activity: 140


View Profile
June 02, 2011, 04:17:34 PM
 #102

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 Offline

Activity: 1890



View Profile WWW
June 02, 2011, 04:37:11 PM
 #103

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.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
Transcendental
Newbie
*
Offline Offline

Activity: 14


View Profile
June 02, 2011, 11:16:07 PM
 #104

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 Offline

Activity: 14


View Profile
June 02, 2011, 11:18:20 PM
 #105

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
Full Member
***
Offline Offline

Activity: 140


View Profile
June 02, 2011, 11:35:20 PM
 #106

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 Offline

Activity: 1890



View Profile WWW
June 03, 2011, 01:24:11 PM
 #107

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

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
memvola
Hero Member
*****
Offline Offline

Activity: 896


View Profile
June 04, 2011, 11:24:33 AM
 #108

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 Offline

Activity: 15


View Profile
June 04, 2011, 12:10:09 PM
 #109

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

[url=https://cryptanalys.is/profile.php?u=etherael
Transcendental
Newbie
*
Offline Offline

Activity: 14


View Profile
June 04, 2011, 09:40:42 PM
 #110

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
Full Member
***
Offline Offline

Activity: 140


View Profile
June 04, 2011, 11:14:28 PM
 #111

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 Offline

Activity: 15


View Profile
June 04, 2011, 11:50:19 PM
 #112

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

[url=https://cryptanalys.is/profile.php?u=etherael
Etherael
Newbie
*
Offline Offline

Activity: 15


View Profile
June 06, 2011, 05:10:14 AM
 #113

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

[url=https://cryptanalys.is/profile.php?u=etherael
fsasa70
Jr. Member
*
Offline Offline

Activity: 45


View Profile
June 06, 2011, 05:26:20 AM
 #114

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 Offline

Activity: 14


View Profile
June 06, 2011, 05:37:21 AM
 #115

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
Jr. Member
*
Offline Offline

Activity: 45


View Profile
June 06, 2011, 01:27:03 PM
 #116

Wow so this round has been over a week already  Cry

So what's the pools total hashrate?
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
June 06, 2011, 06:42:59 PM
 #117

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.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
martok
Full Member
***
Offline Offline

Activity: 140


View Profile
June 07, 2011, 12:47:51 AM
 #118

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
Full Member
***
Offline Offline

Activity: 140


View Profile
June 07, 2011, 06:17:03 PM
 #119

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 Offline

Activity: 1


View Profile
June 08, 2011, 05:30:01 AM
 #120

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.
Pages: « 1 2 3 4 5 [6] 7 8 9 10 11 12 13 14 15 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!