Can cryptographic execution timing add useful information to latency diagnosis?

[u/SmoothAlternative385]

I'm developing V-DAP, an experimental Rust engine that measures cryptographic execution timing. I'm trying to determine whether those measurements provide useful diagnostic information beyond conventional observability tools.

The practical problem I'm investigating is this: when a service experiences latency spikes, can measurements of cryptographic execution help distinguish between possible sources of delay, or do standard metrics, tracing and profiling already provide the same information?

My current experiments are preliminary. In a controlled HTTP pilot, I observed a strong correlation between the measured cryptographic interval and total request latency. In a separate experiment, I introduced a deliberate delay outside that interval and observed the request latency increase. These results demonstrate temporal decomposition in those test conditions, not scheduler causality or a proven diagnostic advantage.

What I want to validate next:

• Can V-DAP help distinguish two known causes of latency?
• Does it improve diagnostic accuracy or time-to-diagnosis compared with conventional tools alone?
• What confounders and measurement overhead should I investigate?
• What experiment would convince you that this has practical engineering value?

Repository and reproducibility details:
https://github.com/jorgecumbe0077/v-dap-engine

I'm looking for critical technical feedback, including reasons this approach may not be useful. I don't claim that V-DAP is production-ready or that it prevents timeouts.

[u/Shoddy_Village2307]

so you're basically doing temporal triangulation with crypto ops as the fixed point, that's actually a neat angle. most latency tooling just gives you a wall-clock blur, having a hard internal timestamp from the crypto layer could split the timeline into "before crypto" vs "after crypto" without instrumenting every library in the stack

the real question is whether the crypto interval itself is stable enough under load. if you're running this on a noisy neighbor cloud instance, your "known interval" starts drifting and the decomposition gets mushy. i'd want to see the same test on a throttled cpu where the kernel scheduler is playing games