在实时应用的上下文中,延迟和抖动之间有什么区别



根据维基百科,抖动是假设周期信号与真实周期性的不希望的偏差,根据我正在读取的QoS上的一个papper,抖动被称为延迟变化。在实时应用的上下文中是否有抖动的定义?是否存在对抖动敏感但对延迟不敏感的应用?例如,如果流应用程序在向用户显示数据包之前使用某种缓冲区来存储数据包,那么该应用程序是否有可能对延迟不敏感但对抖动敏感?

延迟:是数据(信号)到达目的地所需的时间。现在,更高的延迟通常意味着某种通信链路中断的拥塞。

抖动:是延迟时间的变化。当系统不处于确定性状态时,就会发生这种情况,例如。视频流经常受到抖动的影响,因为传输的数据量非常大,因此无法说传输可能需要多长时间。

如果您的应用程序对抖动敏感,那么它肯定对延迟敏感。

在实时协议(RTP,RFC3550)中,标头包含时间戳字段。 它的值通常来自单调递增的计数器,递增的频率是时钟速率。此时钟速率必须在整个参与者中相同,参与者想要带有时间戳字段的内容。计数器具有不同的基本偏移量,因为开始时间可能不同,或者由于安全原因而包含它,等等......总而言之,我们说时钟没有同步。

为了在示例中显示它,请考虑我们是否引用snd_timestamp并rcv_timestamp RTP 标头字段中的最新数据包发送方时间戳和接收方使用相同的时钟速率生成的接收方时间戳。错误的结论是

delay_in_timestamp_unit = rcv_timestamp - snd_timestamp

如果接收器和发送方时钟速率具有不同的基本偏移(它们有),这不会给您延迟,也不会考虑 32 位无符号整数的环绕。

但是,如果我们想要适当的播放自适应算法,或者想要检测和避免拥塞,那么监控传输数据包的时间在某种程度上是必要的。

另请注意,如果我们有同步时钟delay_in_timestamp_unit可能不会准时表示纯网络延迟,因为发送方或接收方的组件在添加和/或执行的时间戳之后和/或之前保留了这些数据包。因此,如果您计算参与者之间的 2 秒延迟,但您知道您的网络延迟约为 100 毫秒,那么您的数据包在发送方或/和接收方会遭受额外的延迟。但是这种额外的延迟在某种程度上(或者至少你希望它是)恒定的,所以唯一的延迟时间变化是 - 希望 - 网络延迟。因此,您不应该说如果数据包延迟> 500 毫秒,那么我们就会出现拥塞,因为如果您只使用一个数据包发送方和接收方时间戳信息,您不知道实际的网络延迟是多少。

但是,两个连续数据包的延迟之间的差异可能会为您提供一些有关网络中是否有问题的天气信息。

diff_delay = delay_t0 - delay_t1

如果diff_delay等于 0,则延迟相同,如果大于 0,则新到达的数据包需要比前一个数据包更多时间,如果小于 0,则延迟需要的时间更少。

从基于连续两次延迟的相关信息中,你可以说些什么。

如果时钟不同步,如何确定两个延迟之间的差异?

假设您以 rcv_timestamp_t1 和 snd_timestamp_t1 的形式存储了最后的时间戳

diff_delay = (rcv_timestamp_t0 - snd_timestamp_t0) - (rcv_timestamp_t1 - snd_timestamp_t1)

但是,如果不维护发送方和接收方的基本偏移量,这将是一个问题,因此请对其进行重新排序:

diff_delay = (rcv_timestamp_t0 - rcv_timestamp_t1) - (snd_timestamp_t0 - snd_timestamp_t1)

在这里,您可以相互减去 RCV 时间戳,它消除了偏移 RCV 和 SND 包含,然后您可以从snd_diff中提取rcv_diff,它为您提供有关两个连续数据包延迟差异的信息以时钟速率为单位。

现在,根据抖动RFC3550是"RTP数据包到达时间的统计方差的估计"。

为了最终进入正题,您的问题是"在实时应用中,延迟和抖动之间有什么区别?"

请注意,但实时应用程序通常是指在纳秒范围内处理数据的系统,所以我认为您指的是端到端系统。

此外,尽管抖动的定义发生了一些变化,但它都使用到达数据包延迟的差异,从而为您提供有关网络延迟的相对变化的信息,同时延迟本身是交付时间的绝对值。

最新更新