-
Notifications
You must be signed in to change notification settings - Fork 720
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
CAD-2371 Metrics for blocks lost due to switching #2321
CAD-2371 Metrics for blocks lost due to switching #2321
Conversation
b1f6803
to
b5c5938
Compare
9fc85dc
to
5a15096
Compare
5a15096
to
ae05e7c
Compare
ae05e7c
to
2955cfd
Compare
@@ -969,19 +997,23 @@ data ChainInformation = ChainInformation | |||
, slotInEpoch :: Word64 | |||
-- ^ Relative slot number of the tip of the current chain within the | |||
-- epoch. | |||
, blocksLost :: Int64 | |||
-- ^ Blocks lost due to switch at fork |
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.
If you do end up following my overall proposal, then this comment is wrong and also the name is misleading.
I'd call it myBlocksSelected
, an the comment would say something along the lines of: it's the difference between the numbers of my blocks on the latest selection minus that same number as of the last restart. Thus comparing myBlocksSelected
to the number of blocks I've forged since the last restart shows how many blocks I've forged for naught.
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 that ^^^ plan would require another new metric that simply increments with each TraceForgedBlock
event.
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've updated the code to what I think you mean.
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.
OK, after a little more thinking, I actually think one metric will suffice, and it can be "blocks forged since last restart but not currently selected". (Edit: that's a bit of an overstatement, but it's a reasonable interpretation of this metric as a heuristic.)
TraceForgedBlock
should increment the metric. SwitchedToAFork
and AddedToCurrentChain
should both increment it for each block of ours on the old chain and also decrement it for each block of ours on the new chain.
If we restart and then immediately switch to a fork with more of ours blocks, then this metric might dip negative. But over time, we should generally see this metric gradually increase.
Does that make sense? I'm headed to bed now -- talk to you tomorrow.
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 feel like TraceForgedBlock
shouldn't increment the metric because when we forge a block it is appended to the current chain and is therefore not one of the unselected ones?
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.
The TraceForgedBlock
just means we created the block and are about to add it to the ChainDB. Once it's added, then the ChainDB might select it, which would incur a separate AddedToCurrentChain
event. So decrement for the forge, then increment for the subsequent selection, thus giving us the desired delta of 0.
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. I've used the term "uncoupled" to mean blocks forged not on the current chain, which is the thing being counted.
4c48111
to
483c688
Compare
traceCounter "blocksForgedNum" tr | ||
=<< mapForgingCurrentThreadStats fStats | ||
(\fts -> (fts { ftsBlocksForgedNum = ftsBlocksForgedNum fts + 1 }, | ||
ftsBlocksForgedNum fts + 1)) | ||
meta <- mkLOMeta Critical Public | ||
let tBlocksUncoupled = fsBlocksUncoupled fStats | ||
traceI tr meta "mySelectedBlocks" =<< STM.modifyReadTVarIO tBlocksUncoupled (+ 1) |
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.
Yep, it's a +1
to the TVar
because blocksUncoupledDelta
counts blocks not on the current chain. And even though we just forged it, it's not on the chain until we later (though very soon) get a corresponding AddedToCurrentChain
, which is handled higher up in the diff. 👍
@newhoggy Have you discussed this concern with @disassembler ? I haven't. |
Reproducing this comment from IntersectMBO/ouroboros-network#2930 (comment)
|
0ea8343
to
5839b30
Compare
After a group convo on Slack, I merged IntersectMBO/ouroboros-network#2930 as-is. So I think this PR will also be ready once it bumps the My summary of the slack thread: we only use the verification key of the cold key (and we're already using that for Shelley block selection), and using the cold key as "self" for this metric is appropriate. |
7454b25
to
d192ace
Compare
…id chaing parser implementations causing tests to fail.
d192ace
to
e918a65
Compare
bors merge |
Build succeeded: |
I re-reviewed the new metric itself: still LGTM. I did not review the other eg testing changes. |
No description provided.