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

Change replay percentage to total block size processed #1289

Closed
3 of 9 tasks
abitmore opened this issue Aug 27, 2018 · 12 comments
Closed
3 of 9 tasks

Change replay percentage to total block size processed #1289

abitmore opened this issue Aug 27, 2018 · 12 comments
Labels
1b User Story The User Story details a requirement. It may reference a parent Epic. It may reference child Task(s) 2b Gathering Requirements Status indicating currently refining User Stories and defining Requirements 3b Feature Classification indicating the addition of novel functionality to the design 4b Normal Priority Priority indicating the moderate impact to system/user -OR- existing workaround is costly to perform 6 UX Impact flag identifying the User Interface (UX) 9b Small Effort estimation indicating TBD good first issue

Comments

@abitmore
Copy link
Member

abitmore commented Aug 27, 2018

User Story
As a node admin, during replaying, I want to know percentage of total size of blocks that have been processed, rather than count of blocks, so that I can estimate more accurately when it will complete.

CORE TEAM TASK LIST

  • Evaluate / Prioritize Feature Request
  • Refine User Stories / Requirements
  • Define Test Cases
    • Assigned: @cogutvalera
    • Estimated: 2 hours
    • Remitted: Week 39
  • Design / Develop Solution
  • Perform QA/Testing
  • Update Documentation
@abitmore abitmore added good first issue 1b User Story The User Story details a requirement. It may reference a parent Epic. It may reference child Task(s) 2b Gathering Requirements Status indicating currently refining User Stories and defining Requirements 3b Feature Classification indicating the addition of novel functionality to the design 4b Normal Priority Priority indicating the moderate impact to system/user -OR- existing workaround is costly to perform 9b Small Effort estimation indicating TBD 6 UX Impact flag identifying the User Interface (UX) labels Aug 27, 2018
@oxarbitrage
Copy link
Member

i don't think block % to total will allow you to estimate time. count or % of operations will do better.

@abitmore
Copy link
Member Author

We don't have the number of total operations before replay. For this issue I mean we can use total_processes_block_size / total_block_size which should have been obtained from block log already when replaying.

@bangzi1001
Copy link
Contributor

Is that possible to add "Estimate Completion Time" beside the Percentage? If can, then node admin no need to estimate completion time manually.

@pmconrad
Copy link
Contributor

For this issue I mean we can use total_processes_block_size / total_block_size which should have been obtained from block log already when replaying.

I believe using the file size of the block log is an inaccurate measure of the total block size to apply. The reason is that the block log is only ever appended to. For example, when switching between forks, the blocks that are re-applied will be appended to the block log again. Similarly, the last 50 blocks of a replay are appended again.

I believe the error is small for a typical node, but can be significant for a node that is restarted often.

@abitmore
Copy link
Member Author

the last 50 blocks of a replay are appended again.

This doesn't sound ideal.

I believe the error is small for a typical node, but can be significant for a node that is restarted often.

I guess it won't be too significant, since we don't reapply too old blocks anyway. IMHO, even it's not accurate, it's still better for estimation than block counts.

@cogutvalera
Copy link
Member

@ryanRfox assign this issue to me please so I will continue my researchers after #946 issue.

Thanks !

@ryanRfox
Copy link
Contributor

Assigned @cogutvalera and awaiting his estimate for @bitshares/core-dev review. Thanks

@cogutvalera
Copy link
Member

@ryanRfox my estimation for this issue is approximately 2 hours

@cogutvalera
Copy link
Member

PR is ready #1335

Thanks !

pmconrad added a commit that referenced this issue Oct 2, 2018
Change replay percentage to total block size processed #1289
@pmconrad
Copy link
Contributor

pmconrad commented Oct 2, 2018

Resolved in #1335

@pmconrad pmconrad closed this as completed Oct 2, 2018
@ryanRfox
Copy link
Contributor

I understand this is a closed Issue, so perhaps I need to open a separate one. I feel the output could be improved. Currently is looks like this:

1944127ms th_a       db_management.cpp:103         reindex              ]    [by size: 2.37002290685776762%   821428243 of 34659084544]   [by num: 17.34458437871986192%   5430000 of 31306602]

Is it trivial to make it look something like:

1944127ms th_a       db_management.cpp:103         reindex              ]    [by size: 2.37%   821.42M of 34.66G]   [by blocks: 17.345%   5.43M of 31.31M]

Round to two decimal places and convert to K, M, G notation.

@abitmore
Copy link
Member Author

abitmore commented Oct 14, 2018

I more like accurate numbers, at least for blocks ;) I agree that it's better if the decimal places of percentages are fewer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1b User Story The User Story details a requirement. It may reference a parent Epic. It may reference child Task(s) 2b Gathering Requirements Status indicating currently refining User Stories and defining Requirements 3b Feature Classification indicating the addition of novel functionality to the design 4b Normal Priority Priority indicating the moderate impact to system/user -OR- existing workaround is costly to perform 6 UX Impact flag identifying the User Interface (UX) 9b Small Effort estimation indicating TBD good first issue
Projects
None yet
Development

No branches or pull requests

6 participants