When a getMore is issued against a tailable cursor with the awaitData option and no results are currently available, the thread executing the getMore will wait on a condition variable for additional results to become available via insertion into the capped collection. This allows clients to periodically poll a capped collection for new records.

This waiting time is currently incorporated into some of the latency measurements surfaced by the server (e.g. in diagnostic logs, the system.profile collection, and the opLatencies section of serverStatus). This can be counter-intuitive to users, since reporting on average latency may be skewed by this "expected" waiting time on systems that are mostly idle. Therefore, we should exclude this "expected latency" from the following:

• system.profile
• slow query logs
• top
• global operation latency histogram
• per-collection operation latency histogram

Note, however, that this behavior change will not apply to db.currentOp()'s secs_running or microsecs_running, since this output is more often used to gauge the true latency of active operations, rather than generating reports after the fact.