You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In unstable metrics show that the time to process a block = seen in gossip until set as head ranges 600-900ms. This includes calling the execution client to notify the payload. Running the state transition function for a block takes ~50ms and computing the head another ~50ms. So the long process times are due to the shared resources with other items like processing attestations.
Block process timeline
Step
Avg time
Gossip validation
30 ms
Send notify payload
10 ms
State transition
45 ms
State hashing
25 ms
Verify block sigs
25 ms
notify new payload idle
300 ms
import attestations
10 ms
recompute head
100 ms
persist LC data
25 ms
total
570 ms
CPU profiles show that attestation processing interlaces with block processing, It's unclear now if the 300 ms time for the new payload response is caused by that or not. See two examples of idle and busy loop waiting for notify new payload response
Research / gather more data
What's the actual notify new payload time from the point of view of the execution client
If significantly less than 300ms, add a snooper to watch traffic and understand where is the delay
At what point into the slot is the new payload HTTP request actually dispatched from the OS?
Optimization targets
Algorithmic optimization of recompute head
Stack recompute head with new payload waiting - investigated, found that it doesn't improve timing
Complete block import before new payload response setting it as optimistic head and set as VALID on response latter - likely to cause missed attestations
Block network processor queues when importing recent blocks. To allocate all cycles to block processor without interlaced attestations
Optimize persist LC data, or schedule for latter to complete import faster
CC @tuyennhv
The text was updated successfully, but these errors were encountered:
In unstable metrics show that the time to process a block = seen in gossip until set as head ranges 600-900ms. This includes calling the execution client to notify the payload. Running the state transition function for a block takes ~50ms and computing the head another ~50ms. So the long process times are due to the shared resources with other items like processing attestations.
Block process timeline
CPU profiles show that attestation processing interlaces with block processing, It's unclear now if the 300 ms time for the new payload response is caused by that or not. See two examples of idle and busy loop waiting for notify new payload response
Research / gather more data
Optimization targets
Stack recompute head with new payload waiting- investigated, found that it doesn't improve timingComplete block import before new payload response setting it as optimistic head and set as VALID on response latter- likely to cause missed attestationsCC @tuyennhv
The text was updated successfully, but these errors were encountered: