- General
-
Ideas
Mining Ethereum from a pool's perspective
Since we've mined our first two Ethereum blocks just yesterday I would like to use the opportunity to provide some insight how mining Ether works from a pool's point of view.
A pool basically acts as a proxy between the blockchain's Peer-to-Peer network and the miners. The pool is connected to one or more daemons at all times. Those daemons in turn are connected to the P2P network. The pool monitors the daemons and whenever it determines that a new block has been mined, it requests new work from the daemon and informs all connected miners about the new block - or job. This pattern is true for all mined cryptocurrencies, not just ethereum. What's special about Ethereum is the extremely short time spans between blocks. Whereas most other cryptocurrencies have block times of more than 30 seconds - up to several minutes, new Ethereum blocks arrive sometimes in under one second. Let's use the excerpt below which was extracted from the production pool logs as an example.
Block 4649319 is detected at 10:52:57.0765. The pool immediately notifies the miners ("Broadcasting job") of the new job. Two miners actually manage to submit a share before block 4649320 is detected just three seconds later at 10:53:00.0763. Unfortunately this time only one miner succeeds with submitting a share until we hit the next block 4649321 at 10:53:03.9915. This time we are lucky enough to have this block last almost a minute, thus giving more miners a chance to submit shares. I think everyone will realize that because of those insanely short block times, low latency is absolutely crucial for mining Ethereum. Not only for the miners but also for the pool talking to the blockchain daemon. Most pool implementations rely on asking the daemon for block updates in very fast intervals (more than ten times per second) - this is called polling - in order to detect new blocks as quickly as possible. This results in increased load on the daemon and the internal network. One of the changes we deployed mere hours before finding our first two blocks yesterday was a method for having the daemon push updates to the pool instead of doing it the other way around. As a result of this we've reduced the time between a new block being announced on the P2P network and the pool learning about the evenht to the absolute minimum. I believe we are one of very few pools doing this - if not the only one. But to really take advantage of this we simply need more miners.
[2017-11-30 10:52:57.0765] [I] [eth1] [Ethereum Job Manager] New block 4649319 detected
[2017-11-30 10:52:57.0765] [I] [eth1] [Pool] Broadcasting job
[2017-11-30 10:52:58.3880] [I] [eth1] [Pool] [0HL9NB7K5OOBS] Share accepted: D=0.375
[2017-11-30 10:52:59.5560] [I] [eth1] [Pool] [0HL9NB7K5OOBT] Share accepted: D=0.481
[2017-11-30 10:53:00.0763] [I] [eth1] [Ethereum Job Manager] New block 4649320 detected
[2017-11-30 10:53:00.0763] [I] [eth1] [Pool] Broadcasting job
[2017-11-30 10:53:01.8655] [I] [eth1] [Pool] [0HL9NB7K5OOBS] Share accepted: D=0.375
[2017-11-30 10:53:03.9915] [I] [eth1] [Ethereum Job Manager] New block 4649321 detected
[2017-11-30 10:53:03.9915] [I] [eth1] [Pool] Broadcasting job
[2017-11-30 10:53:05.8918] [I] [eth1] [Pool] [0HL9NB7K5OOBS] Share accepted: D=0.375
[2017-11-30 10:53:13.2260] [I] [eth1] [Pool] [0HL9NB7K5OP2F] Share accepted: D=0.1
[2017-11-30 10:53:15.0510] [I] [eth1] [Pool] [0HL9NB7K5OP4L] Share accepted: D=0.356
[2017-11-30 10:53:15.9560] [I] [eth1] [Pool] [0HL9NB7K5OP4L] Share accepted: D=0.356
[2017-11-30 10:53:18.4359] [I] [eth1] [Pool] [0HL9NB7K5OP17] Share accepted: D=0.322
[2017-11-30 10:53:19.2111] [I] [eth1] [Pool] [0HL9NB7K5OOBS] Share accepted: D=0.375
[2017-11-30 10:53:20.2321] [I] [eth1] [Pool] [0HL9NB7K5OOBS] Share accepted: D=0.375
[2017-11-30 10:53:22.0209] [I] [eth1] [Pool] [0HL9NB7K5OOBT] Share accepted: D=0.481
[2017-11-30 10:53:23.3830] [I] [eth1] [Pool] [0HL9NB7K5OP17] VarDiff update to 0.54
[2017-11-30 10:53:24.2158] [I] [eth1] [Pool] [0HL9NB7K5OP2F] Share accepted: D=0.1
[2017-11-30 10:53:24.3368] [I] [eth1] [Pool] [0HL9NB7K5OP17] Share accepted: D=0.545
[2017-11-30 10:53:25.0484] [I] [eth1] [Pool] [0HL9NB7K5OOBT] Share accepted: D=0.481
[2017-11-30 10:53:31.3341] [I] [eth1] [Pool] [0HL9NB7K5OP4L] Share accepted: D=0.356
[2017-11-30 10:53:33.1879] [I] [eth1] [Pool] [0HL9NB7K5OOBT] Share accepted: D=0.481
[2017-11-30 10:53:37.3864] [I] [eth1] [Pool] [0HL9NB7K5OP2F] Share accepted: D=0.1
[2017-11-30 10:53:40.0190] [I] [eth1] [Pool] [0HL9NB7K5OOBS] Share accepted: D=0.375
[2017-11-30 10:53:43.6154] [I] [eth1] [Pool] [0HL9NB7K5OOBT] Share accepted: D=0.481
[2017-11-30 10:53:46.5382] [I] [eth1] [Pool] [0HL9NB7K5OOPC] Share accepted: D=0.552
[2017-11-30 10:53:52.2728] [I] [eth1] [Pool] [0HL9NB7K5OOPC] Share accepted: D=0.552
[2017-11-30 10:53:57.2219] [I] [eth1] [Pool] [0HL9NB7K5OP17] Share accepted: D=0.545
[2017-11-30 10:53:57.7361] [I] [eth1] [Pool] [0HL9NB7K5OP17] Share accepted: D=0.545
[2017-11-30 10:53:58.6192] [I] [eth1] [Pool] [0HL9NB7K5OP4L] Share accepted: D=0.356
[2017-11-30 10:54:00.9873] [I] [eth1] [Pool] [0HL9NB7K5OP2F] Share accepted: D=0.1
[2017-11-30 10:54:01.1095] [I] [eth1] [Pool] [0HL9NB7K5OP2F] Share accepted: D=0.1
[2017-11-30 10:54:01.1473] [I] [eth1] [Ethereum Job Manager] New block 4649322 detected
Customer support service by UserEcho
This was a nice read! Aren't the blocks coming in even faster than under a minute? I am seeing 3-5 blocks per minute, so that probably averages at around 15secs per block.
I am a small hobby miner on my work-at-home desktop, and will add a 2nd GPU before Xmas. I know it's a tiny bit, but we are a hive! :)
Thank you. That's why I wrote "Ethereum blocks arrive sometimes in under one second" :-)
I was surprised and disappointed to learn Ethereum is especially picky about ping times. I have 180 to 200 ms latency to this pool and I'm thinking I should consider switching back to ethermine or something else. Can the techs confirm what is the correct decision for me?
Yeah latency is important. I think the pool operator was considering or working on supporting more GEOs, but not sure at what stage this is. Let's see what he tells you.
@Jim: Nowadays all pools and miners are using the stratum protocol which means your miner maintains a connection to the pool at all times. Ping in turn measures round trip time. Therefore because of the persistent connection you can basically cut you ping time in half to get the real pool-to-miner latency which your case wouldn't be that bad at 95ms average. But I really don't want to convince you to anything. If you feel safer joining a pool closer to you that also has a higher block rate then by all means do it.
But what is your honest opinion about the effect of say 100 ms latency? Is there a probability that 100 will substantially effect share rate or block solution? Note: I was paid out on the previous two blocks and the total seemed pretty good for just a couple days of mining..
My honest opinion is that you should experiment a bit and stick to what works best for you. My gut feeling is that 100ms should be fine.