-
Notifications
You must be signed in to change notification settings - Fork 214
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
use pool production tip to compute performance #1168
Conversation
lib/core/src/Cardano/Pool/Metrics.hs
Outdated
<*> (count <$> readPoolProduction nodeEpoch) | ||
<*> readPoolProduction nodeEpoch | ||
|
||
let tip = maximumBy (compare `on` view #slotId) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not use poolProductionCursor
and case
on the Maybe
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because side-effects are bad 😬 ?
We already have that information available, so there's no need to use another call for this.
cf my last commit.
lib/core/src/Cardano/Pool/Metrics.hs
Outdated
|
||
when (Map.null distr || Map.null prod) $ do | ||
computeProgress nodeTip >>= throwE . ErrMetricsIsUnsynced | ||
computeProgress tip >>= throwE . ErrMetricsIsUnsynced |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think here is a case when we actually don't want the poolProductionTip
😅
computeProgress
compares the poolProductionTip
with this tip, so I think it will only display 100% now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see two options:
- Keep it comparing with the node tip
- Compare against slot 0 of the node's epoch (should be when the results are actually first displayed 🤔 )
Maybe best to keep it the same for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like maximumBy
will crash when the follower is un-synced. We should also at least test the PR manually on the testnet.
(but not sure if there is a testnet we are compatible with at the very moment)
@@ -602,14 +599,13 @@ instance ToText StakePoolLayerMsg where | |||
MsgRegistry msg -> toText msg | |||
MsgListStakePoolsBegin -> "Listing stake pools" | |||
MsgMetadataUnavailable -> "Stake pool metadata is unavailable" | |||
MsgComputedProgress (Just dbTip) nodeTip -> mconcat | |||
MsgComputedProgress prodTip nodeTip -> mconcat | |||
[ "The node tip is:\n" | |||
, pretty nodeTip | |||
, ",\nbut the last pool production stored in the db" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not exactly true anymore. prodTip
is now the greatest slot stored in the DB, where epoch == nodeTip.epoch
.
If the DB were to find itself at a greater slotId than the node this distinction would matter… But that shouldn't be possible.
edit: see other comment which is more concerning
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, any epoch stored that would be greater than the nodeTip is irrelevant. That the symptoms of a rollback that hasn't yet happened on the database. In practice, the most recent production tip from the node's epoch is our current state.
lib/core/src/Cardano/Pool/Metrics.hs
Outdated
<*> (count <$> readPoolProduction nodeEpoch) | ||
<*> readPoolProduction nodeEpoch | ||
|
||
let prodTip = maximumBy (compare `on` view #slotId) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the docs for maximumBy
:
The largest element of a non-empty structure with respect to the given comparison function.
If there are no pool productions in the epoch of the node tip, this will crash. I.e when it should have thrown ErrMetricsIsUnsynced
, it will crash instead.
You cannot move this binding to after the when (Map.null distr || Map.null prod
check, since computeProgress
relies on the prodTip
.
I would suggest using poolProductionTip
. You can put it inside the atomically
and there shouldn't be any downsides:
(distr, prod, dbTip) <- liftIO . atomically $ (,,)
<$> (Map.fromList <$> readStakeDistribution nodeEpoch)
<*> readPoolProduction nodeEpoch
<*> (readPoolProductionCursor 1 >>= toMaybe)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm. Good point!
bors try |
tryBuild failed |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
bors r+ |
1 similar comment
bors r+ |
Already running a review |
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 <[email protected]>
Build failed |
instead of the node tip. The production worker might not have caught up with the network yet and therefore, yield statistics that are slightly off
c12421a
to
31123c5
Compare
bors r+ |
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 <[email protected]>
Build failed |
bors r+ |
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 <[email protected]>
Build succeeded |
Issue Number
#1158
Overview
Comments