Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

Warp syncing not working at all on foundation network #7352

Closed
GothicIII opened this issue Dec 21, 2017 · 2 comments
Closed

Warp syncing not working at all on foundation network #7352

GothicIII opened this issue Dec 21, 2017 · 2 comments
Labels
M4-core ⛓ Core client code / Rust. Z7-duplicate 🖨 Issue is a duplicate. Closer should comment with a link to the duplicate.
Milestone

Comments

@GothicIII
Copy link

GothicIII commented Dec 21, 2017

Before filing a new issue, please provide the following information.

I'm running:

  • Which Parity version?: 1.8.4 Beta and 1.7.3 Stable
  • Which operating system?: Windows
  • How installed?: via installer / binaries
  • Are you fully synchronized?: no
  • Did you try to restart the node?: yes

Issue: Warp syncing broken on foundation network.

How to produce:
Install parity via installer/run binary without parameters. After a short while warp sync either won't even start or breaks at random points and start a normal sync.

Detailed description:
First time I started parity from command line. It started to sync with warp mode and the best I got was 40% snapshots downloaded. Then I get no error, even with high verbose level, the logfile output resets completly and parity just starts syncing blocks manually from block 0.

If I kill the deamon and delete all parity related config files ([...]\Appdata\Local\Parity and [...]\Appdata\Roaming\Parity) parity starts syncing at block 0 of 5m without even considering using warp. I don't know how to force warp sync again. It only kicked in twice out of 30 tries.

"Workaround":
If I switch to a different network like kovan I have no problems. Syncing of 5m blocks was blazing fast. But this is not helpful.

System and environment:
Windows is installed on a SSD with a core i5 [email protected] (SingleThread boost) and 16gb RAM sitting at a 100mbit down and 40mbit up internet speed, so thats not an issue.

I hoped to get a faster alternative than geth, but I'm not willing to let my computer run for 48hours until all blocks are in sync. While writing this geth synced 4m blocks and should be finished soon.

EDIT: Today I tried it again without success. It got further to ~90% warp sync and then it just stops downloading the snapshots and starts again syncing from scratch at block #0.

@kirushik
Copy link
Collaborator

Thanks for your report, @GothicIII! It's really detailed and seems to cover all the necessary info.

Yes, we're aware that warp sync has multiple problems and is currently not helping much. We hope to solve that for most usecases in the upcoming releases (but I can't give you any ETA on that, sorry).
There's already an issue #6372 for warp sync failing at arbitrary times, so I'm closing this one in favor of the older one.

If (after reading all the comments there) you think that this issue is somehow completely different — please post additional info here, and we'll reopen this one.

@5chdn
Copy link
Contributor

5chdn commented Jan 3, 2018

Duplicate of #7436

@5chdn 5chdn marked this as a duplicate of #7436 Jan 3, 2018
@5chdn 5chdn added M4-core ⛓ Core client code / Rust. Z7-duplicate 🖨 Issue is a duplicate. Closer should comment with a link to the duplicate. labels Jan 3, 2018
@5chdn 5chdn added this to the 1.9 milestone Jan 3, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
M4-core ⛓ Core client code / Rust. Z7-duplicate 🖨 Issue is a duplicate. Closer should comment with a link to the duplicate.
Projects
None yet
Development

No branches or pull requests

3 participants