The only way to get an accurate estimate of expected latency is to measure it in all sorts of different scenarios. You can't measure something that doesn't exist. And relying on other peoples documentation for accurate latency estimates is asking for trouble. The one thing I've learned through profiling a lot of my code is that my intuitions about how long something will take are always wrong.
Part of your job is understanding what is reasonable to expect from your code and understanding how to estimate things. An estimate that is wrong by a factor of 10 can still be very useful.
When you get into the weeds on perperformance, a lot of things get very un-intuitive, but from a high level, it is often not hard to estimate median performance figures for a system within a factor of 10.
As an experienced engineer, you should know that you can never give a good estimate. Very few things are as you would expect them to be.
I looked for an article on how to estimate latency. When I Google "how to estimate the latency of my program" the top results are:
"Network Latency Guide: How to Check, Test, & Reduce"
"How to Measure Latency - Obkio"
"How to measure network latency: the 5 best tools - Kadiska"
They're all about measuring latency. Honestly I can't find any blog or guide that talks about how to give good estimates. Every time I Google a different variation of this question, it only gives me results that talk about how to measure latency. If you can point me to a good source that talks about how you can provide a good estimate of latency, I would be very surprised ;)
Use a table of common latencies, add up what's going to happen on your critical path, and multiply by 2. That will be close to your median latency.
Edit - when people ask for estimates, they usually aren't asking if it's 1 millisecond or 2 milliseconds. They're asking if it's closer to 1 millisecond or 100 milliseconds.
