It's well-known that the signal processing of an SDR adds a significantly amount of latency, the SDR software on the computer adds more latency due to data buffering, FFT, decoding, demolutaion, audio buffering, etc, not to mention that most computer systems aren't a real time system and have unpredictable delays as well.
It's usually not a concern, but can be a problem when one wants to extract the precise time-mark of a signal. To elaborate the question, imagine a SDR running on a typical desktop computer, operated by a program powered by GNU/Radio, and consider two scenarios:
Time Synchronization - SDR is tuned to a frequency and listens for an incoming pulse. A pulse is generated at 00:00:00 UTC. Upon receiving it, the SDR immediately set the system's real-time clock to 00:00:00 UTC (for example, in a time synchronization experiment). What would be the error between UTC and system's real-time clock now? Ignore all insignificant sources of errors.
Time-mark extraction - SDR is tuned to a frequency and listens for an incoming pulse. As soon as the pulse is generated, the SDR records the wall-clock time (for example, in a propagation-delay experiment). Assume the system's real-time clock has no error, what would be the error of the time measurable by the program?
Both questions ask for a simple parameter: The typical total delay/latency in the entire signal path of the an SDR setup on a desktop computer. We also assume the latency is not predetermined and calibrated to zero prior to these experiments.
I expect the latency is much worse than what the operating system on a desktop computer is capable of. For example, protocols like NTP uses a PLL-like algorithm and finish the time synchronization in multiple steps, an final error of less than 10 milliseconds over the Internet is not impossible given a datacenter network with symmetric routes (see this statistics), but extracting the time-mark of an one-off event is harder for a desktop computer with SDR, and I expect the delay of an unoptimized implementation has a latency of a dozen of milliseconds. If an accuracy comparable to NTP is required, it's better use a specialized circuit, not a SDR.
That all being said, while I can find some research papers and projects on the architecture of a low-latency SDR, I cannot find a solid measurement or analysis of latency/delay of a typical SDR, such as a RTL-SDR, HackRF, LimeSDR, with gqrx or GNU Radio. I was inspirited by Dan Luu's experiments on the typical latency between entering a keystroke and a screen update on various computer hardware, or the typical latency of latency between a keystroke and a keyboard scancode using a logic analyzer, some experiments for SDR software and hardware would be greatly useful.
I believe this can be an useful reference question. Any data, analysis, and measurements are appropriated. I think I could do some measurements in the future.