From 0f6d2d313f5132a31968c89d3fbb945605bc0e28 Mon Sep 17 00:00:00 2001 From: Sektor van Skijlen Date: Fri, 16 Feb 2024 08:55:02 +0100 Subject: [PATCH] Apply suggestions from code review (doc review, finished) Co-authored-by: stevomatthews --- docs/API/API-socket-options.md | 8 ++++---- docs/features/latency.md | 12 ++++++------ 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/API/API-socket-options.md b/docs/API/API-socket-options.md index ba2f0959f..84e361f6d 100644 --- a/docs/API/API-socket-options.md +++ b/docs/API/API-socket-options.md @@ -1309,11 +1309,11 @@ is determined by the negotiation in the connection establishment (handshake exch The general idea for the latency mechanism is to keep the time distance between two consecutive received packets the same as the time when these same packets were scheduled for sending by the sender application (or per the time explicitly declared when sending - see -[`srt_sendmsg2`](API-functions.md#srt_sendmsg2) for details). This makes the packets, that have arrived -earlier than their delivery time, kept in the receiver buffer until this time comes. This should -compensate any jitter in the network and an extra delay needed for a packet retransmission. +[`srt_sendmsg2`](API-functions.md#srt_sendmsg2) for details). This keeps any packets that have arrived +earlier than their delivery time in the receiver buffer until their delivery time comes. This should +compensate for any jitter in the network and provides an extra delay needed for a packet retransmission. -For the detailed information on how the latency setting influences the actual packet delivery time and +For detailed information on how the latency setting influences the actual packet delivery time and how this time is defined, refer to the [latency documentation](../features/latency.md). Reading the `SRTO_RCVLATENCY` value on a socket after the connection is established provides the actual (negotiated) diff --git a/docs/features/latency.md b/docs/features/latency.md index 38ee40da3..cfbb779a4 100644 --- a/docs/features/latency.md +++ b/docs/features/latency.md @@ -133,10 +133,9 @@ both machines with identical time bases and speeds, then: * `ATS[x] = program_delay[x] + network_delay[x] + STS[x]` -(The only problem with treating this above formula too seriously -is that there doesn't exist the common clock base for two -network-communicating machines, so these components should be -treated as something that does exist, but isn't exactly measurable). +Note that two machines communicating over a network do not typically have a +common clock base. Therefore, although this formula is correct, it involves +components that can neither be measured nor captured at the receiver side. This formula for ATS doesn't apply to the real latency, which is based strictly on ETS. But you can apply this formula for the very first arriving packet, @@ -189,8 +188,9 @@ We can now get the true network latency in SRT by moving STS to the other side: The DRIFT ========= -The DRIFT, for simplifyint the calculations above, should be treated as 0, -which is the initial state. In time, however, it gets changed basing on the +The DRIFT is a measure of the variance over time of the base time. +To simplify the calculations above, DRIFT is considered to be 0, +which is the initial state. In time, however, it changes based on the value of the Arrival Time Deviation: * `ATD[x] = ATS[x] - ETS[x]`