Expose State Sync ETA in eth.syncing

[mohamedmansour]

I run a public Geth node for watchtheburn and when the node is syncing, I show the status on the loading screen. Once geth goes into State sync, there is no user feedback in the eth_syncing API, whereas the logs do have feedback:

INFO [08-24|10:13:03.126] State sync in progress                   synced=24.84% state=33.15GiB   accounts=36,914,[email protected]   slots=119,992,[email protected] codes=131,[email protected] eta=3h15m24.538s

It would be nice if eth_syncing would be updated to have state sync information so we could pass that information to the users instead of being stuff at 99% synced (currentBlock/highestBlock)

[xanoni]

This would be very interesting, but how can I even ask Geth to write a logfile? So far I was just redirecting stdout and stderr.

Also can't see it here:

$ geth --help|grep log
  --log.json                          Format logs with JSON
  --log.backtrace value               Request a stack trace at a specific logging statement (e.g. "block.go:271")
  --log.debug                         Prepends log messages with call-site location (file and line number)

Is it part of one of the sub-commands? Which?

EDIT: Oh, I just realized that you're probably just talking about stdout .... never mind then.

[holiman]

We can't really provide an estimate on the healing phase of snap-sync, just like we can't provide an ETA on fast-sync.
The longer the first phase (snap download) takes, the more out-of-sync will the data be. Therefore, it will make the heal-phase longer. And that's kind of recursive, the more time it takes, the more work accumulates.

So the 99% done is only for the first phase, not the second phase.

[fjl]

Spec is here: https://github.com/ethereum/execution-apis/blob/main/src/schemas/client.json

[mohamedmansour]

We can't really provide an estimate on the healing phase of snap-sync, just like we can't provide an ETA on fast-sync.
The longer the first phase (snap download) takes, the more out-of-sync will the data be. Therefore, it will make the heal-phase longer. And that's kind of recursive, the more time it takes, the more work accumulates.

So the 99% done is only for the first phase, not the second phase.

Can’t we expose what geth placed in the log output accessible to the api? The log output has alot of data not available in the api which would be nice to have additional fields in eth.syncing

[ligi]

@mohamedmansour I opened an issue about this on magicians: https://ethereum-magicians.org/t/improve-syncing-rpc-call/6994
IMHO we should go this route and not do a solo action from the geth side. It is great that there is now a rpc spec and we should work more to comply with it and not diverge even more from it.

[newearthmartin]

We can't really provide an estimate on the healing phase of snap-sync, just like we can't provide an ETA on fast-sync.
The longer the first phase (snap download) takes, the more out-of-sync will the data be. Therefore, it will make the heal-phase longer. And that's kind of recursive, the more time it takes, the more work accumulates.

Even if we can't show an ETA, is it possible to show an absolute number that is growing? at least to know that something is happening

I'm not sure if this is the same thing or not, I was stuck at always 100 blocks behind and knownStates: 0 for a long time ( #23553 ) and not knowing if any progress was being made or I was just stuck. It was enough to make me try other ethereum clients.

[holiman]

It would be nice if eth_syncing would be updated to have state sync information so we could pass that information to the users instead of being stuff at 99% synced (currentBlock/highestBlock)

We can't really provide an estimate on the healing phase of snap-sync, just like we can't provide an ETA on fast-sync.

Sorry, but it's answered, and we do what we can.