diff --git a/README.md b/README.md
index 9857440..f682fd7 100644
--- a/README.md
+++ b/README.md
@@ -185,7 +185,7 @@ Useful measurement fields include:
 
 Adjusted RTT can be negative when server processing exceeds the measured raw RTT. One-way delay estimates can be negative because of clock skew between the client and server.
 
-On Linux, `sd_us` and `rd_us` (and the underlying one-way delay samples) prefer a kernel-captured timestamp over userspace timing for this client's own send/receive endpoint where the platform and socket support it, reducing the effect of scheduling and queuing delay on these measurements. The peer's reported endpoint gets the same preference when it is this crate's own `irtt-server` on Linux; against another IRTT-compatible server, whatever wall-clock value it reports is used as-is. This is a best-effort fallback: unsupported or implausible kernel timestamps fall back to userspace timing. `raw_rtt_us` always uses userspace timing and is unaffected; `adjusted_rtt_us`/`effective_rtt_us` can still shift slightly, since server processing time is derived from the same server receive endpoint.
+On Linux, `sd_us` and `rd_us` (and the underlying one-way delay samples) prefer a kernel-captured timestamp over userspace timing for this client's own send/receive endpoint where the platform and socket support it, reducing the effect of scheduling and queuing delay on these measurements. The peer's reported endpoint gets the same preference when it is the `irtt-server` applet running on Linux; against another IRTT-compatible server, whatever wall-clock value it reports is used as-is. This is a best-effort fallback: unsupported or implausible kernel timestamps fall back to userspace timing. `raw_rtt_us` always uses userspace timing and is unaffected; `adjusted_rtt_us`/`effective_rtt_us` can still shift slightly, since server processing time is derived from the same server receive endpoint.
 
 Default table output prints a final summary after completed finite runs and interrupted continuous runs when the run policy permits it. CSV, TSV, and JSON Lines output do not print this summary.
 
diff --git a/crates/irtt-client/src/event.rs b/crates/irtt-client/src/event.rs
index 9b1ada8..911fba9 100644
--- a/crates/irtt-client/src/event.rs
+++ b/crates/irtt-client/src/event.rs
@@ -355,11 +355,14 @@ pub struct OneWayDelaySample {
     /// correlated Linux kernel TX timestamp for this send when one is
     /// available and plausible for this send, and the userspace post-send wall
     /// time otherwise. The server receive endpoint is whatever wall time the
-    /// peer reported; against this crate's own `irtt-server` on Linux, that is
-    /// its kernel receive timestamp when one is available and plausible, and
-    /// its userspace receive wall time otherwise. Against another
-    /// IRTT-compatible peer, the client has no way to know which clock source
-    /// produced it. `RttSample::raw` is unaffected and remains a userspace
+    /// peer reported; against this crate's own Tokio server runtime on Linux
+    /// (the `irtt-server` applet), that is its kernel receive timestamp when
+    /// one is available and plausible, and its userspace receive wall time
+    /// otherwise. Against another IRTT-compatible peer, or an application
+    /// driving `irtt_server::ServerCore::handle_datagram` directly, the
+    /// client has no way to know which clock source produced it — the public
+    /// `ServerCore` API never supplies a kernel timestamp of its own accord.
+    /// `RttSample::raw` is unaffected and remains a userspace
     /// monotonic measurement, but `adjusted` and `effective` can still shift:
     /// when the session negotiated wall-clock timing rather than monotonic,
     /// server processing time is derived from this same server receive