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.
Topic: KanoPool kano.is lowest 0.9% fee 🐈 since 2014 - Worldwide - 2432 blocks - page 2242. (Read 5352633 times)
November 01, 2014, 03:19:43 AM
November 01, 2014, 03:05:24 AM
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. November 01, 2014, 02:46:10 AM
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...
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?
November 01, 2014, 02:04:13 AM
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...
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...
October 31, 2014, 08:42:08 PM
Sorry, full restart took a little longer than planned. Up properly now.
seems to be working well.
October 31, 2014, 08:32:31 PM
Sorry, full restart took a little longer than planned. Up properly now.
October 31, 2014, 08:30:40 PM
So I have been mining an s-3 for about 40 of the 80 hours it took to make the block.
So we wait for payouts about 10 hours?
So we wait for payouts about 10 hours?
October 31, 2014, 08:20:51 PM
There'll be a little blip in mining as we upgrade the ckpool code. You may see a small burst of rejects and a redirect notice but you probably won't failover during the upgrade due to the way ckpool handles changeover, but if you do it won't last long.
I'm noticing it
October 31, 2014, 08:08:48 PM
There'll be a little blip in mining as we upgrade the ckpool code. You may see a small burst of rejects and a redirect notice but you probably won't failover during the upgrade due to the way ckpool handles changeover, but if you do it won't last long.
October 31, 2014, 07:57:57 PM
That's ridiculous.
M
M
October 31, 2014, 06:54:05 PM
wicked! BTC
October 31, 2014, 06:42:40 PM
We just found another. 
October 31, 2014, 06:41:31 PM
... and it confirmed shortly after that - so all good
October 31, 2014, 06:35:07 PM
Thank you sir, may I have another!
October 31, 2014, 06:28:57 PM
https://blockchain.info/tx/7b47a5415f69a092f5d2c252ff6bc60f34c333e52ef04cdc24adf485f9db270d
QG
Code:
[10:25:54] blockchain only showing 1 block so that's a good sign :)
[10:26:03] yoouu pew pew pew!!!
[10:26:03]
QG
October 30, 2014, 10:29:43 PM
Updated the top post to reflect our new best hashrate. Stored for prosperity.
Code:
[2014-10-30 19:53:15] Pool:{"hashrate1m": "666T", "hashrate5m": "667T", "hashrate15m": "665T", "hashrate1hr": "653T", "hashrate6hr": "632T", "hashrate1d": "627T"}
6 6 6 the number of the beast
Official pool of SATAN!! 10/10 would mine again
Happy Halloween to every miner hashing through these ghoulish times
October 30, 2014, 09:27:47 AM
Updated the top post to reflect our new best hashrate. Stored for prosperity.
Code:
[2014-10-30 19:53:15] Pool:{"hashrate1m": "666T", "hashrate5m": "667T", "hashrate15m": "665T", "hashrate1hr": "653T", "hashrate6hr": "632T", "hashrate1d": "627T"}
6 6 6 the number of the beast
please update to 700+
as you are over 710th
October 30, 2014, 09:17:05 AM
I'm in with 3 of my S3+.
October 30, 2014, 05:19:54 AM
Updated the top post to reflect our new best hashrate. Stored for prosperity.
Code:
[2014-10-30 19:53:15] Pool:{"hashrate1m": "666T", "hashrate5m": "667T", "hashrate15m": "665T", "hashrate1hr": "653T", "hashrate6hr": "632T", "hashrate1d": "627T"}
6 6 6 the number of the beast
October 30, 2014, 03:56:29 AM
Updated the top post to reflect our new best hashrate. Stored for prosperity.
Code:
[2014-10-30 19:53:15] Pool:{"hashrate1m": "666T", "hashrate5m": "667T", "hashrate15m": "665T", "hashrate1hr": "653T", "hashrate6hr": "632T", "hashrate1d": "627T"}
Jump to: