I would like to know approximately how long it will take my geth node to complete syncing. There was a previous question that was similar to mine, but less specific, and it was closed in favor of a question about how to get the highest block number. Since it was not possible to add an answer to the closed question, and the other question does not answer my question, I am asking this version of the question.


You can enter the following code to estimate the time remaining in minutes. It samples the current block at two different times to estimate the time remaining. Note that if your current block doesn't change during this time, then it can't estimate it.

In geth console:

function printSyncForecast() {
    if (!eth.syncing) return "Your node isn't syncing."
    var sampleSeconds = 10
    var currentBlock = eth.syncing.currentBlock;
    if (!eth.syncing) return "Your node stopped syncing."
    var blocksSynced = eth.syncing.currentBlock - currentBlock
    var blocksPerMinute = blocksSynced * 60 / sampleSeconds;
    if (blocksPerMinute === 0) return "Current block didn't change; try increasing the sample time";
    var blocksRemaining = eth.syncing.highestBlock - eth.syncing.currentBlock;
    var minutesRemaining = blocksRemaining / blocksPerMinute;
    return "node synced " + blocksSynced + " blocks in " + sampleSeconds + " seconds (" + blocksPerMinute + 
      " blocks/minute.)  If these 📈 continue, node will sync the remaining " + blocksRemaining + " blocks in " + 
      minutesRemaining + " minutes."

Here's a one-liner from the command line using a minified version of that code:

geth attach --exec '(function(){if(!eth.syncing)return"Your node isnt syncing.";var n=eth.syncing.currentBlock;if(admin.sleep(10),!eth.syncing)return"Your node stopped syncing.";var e=eth.syncing.currentBlock-n,t=60*e/10;if(0===t)return"Current block didnt change; try increasing the sample time";var c=eth.syncing.highestBlock-eth.syncing.currentBlock;return"node synced "+e+" blocks in 10 seconds ("+t+" blocks/minute.)  If these 📈 continue, node will sync the remaining "+c+" blocks in "+c/t+" minutes."})()'
  • 2
    I realize it's an estimate, but I'm also not sure it's a particularly useful estimate, at least until you're almost done syncing. The reason for this is that different slices of time in the Ethereum blockchain's history yield very different block processing rates. Early blocks process very quickly because the chain can live in cache and there were few transactions. Fast forward to fall 2016. The state chain bloat attack slows down processing of blocks despite blocks not being full. Late 2017 results in slow processing due to heavy transactions (read: CryptoKitties). It works for you, great :)
    – lungj
    Mar 9 '18 at 6:24
  • I updated the code to highlight that the forecast is speculative.
    – Carl G
    Mar 10 '18 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.