Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Daemon: Print estimates for time until fully synced #6278

Open
wants to merge 1 commit into
base: master
from

Conversation

@rbrunner7
Copy link
Contributor

rbrunner7 commented Jan 2, 2020

About every 2 minutes the normal simple sync progress message in the daemon

 Synced 2002098/2002459 (99%, 361 left)

gets an estimate for remaining sync time added:

 Synced 2002118/2002459 (99%, 341 left, 43% of total synced, estimated 2 minutes left)

And after sync finishes a little statistic is output:

Synced 203 blocks in 1 minutes (1.765 blocks per second)
Copy link
Contributor

vtnerd left a comment

  • Have you run tests to determine its accuracy? Presumably you have but I didn't see anything mentioned in the PR comments or commit.
  • Would people in the community find this useful enough for it to be maintained? I think the accuracy is going to be poor, and thus I'm not sure its worth the maintenance effort.
src/common/util.cpp Show resolved Hide resolved
src/common/util.cpp Outdated Show resolved Hide resolved
src/common/util.cpp Outdated Show resolved Hide resolved
src/common/util.cpp Show resolved Hide resolved
src/common/util.cpp Show resolved Hide resolved
}
float blocks_per_second = (1000 * synced_blocks / synced_seconds) / 1000.0f;
MGINFO_YELLOW("Synced " << synced_blocks << " blocks in "
<< tools::get_human_readable_timespan(synced_seconds) << " (" << blocks_per_second << " blocks per second)");

This comment has been minimized.

Copy link
@moneromooo-monero

moneromooo-monero Jan 2, 2020

Contributor

There is already a message about this a bit below.

This comment has been minimized.

Copy link
@rbrunner7

rbrunner7 Jan 3, 2020

Author Contributor

You mean this starting at line 2272, right:

