|
Is there a way to plot this to a db and chart hash rate over time? It could be a flat file/nosql db but would be handy to view the stats historically.
|
|
|
|
Nice work, I noticed the diff reset and hash go to 0 but came up pretty quick. Working well now. A question, if I am in Australia and I have several miners, would I be better to send them to a local ckpool proxy then send that to ck pool in regards to latency and reduced reject/stales?
If your internet bandwidth is often maxed out, especially upstream (such as ADSL which most Australians have) then there is a potential advantage to combining them with a local proxy. On the other hand if you're not maxing it out, you're better off leaving them all connected separately as every extra step in the chain adds its own form of latency. The server is on the west coast of USA though so it's about as close as you can get to Australia and still be in the states. Got them on good fibre so all good. Thanks for clearing that up. |
|
|
|
And a mini bounce for further scalability improvements.
Just so people know what the improvements are, if you check what's gone into the latest ckpool code you'll see changes that correspond with the pool upgrades (doesn't get more open than that does it?).
The ckpool code was not remotely limiting, but being able to see the pool working live and profiling where the CPU is used makes for excellent instant development of whatever is currently the biggest CPU user. The main connection event handler was converted from poll to epoll reducing CPU usage of that to 1/10th and the share processing workqueue was broken up into many threads (proportional to the number of CPUs on the machine) to better distribute out share processing. We're now prepared for about 10x as many workers as we were yesterday, so keep em coming...
Nice work, I noticed the diff reset and hash go to 0 but came up pretty quick. Working well now. A question, if I am in Australia and I have several miners, would I be better to send them to a local ckpool proxy then send that to ck pool in regards to latency and reduced reject/stales? |
|
|
|
|
node back up in Sydney after some issues redownloading Blockchain. ready to roll once again. will consider if a Singapore node is needed anymore.
|
|
|
|
Payout sent a short while ago for the mature block 327110, the newest one 327366 is still yet to mature. Some coding and learning in there for me - the first one I paid with qt, this one I generated the txn info and fed it into the bitcoin interfaces as one does so it took a little longer to do and test. It confirmed while I was typing this also  I'll - yet again - go through the transaction in detail and check it all matches what it should, then the next payout should be a lot quicker. Now a few things: 1) If your payout is less than 10k satoshi, it goes into a dust fund. Some payouts are like a few hundred satoshi and I can't send them without paying silly fees well above the amount or risk the payout never being confirmed. The current payout that just confirmed, I paid no fees in it and it all went ok - I presume that was due to the lack of dust payments. When the payment history is available on the web site, the dust history will show there also, but of course if you mine to an address, you can't login and check that. If your dust never gets above 10k for too long, i.e. you don't mine enough to ever get a payout, I'll probably just use it to add txn fees later. I actually want to be able to fully payout each and every block and keep the pool balance at zero. 2) Some few people don't have addresses still I'll update the web page later to put a message somewhere if you don't have an address. These amounts go into the dust fund also - but will certainly be paid out later once I get an address to pay it to. 3) Round history and payment history It's high on the todo list - but other more urgent things keep happening Will get to it soon. Thanks Kano |
|
|
|
I just picked up two S3's, they should be hashing on here within 24 hours!! Plus my two S1's. Still a pittance I know but it's much more than I've hashed with before. |
|
|
|
|
Singapore server offline for the moment.
Sydney server now on new host using the Microsoft Azure global foundation hosting. This is second to none with perfect network and uptime.
|
|
|
|
Hi Kano, when do you expect to do the payout for the last block? Have you already done it? (just checking I've got my account set up properly)
from freenode#ckpool: [20:42:22] <QG> kanoi_; am i correct that https://blockchain.info/tx/d8b4c28e2ecbba639a14a280511ddf985445da2e9374363c9fcc66b22b54dfe9 needs to reach 120 confirmations before you can distribute shares?
[20:43:27] <conman> yes you're right
[20:43:31] <conman> 100
[20:43:34] <conman> not 120 any more
[20:43:40] <QG> oh ie. https://blockchain.info/tx/d8b4c28e2ecbba639a14a280511ddf985445da2e9374363c9fcc66b22b54dfe9 needs to reach 100 confirmations before the coins are spendable/distributed. QG Ah! Of course, no problems then. 😊 |
|
|
|
|
Hi Kano, when do you expect to do the payout for the last block? Have you already done it? (just checking I've got my account set up properly)
|
|
|
|
6hrs later and still trouble  Seems that the host provider's ddos handling isn't that good at all either. I'm not sure how annoyed everyone mining is but I presume at least some are (understandably) Since, I'm surely annoyed quit a bit about the provider's inability to handle the circumstances ... and keeping my eyes glued it for almost the whole time. The ddos isn't actually directed at the pool but to something else in the datacentre. Check out the Azure stuff mate, pricing is good and services are rock solid. I run all my stuff on there. |
|
|
|
What's up with the pool? It's acting up. I am guessing you guys are on it. Mining and website functions are down.
DDoS at the hosting provider... Yeah my s1's are saying it's down. Get those bastards! |
|
|
|
yup same with Singapore node. both my p2pool nodes have out of cache errors as well.
Seems to be a bug when run for too long they start disconnecting new peers with that...I'm trying to figure out why, but, for now, they should all work atm. it seems to cause p2pool to fall over as well. thats anecdotal of course so can't say for sure but the syptoms seem to line up on both nodes. This one makes no sense...The way it was integrated into p2pool was to just kick off a thread and let it connect to bitcoind (not even to p2pool). Unless it hung python or hung your bitcoind, I dont see how this is possible. yeah liek i said anecdotal, i wanted to be clear on that. I'll do some more testing. |
|
|
|
yup same with Singapore node. both my p2pool nodes have out of cache errors as well.
Seems to be a bug when run for too long they start disconnecting new peers with that...I'm trying to figure out why, but, for now, they should all work atm. it seems to cause p2pool to fall over as well. thats anecdotal of course so can't say for sure but the syptoms seem to line up on both nodes. |
|
|
|
Same here with us-east now. Us-west seems to work fine at this time.
Now? yup same with Singapore node. both my p2pool nodes have out of cache errors as well. |
|
|
|
Ugh, yes, there appear to have been some issues that went unnoticed over the past week or so, should be all good now and I'm monitoring for further hiccups until I can go in and debug a bit more.
au/sg working now. Would there be any negative impact of running two relays to two different relay servers? so if one went down the other would still relay blocks... |
|
|
|
It is how p2pool was intended to be used. Your clients earnings will not change, his accepted shares will have a greater weight, but the overall pool efficiency is increased because he is submitting less shares to be processed by us all.
I missed the first part of this convo but going back I can see now. So if every miner with hash rate > 5% of total hash rate ran the ckproxy, we would see a far more efficient p2pool? that would be higher than around 150th/s right now yes? Yes that is correct, though it is awkward since you need to add yet another layer to the mining, but if you are an owner of hundreds of Terrahash and wish to mine on p2pool, I'm sure you'd be willing to go to the effort. Of course ideally this should happen within the client, or ckpool should take more of the work from the p2pool internals but this way the p2pool client is actually completely native and unmodified (for now). The farm I helped get on board has been off the pool for a little but will be back on again soon, and I anticipate to be helping yet another even larger miner do the same thing soon. This sounds pretty good to me. Could be an interesting concept to explore as a fork. |
|
|
|
I've set up a private pool solution for a reasonably large miner using a combination of p2pool and ckpool technology. You should all see a decent increase in the overall pool size over the next 24-48 hours.
This hasher is now online. His hashrate should be obvious, right at the top of the list. Barring changes in plans, and provided the hardware continues to hash well, it should be remaining on this pool. Now the interesting thing with this is, because I have connected the hardware via ckproxy instead of as 100 connections directly to the p2pool client, p2pool sees it as one client, which means that this miner's share target is more than 10 times larger than that for other miners. By doing this, even though I've dumped a large hashrate onto the pool, it won't substantially increase the target share rate for the smaller miners. This means smaller miners can benefit from the increased p2pool hashrate decreasing their variance without their share target increasing that much which normally increases their variance the same amount. If more larger miners did something similar on p2pool, it might keep the smaller miners. The large miner benefits from his p2pool client scaling where it otherwise couldn't and the smaller miners get to stay and benefit from his presence. While it's not a "fix" for the overall design, it might give p2pool some breathing space, allowing ever larger miners to join. That said, "small" these days is not really that small... Perhaps p2pool will actually end up being nothing but big miners (though that is what most of the network is now), provided their hardware is compatible :p Sorry I'm late to the party, but this is great news and wanted to thank you. While setting "the client" at a higher share diff does nothing for the overall pool diff, it certainly speeds up the pool as a whole vs submitting a bunch of sudo shares that don't meet the minimum diff requirement. It is how p2pool was intended to be used. Your clients earnings will not change, his accepted shares will have a greater weight, but the overall pool efficiency is increased because he is submitting less shares to be processed by us all. I missed the first part of this convo but going back I can see now. So if every miner with hash rate > 5% of total hash rate ran the ckproxy, we would see a far more efficient p2pool? that would be higher than around 150th/s right now yes? |
|
|
|
|
Seeing issues on the sg node again. Had to change to west-us
|
|
|
|
|
11:20 am AEST we lost upstream internet due to Sydney CBD issues on upstream provider. Link is now up, if you had pool.norgzpool.net.au in your miner you should have diverted to the Singapore node automatically.
All systems back to normal. Outage lasted no longer than 20 mins.
|
|
|
|
|
Updated to Bitcoin 0.9.3 (small drop in the charts will be visible).
Node stats are currently as follows:
Version: 13.4-52-g8cffc88
Pool rate: 3.76PH/s (14% DOA+orphan) Share difficulty: 10600000
Node uptime: 10.6 days Peers: 8 out, 1 in
Local rate: 4.69TH/s (6.2% DOA) Expected time to share: 3.4 hours
Shares: 27 total (1 orphaned, 1 dead) Efficiency: 108.0%
|
|
|
|
|
Show Posts
