1

I am trying to set up an Ethereum node. I have tried with both geth and Parity and they both seem to be taking several days. I am on a high-end system with fiber internet, so I am wondering if this is to be expected.

My system specs are as follows:

  • CPU: Intel i7 6700K
  • GPU: GeForce GTX 1060 6GB
  • RAM: 16GB DDR4 SDRAM
  • HD: 128GB M.2 SSD
  • Internet: 950 Mb/s down, 120 Mb/s up, fiber

I am running Ubuntu 16.06 with Parity version v1.10.2-beta-f4ae813-20180423/x86_64-linux-gnu/rustc1.25.0. Clock is synced.

I launched Parity firstly with no args, waited a couple of days, then deleted ~/.local/share/io.parity.ethereum (around 70GB iirc) and tried again with:

parity --mode active --tracing off --pruning fast --db-compaction ssd --cache-size 1024

This time it's been running for about 4 days and by a quick back-of-envelope calculation it will take another few days still.

With geth, I would quickly sync just to the last 100 blocks (~70GB) after only a few hours - but it wouldn't catch up the last 100 blocks given another 24 hours. Is this normal?

Improve this question
1
  • Does not seem unreasonable. I haven't had much success with warp sync lately with Parity, but for the latest blocks, I'd expect your computer to sync at about 2 blocks/second which means that it'll take about 3 hours to verify one day's worth of blocks. Don't know how geth works nowadays and what optimizations exist. Might have the chain (mostly) downloaded but need to verify the blocks before resuming sync.
    – lungj
    Apr 30, 2018 at 2:36

1 Answer 1

Reset to default
3

More than a day is definitely not usual with your configuration. I would advise you to use the flag --warp-barrier NUM to specify a minimum block you want to warp sync to

Note that some flags you use for Parity are the default ones and therefore not needed --mode active --tracing off --pruning fast.

Improve this answer
4
  • Thanks for the advice Tbaut, I deleted ~/.local/share/io.parity.ethereum and have restarted with parity --db-compaction ssd --cache-size 1024 --warp-barrier 5520000
    – Dagrada
    Apr 30, 2018 at 18:31
  • Hi Tbaut, well it's been running for about 24 hours now with --db-compaction ssd --cache-size 1024 --warp-barrier 5520000 and I'm still only up to block 2,965,730.. any ideas?
    – Dagrada
    May 1, 2018 at 21:13
  • 1
    This is obviously a bug. Please report it in the GitHub repo. --warp-barrier should not go back to normal sync. I advise you to not let it continue to normal sync as soon as you see that the warp sync is failing but rather try again.
    – Tbaut
    May 2, 2018 at 7:38
  • I've opened an issue. BTW, are there any port-forward requirements on the network router side?
    – Dagrada
    May 2, 2018 at 21:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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