MCLOG_YELLOW(el::Level::Info, "sync-info", "Sync time: " << sync_time/1e9/60 << " min, idle time " << ...

Well, this only appears on demand i.e. with the special log category sync-info active, and gives out quite technically formulated info. My new info strings always appears and addresses "end users". I see one complementing the other.

{
uint64_t total_blocks_to_sync = target_blockchain_height - m_sync_start_height;
uint64_t total_blocks_synced = current_blockchain_height - m_sync_start_height;
progress_message += ", " + std::to_string(total_blocks_synced * 100 / total_blocks_to_sync) + "% of total synced";

This comment has been minimized.

Copy link
@moneromooo-monero

moneromooo-monero Jan 2, 2020

Contributor

Is total_blocks_to_sync guaranteed to not be 0 here ?

This comment has been minimized.

Copy link
@rbrunner7

rbrunner7 Jan 3, 2020

Author Contributor

Yes, together by the 2 if statements that guard that code and the way m_start_sync_height was initialized:

if (current_blockchain_height > previous_height)

if (current_blockchain_height < target_blockchain_height)

But maybe one of the cases where one should err on the safe side and add a check for zero nevertheless, for "peace of mind" and to guard against later changes that may shift conditions?

@rbrunner7

This comment has been minimized.

Copy link
Contributor Author

rbrunner7 commented Jan 2, 2020

Have you run tests to determine its accuracy? Presumably you have but I didn't see anything mentioned in the PR comments or commit.

I never synced as much as in the last few days :)

If you are behind a few days and thus a few hundred blocks it usually gives quite a good estimate how long the sync will take, whether it will be through in a few minutes or whether you have to prepare for, say, half an hour wait or more.

If you sync over long distances there are suprising variances of sync speed. For no obvious reason there can be factors of differences in sync speed, even averaged over hours, which surprised me quite a bit. This of course makes the estimates less reliable, but you still get an idea about the "ballpark" of time that it will take. I know now for example that syncing from scratch in my Linux VM with a debug build with all optimizations off takes roughly 1 month ...

Would people in the community find this useful enough for it to be maintained? I think the accuracy is going to be poor, and thus I'm not sure its worth the maintenance effort.

I am not sure what you mean with "maintenance effort". If you think about the table of block size averages, I refer to my source code comment:

// It's no big problem for estimates that this table will, over time, and if not
// updated, miss larger and larger parts at the top of the blockchain, as long
// as block size averages there do not differ wildly.

To add, if you don't sync over large numbers of blocks but just add a few hundred blocks at the blockchain top that table is even less important, even if block sizes should vary much, say over the course of weeks.

You could ask why include the table at all then? I think the most striking use case is giving useful estimates for the time necessary to sync from scratch. Agreed, that's not a particularly frequent use case, but on the other hand the code size looks reasonable to me.

@SamsungGalaxyPlayer

This comment has been minimized.

Copy link

SamsungGalaxyPlayer commented Jan 2, 2020

I like the feature but can't comment on its accuracy.

@rbrunner7

This comment has been minimized.

Copy link
Contributor Author

rbrunner7 commented Jan 2, 2020

Some info regarding accuracy not yet mentioned: More often than not the estimates seem to come out too high, i.e. the true resulting sync time will be shorter than the estimate.

The main reason for this seems to be that syncing becomes faster over time. I can't see anything special in the fact that during the first 2 or 3 minutes there is a speedup - peers have to be found and buffers filled first after all. What surprises me quite a bit is that the speedup often seems to continue after the 10-minute mark or even later.

I think if you are not accurate it's psychologically better to have estimates that are too high than the other way round.

@vtnerd

This comment has been minimized.

Copy link
Contributor

vtnerd commented Jan 2, 2020

Some info regarding accuracy not yet mentioned: More often than not the estimates seem to come out too high, i.e. the true resulting sync time will be shorter than the estimate.

Which is anecdotal; the issue is that we are dealing with transient and rotating p2p connections instead of consistent server connection(s). Although it is good/interesting to know that in your tests the connections seemed to be mostly stable. Was this on testnet or mainnet?

@vtnerd

This comment has been minimized.

Copy link
Contributor

vtnerd commented Jan 2, 2020

My apologies, I probably wasn't clear in my last comment. One reason I doubted the accuracy is because I don't see how any estimate could be given in a p2p environment due to how the connections can rotate. But I might be too pessimistic.

@rbrunner7

This comment has been minimized.

Copy link
Contributor Author

rbrunner7 commented Jan 3, 2020

Although it is good/interesting to know that in your tests the connections seemed to be mostly stable. Was this on testnet or mainnet?

I tested mainly on Mainnet, although I checked also the other two to make sure it runs ok at least technically. Can't say much about accuracy there however. I noticed that Stagenet also has a surprising variance of block sizes averaged over runs of 10,000 blocks but did not deem it important enough to include an array of those averages.

I don't see how any estimate could be given in a p2p environment due to how the connections can rotate. But I might be too pessimistic.

Well, maybe the speeds of those different peers often are not as dramatically different as to spoil the estimates completely, and other factors like block sizes also vary (and independently so), and reading is only a fraction of total time spent anyway, so it usually seems to average out to a reasonable degree.

You are right of course, syncing is really a very dynamic process, with many factors influencing speed, which degrades accuracy. For me the question boils down to the following: Are the estimates given so bad, so unreliable, even so misleading at times that it's better to give no estimates at all? Of course I am biased, but I would say they are good enough to be useful.

@rbrunner7

This comment has been minimized.

Copy link
Contributor Author

rbrunner7 commented Jan 18, 2020

@vtnerd , @moneromooo-monero , anything left to improve and/or discuss here after my code changes, or do you see this as merge-worthy as-is?

@moneromooo-monero

This comment has been minimized.

Copy link
Contributor

moneromooo-monero commented Jan 18, 2020

If it's reasonably accurate, I'm ok with it though I'm no fan of the ad hoc array.

@rbrunner7

This comment has been minimized.

Copy link
Contributor Author

rbrunner7 commented Jan 22, 2020

If it's reasonably accurate, I'm ok with it

Below I copied all relevant lines from the console output of my own Windows daemon syncing through about 6000 blocks. Ideally the time estimates given would be all exactly 2 minutes apart, which they are not of course, but to me it does not look too bad, and more importantly, useful despite the inaccuracies.

That the first estimate after 2 minutes and the final total sync time are identical (26.8 minutes) is pure coincidence; it means that the first estimate was about 7.5% too high (26.8+2 minutes versus 26.8 minutes).

2020-01-22 18:09:02.838 I [66.168.93.26:34290 INC] Sync data returned a new top block candidate: 2011047 -> 2017010 [Your node is 5963 blocks (8.3 days) behind]
2020-01-22 18:11:06.782 I Synced 2011467/2017010 (99%, 5543 left, 7% of total synced, estimated 26.8 minutes left)
2020-01-22 18:13:09.521 I Synced 2011867/2017011 (99%, 5144 left, 13% of total synced, estimated 25.6 minutes left)
2020-01-22 18:15:11.519 I Synced 2012307/2017011 (99%, 4704 left, 21% of total synced, estimated 22.8 minutes left)
2020-01-22 18:17:13.451 I Synced 2012707/2017013 (99%, 4306 left, 27% of total synced, estimated 21.1 minutes left)
2020-01-22 18:19:16.214 I Synced 2013207/2017013 (99%, 3806 left, 36% of total synced, estimated 18.0 minutes left)
2020-01-22 18:21:20.957 I Synced 2013627/2017014 (99%, 3387 left, 43% of total synced, estimated 16.1 minutes left)
2020-01-22 18:23:23.489 I Synced 2014167/2017016 (99%, 2849 left, 52% of total synced, estimated 13.1 minutes left)
2020-01-22 18:25:25.362 I Synced 2014747/2017020 (99%, 2273 left, 61% of total synced, estimated 10.0 minutes left)
2020-01-22 18:27:26.172 I Synced 2015227/2017020 (99%, 1793 left, 69% of total synced, estimated 7.9 minutes left)
2020-01-22 18:29:27.132 I Synced 2015647/2017021 (99%, 1374 left, 77% of total synced, estimated 6.1 minutes left)
2020-01-22 18:31:29.030 I Synced 2016127/2017023 (99%, 896 left, 85% of total synced, estimated 3.9 minutes left)
2020-01-22 18:33:30.948 I Synced 2016487/2017023 (99%, 536 left, 91% of total synced, estimated 2.4 minutes left)
2020-01-22 18:35:38.204 I Synced 2016967/2017024 (99%, 57 left, 99% of total synced, estimated 15 seconds left)
2020-01-22 18:35:55.291 I SYNCHRONIZED OK
2020-01-22 18:35:55.293 I Synced 5978 blocks in 26.8 minutes (3.713 blocks per second)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.