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

Apparent performance could be wrong for brief times (because of multiple sources of truth) #1158

Closed
Anviking opened this issue Dec 10, 2019 · 0 comments
Assignees

Comments

@Anviking
Copy link
Member

Anviking commented Dec 10, 2019

Context

The Pool.Metrics chain-follower ensures a source of stake distributions and pool productions that are consistent with each other (always on the same fork).

The performance calculation is:
Apparent Performance = (n / N) * (S / s)
where

  • n is the number of blocks produced by the pool in the last epoch
  • N is the number of slots in the epoch
  • s is the stake owned by the pool in the last epoch
  • S is the total stake delegated to pools in the last epoch

In the implementation however,
https://github.com/input-output-hk/cardano-wallet/blob/master/lib/core/src/Cardano/Pool/Metrics.hs#L239

the tip used to calculate N for the current epoch is retrieved separately from the node.

Because it is a different source of data from the DB, it is not guaranteed to be on the same chain as the DB.

Information -
Version
Platform
Installation

Steps to Reproduce

Not tested:

Consider the scenario:

  1. Slots per epoch = 20, poolA has 100% stake
  2. stake-pool-worker syncs to slot 2.3
  3. node rolls forward to 2.19
  4. user calls listStakePools without the worker yet noticing the roll-foward

Expected behavior

Performance is calculated from consistent sources of data.

Likely we'd expect:
For epoch 2:
s / S = 1
N = 3
n = 3

AP = 100%

Actual behavior

Hypothetical, not tested:

For epoch 2:
s / S = 1
N = 19
n = 3

AP = 16%

(As the chain follower catches up, the inconsistency would disappear)

Resolution


We could calculate the N using the tip from the Pool DB instead of the tip from the node's REST api. ==> #1168

QA

@Anviking Anviking changed the title Hypothetical error in pool performance calculation from race-conditions on rollbacks Total slots in epoch (S) could be inconsistent with produced blocks (s) Dec 10, 2019
@Anviking Anviking changed the title Total slots in epoch (S) could be inconsistent with produced blocks (s) Total slots in epoch (S) could sometimes be inconsistent with produced blocks (s) Dec 10, 2019
@Anviking Anviking changed the title Total slots in epoch (S) could sometimes be inconsistent with produced blocks (s) Apparent performance could be wrong for brief times (because of multiple sources of truth) Dec 11, 2019
@KtorZ KtorZ self-assigned this Dec 12, 2019
iohk-bors bot added a commit that referenced this issue Dec 12, 2019
1168: use pool production tip to compute performance r=Anviking a=KtorZ

# Issue Number

<!-- Put here a reference to the issue this PR relates to and which requirements it tackles -->

#1158 

# Overview

<!-- Detail in a few bullet points the work accomplished in this PR -->

- [ ] I have used pool production tip to compute performanceinstead of the node tip. The production worker might not have caught up with the network yet and therefore, yield statistics that are slightly off



# Comments

<!-- Additional comments or screenshots to attach if any -->

<!-- 
Don't forget to:

 ✓ Self-review your changes to make sure nothing unexpected slipped through
 ✓ Assign yourself to the PR
 ✓ Assign one or several reviewer(s)
 ✓ Once created, link this PR to its corresponding ticket
 ✓ Assign the PR to a corresponding milestone
 ✓ Acknowledge any changes required to the Wiki
-->


Co-authored-by: KtorZ <matthias.benkort@gmail.com>
iohk-bors bot added a commit that referenced this issue Dec 12, 2019
1168: use pool production tip to compute performance r=KtorZ a=KtorZ

# Issue Number

<!-- Put here a reference to the issue this PR relates to and which requirements it tackles -->

#1158 

# Overview

<!-- Detail in a few bullet points the work accomplished in this PR -->

- [ ] I have used pool production tip to compute performanceinstead of the node tip. The production worker might not have caught up with the network yet and therefore, yield statistics that are slightly off



# Comments

<!-- Additional comments or screenshots to attach if any -->

<!-- 
Don't forget to:

 ✓ Self-review your changes to make sure nothing unexpected slipped through
 ✓ Assign yourself to the PR
 ✓ Assign one or several reviewer(s)
 ✓ Once created, link this PR to its corresponding ticket
 ✓ Assign the PR to a corresponding milestone
 ✓ Acknowledge any changes required to the Wiki
-->


Co-authored-by: KtorZ <matthias.benkort@gmail.com>
iohk-bors bot added a commit that referenced this issue Dec 12, 2019
1168: use pool production tip to compute performance r=KtorZ a=KtorZ

# Issue Number

<!-- Put here a reference to the issue this PR relates to and which requirements it tackles -->

#1158 

# Overview

<!-- Detail in a few bullet points the work accomplished in this PR -->

- [ ] I have used pool production tip to compute performanceinstead of the node tip. The production worker might not have caught up with the network yet and therefore, yield statistics that are slightly off



# Comments

<!-- Additional comments or screenshots to attach if any -->

<!-- 
Don't forget to:

 ✓ Self-review your changes to make sure nothing unexpected slipped through
 ✓ Assign yourself to the PR
 ✓ Assign one or several reviewer(s)
 ✓ Once created, link this PR to its corresponding ticket
 ✓ Assign the PR to a corresponding milestone
 ✓ Acknowledge any changes required to the Wiki
-->


Co-authored-by: KtorZ <matthias.benkort@gmail.com>
@KtorZ KtorZ closed this as completed Dec 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants