missing e2e latency numbers for submit to anchor

[ozym-nhb]

digging through this over the weekend, cool project. embedded VRF anchoring without needing an external chain is a nice pattern, don't see it done clean very often
one thing I couldn't find though was bench/ has SMT-level numbers (insert, prove, verify) but nothing on the actual submit-anchor round trip at the default cycleInterval. that's the number I'd actually want before wiring this into anything latency-sensitive, SMT being fast doesn't tell me if I'm blocking a pipeline for 200ms or 4s
might already exist somewhere I missed, if so apologies in advance 🙃 otherwise seems worth adding p50/p95/p99 for that specific path next to the SMT benchmarks.

[had-nu]

Thanks for flagging this.

SMT benchmarks were the easy ones to write and I never circled back to measure the actual round trip, which is honestly the number that matters most for anyone doing exactly what you described (CI/pipeline gating). Adding p50/p95/p99 for submit-anchor across the documented cycleInterval values (1s/3s/10s) is now tracked, both single-node and multi-node paths since they'll behave pretty differently once gossip/quorum collection is in the loop.

I will close this out once real numbers land in bench/report.json instead of just the SMT stuff that's there now.

Nice catch.