README.md

@@ -185,6 +185,8 @@ 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 kernel-captured send/receive timestamps over userspace timing where the platform and socket support them, reducing the effect of scheduling and queuing delay on these measurements. This is a best-effort fallback: unsupported or implausible kernel timestamps fall back to userspace timing. RTT always uses userspace timing and is unaffected.
+
 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.
 
 A peer closing a finite CLI or TUI run is accepted as a terminal outcome. In

crates/irtt-client/src/event.rs

@@ -351,7 +351,13 @@ pub struct OneWayDelaySample {
     /// Client-to-server delay.
     ///
     /// This is computed from the client send wall time and the server receive
-    /// wall time when both are available.
+    /// wall time when both are available. The client send endpoint is the
+    /// 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 the server's kernel
+    /// receive timestamp when one is available and plausible, and its
+    /// userspace receive wall time otherwise. RTT is unaffected and remains a
+    /// userspace monotonic measurement.
     pub client_to_server: Option<SignedDuration>,
     /// Server-to-client delay.
     ///

crates/irtt-server/src/socket_io.rs

@@ -32,11 +32,11 @@
 //! instant, is served normally with no timestamp. Nothing about which datagrams
 //! reach [`ServerCore`](crate::ServerCore) depends on it.
 //!
-//! **Nothing consumes it yet.** It is captured here so a follow-up change can
-//! decide how a kernel-observed arrival time enters the protocol core; today
-//! the core still samples its own receive instant and no protocol timing is
-//! affected. It is a software wall-clock reading only — not a NIC hardware
-//! timestamp, not monotonic, and not a transmit timestamp.
+//! [`ServerCore`](crate::ServerCore) prefers it over its own receive sample
+//! when reporting a request's receive instant, falling back to that sample
+//! when no plausible kernel reading is available; see
+//! `preferred_receive_wall_ns`. It is a software wall-clock reading only —
+//! not a NIC hardware timestamp, not monotonic, and not a transmit timestamp.
 
 use std::{io, net::SocketAddr, time::SystemTime};