每个人,以及大多数事物,都需要时钟,计算机也不例外。然而,时钟如果放任自流,往往会发生漂移,因此有必要定期将其同步到更高精度的其他参考时钟来纠正它们。一种经济且方便的方法是通过计算机网络来实现。
自互联网早期以来,一个统称为 NTP(网络时间协议)的系统已被用于允许客户端计算机(如 PC)连接到安装了高质量时钟的其他计算机(NTP 服务器)。通过在网络上以 NTP 格式的数据包传输的数据包时间戳的交换,PC 可以使用服务器时钟来校正自己的时钟。作为 NTP 时钟软件,特别是ntpd守护进程,它与包括 Mac OS、Windows 和 Linux 在内的所有主要计算机操作系统捆绑在一起,因此它是一项非常成功的技术,用户群与全球计算机人口相当。
尽管 NTP 系统多年来在通用用途中运行良好,但其准确性和鲁棒性都低于底层硬件所能达到的水平,并且不足以应对未来的挑战。电信行业就是如此,该行业正忙于用廉价的异步以太网线路取代移动基站同步回程系统(过去曾提供亚微秒级的基于硬件的同步作为副产品)。另一个是金融行业的高速交易,交易所和交易中心之间延迟的减少与利用这些延迟获利的能力之间存在直接关系。在这里,准确的交易时间戳至关重要。更普遍地说,时序至关重要,因为由于光速是有限的,网络节点之间的延迟受到硬性约束,这不会被未来更快的处理器或带宽增加所克服。无法规避的事情必须得到严格的管理,而没有精确的同步,这是不可能的。
当讨论转向时钟时,困惑往往随之而来。为了避免迷失在时钟装置中,让我们定义一些术语。t 我们指的是牛顿宇宙中以秒为单位测量的真时间,原点在某个任意时间点。我们说时钟 C 在真时间 t 读取 C(t)。图 1 显示了一些示例时钟随着(真)时间的推移的读数。黑色时钟 Cp(t) 是完美的
Cp(t) = t
而蓝色时钟
Cs(t) = C0 + (1 + x)t
在 t = 0 时偏差为 C0。事实上,随着它以恒定但过快的速率运行,情况会变得更糟,速率误差为skew x。红色时钟 Cd(t) = t + E(t) 更为真实;其误差 E(t) 随时间变化,时钟被称为漂移。漂移远非漫无目的,实际上与温度变化密切相关。图 6(稍后会更详细地讨论)给出了 Pentium PC 中未同步时钟在两天期间的漂移 E(t)(黑色曲线)的特写视图。
每个时钟的核心都有硬件。在 PC 中,这是一个位于主板上的振荡器。振荡器以接近恒定的速率“滴答”——事实上,平均变化通常仅为 0.1 ppm(百万分之一)。诸如 HPET(高性能事件定时器)之类的硬件计数器计算这些滴答,使操作系统能够访问缓慢漂移的时序源。从这样的计数器,可以定义一个时钟,粗略地说,它将计数器滴答单位转换为秒,并添加一个常数来设置时间原点
C(t) = C0(t) + p(t) · HPET(t)
其中 p(t) 是 HPET 计数器的(缓慢随时间变化的)周期,单位为秒。时钟同步算法的作用是设置和定期更新 C0 和 p(t) 的值,以尽可能减少漂移或误差 E(t) = C(t) – t。
进入互联网。同步算法无法纠正 C(t) 的漂移,这是从计数器继承来的,除非求助于一些独立的专家:参考时序源或主时钟。附加额外的硬件是可能的,但很昂贵,而且除非它可靠,否则毫无意义。一个高质量的 GPS,具有始终良好的卫星可见性,可能要花费数千美元,这还不包括说服大楼主管将其安装在屋顶上并将电缆连接到你的办公室。哦,而且这将需要你至少六个月的时间才能实现。原子钟甚至更昂贵,并且仍然需要 GPS 来避免每周甚至更长时间范围内的漂移。相比之下,通过网络进行同步可以在没有提前期、没有花费、并且不需要太多努力的情况下完成。
原则上,时钟同步是微不足道的。你问专家现在几点了,他看看他的时钟,告诉你,然后你设置你的手表——就这么简单。问题是这些步骤中的每一步都需要时间,而在互联网上,这些延迟可能很大、不可预测且高度可变。同步算法的关键挑战——几乎是唯一的挑战——是能够应对这些变化,稳健而精确地消除由延迟可变性引起的误差。
定时数据包遭受的延迟是在主机计算机和网络(以及服务器中产生的,但我们将慷慨地假设一个完美的参考时钟)。在主机中,延迟来自 NIC(网络接口卡)行为、操作系统进程调度和数据包时间戳代码的架构,并且大约为几十微秒。在网络中,它们是由网络元素(如 IP 路由器和第 2 层交换机)中的排队引起的,并且从千兆以太网 LAN 上的不到一毫秒到网络拥塞严重且服务器距离超过几跳时可能数百毫秒不等。
在我们这里关注的双向同步范例中(另一种选择是仅从服务器广播),定时数据包在两个方向上交换(见图 2)。前向(主机到服务器:d↑ )和后向(服务器到主机:d↓)方向上的 OWD(单向延迟)都有各自独立的主机和网络组件。将每个方向上的 OWD 相加得到主机服务器主机 RTT(往返时间)。
图 3 提供了一个示例,说明当主机和服务器都在 LAN 上时,定时数据包的 RTT 以及主机组件本身。每个都远高于其最小值变化,这转化为添加了大量的“噪声”,同步算法必须以某种方式看穿它。
时钟的三个主要用途是:
1. 建立事件之间的严格顺序,
2. 测量事件之间的时间间隔,
3. 定义一个普遍可比且可触发的事件标签,“时间”。
理想情况下,完美的时钟非常适合这些目的中的每一个,但在现实世界中,硬件和软件的限制意味着通过专用时钟才能获得最佳性能。选择适合工作的时钟至关重要,但尚未被广泛理解。
当人们想到时钟时,通常会想到第三种用途:告诉绝对时间的时钟。然而,面对延迟可变性,同步这样的时钟本质上是困难的。因此,绝对时钟 Ca(t) 的精度可能很低,随时间变化很大,并且受网络条件的影响。绝对时钟还必须支持跳跃复位的能力,包括向后跳跃。尽管这种情况可能很少见,但这使得它们不太适合用途 1。
建立时间顺序的更好选择是行为良好的原始计数器,例如 HPET(t),它单调递增。等效地,可以缩放这样的计数器以形成一个以秒为单位校准的简单因果时钟
Cc(t) = p0 · HPET(t)
其中 p0 是一个永不更新的常数。这样的时钟会报出错误的时间并且会漂移,但在用途 1 中表现出色,并且完全独立于网络条件,实际上根本不需要服务器时间戳!
绝对时钟 Ca(t) 的误差也使其不适合用途 2。通过一个例子可以最好地看出这一点:如果计数器的速率误差为 0.1 ppm(这在合理的温度环境下的 PC 中非常典型),那么在一秒的时间间隔内,漂移量仅为 10-7 · 1 = 0.1 μs 的误差。另一方面,Ca(t) 中的误差,以及因此持续时间测量中的误差,可能从几微秒到几毫秒,甚至在极端情况下大于一秒,具体取决于网络拥塞和算法鲁棒性等因素。
测量时间差的更好选择是使用差分时钟——即未针对漂移进行校正的时钟。一个简单的例子是
Cd(t) = C0 + pav · HPET(t)
其中 C0 是一个常数(永不更新),pav 是长期平均速率的估计值,我们可以将其视为一个常数(为了清晰起见,我们在这里稍微简化一下;有关更多详细信息,请参见参考文献 4)。这样的时钟仅大致报出正确的时间并且会漂移,但在用途 2 中表现出色,前提是 pav 可以稳健且准确地估计(这是可以的)。它确实依赖于服务器时间戳,但与 Ca(t) 相比,方式的敏感性要低得多,鲁棒性也更高,因为它直接利用了本地硬件的高稳定性(速率常数高达 0.1 ppm)。
图 4 比较了通过精确的绝对时钟和精确的差分时钟测量的来自 GPS 接收器(标称精确间隔一秒)的脉冲进入 PC 串行端口的时间之间的误差。它们在数量级上有所不同,即使服务器就在附近(最小 RTT 约为 1 毫秒)。事实上,操作系统/串行端口为这些测量增加了大约 2 微秒的噪声,因此实际上淹没了 Cd(t) 中的误差:差分时钟在一秒尺度上非常出色,以至于要测量其误差是一个严峻的挑战!
最后一个关键点:差分时钟通过策略性地忽略漂移来工作,但在更长的持续时间内,由此产生的误差会增长,因此差分时钟会失去精度。一个好的经验法则是交叉点发生在 τ = 1,000 秒。在此尺度之上,持续时间应改为使用绝对时钟计算。可以通过在艾伦偏差图中找到最小值来计算此交叉值,该图测量振荡器稳定性(作为时间尺度函数的变异性)。
考虑以下同步绝对时钟 Ca(t) 的方法。定时数据包在主机中使用 Ca 盖上时间戳。这些时间戳与服务器获取的时间戳进行比较,并评估时钟误差。然后稍微调整 Ca 的速率,以使该误差随时间趋于零。这是一个反馈方法的示例,因为前一轮的时钟校正直接反馈作为算法的输入,因为它正是时钟 Ca 本身用于生成主机时间戳。
另一种选择是使用底层计数器在主机中生成原始数据包时间戳(即,计数器读数)。然后基于这些和服务器时间戳来估计时钟误差,并在读取时钟时“减去”。这是一种前馈方法,因为误差是基于后处理输出来校正的,并且这些误差本身不会反馈到下一轮的输入中。换句话说,原始时间戳独立于时钟状态。可以说,硬件现实被直接观察到,而不是通过算法眼镜看到。
NTP 同步算法是一种反馈设计。它结合使用了 PLL(锁相环)和 FLL(频率锁定环)方法来锁定服务器时钟的节奏。2 前馈设计的一个例子是 RADclock,这是一种双向、最小 RTT 过滤的、基于前馈的绝对和差分同步算法,它位于我们在墨尔本大学的 RADclock 项目的核心。4
在互联网的背景下,反馈方法有两个明显的缺点,互联网的延迟很大且高度可变,并且反馈率很低(定时数据包之间的时间间隔通常在 64 到 1,024 秒之间,因为为了可扩展性,我们不能用定时数据包使网络饱和)。第一个缺点是无法保证 PLL 和 FLL 等经典控制方法的稳定性。换句话说,如果条件不够好,它们可能会失去锁定,从而导致转移到可能持续很长时间甚至永久的高误差模式。图 5 给出了这方面的一个例子,比较了ntpd和绝对 RADclock(共享完全相同的定时数据包到非拥塞 LAN 上的服务器)在两周内的误差。的反馈稳定性ntpd在许多情况下会丢失,导致更大的误差。
第二个缺点是差分时钟甚至无法在反馈框架中定义,因此我们失去了它们的优势,这些优势不仅包括更高的精度,还包括更高的鲁棒性。值得注意的是,在网络中,时间差可以说比绝对时间更常用。延迟抖动、RTT、到达间隔时间和代码执行时间都是时间差的示例,最好使用差分时钟来测量。
前馈方法的一个缺点是它本身不能保证时钟永远不会向后移动;但是,因果关系强制执行的时钟读取函数可以解决此问题,而不会损害核心设计。
NTP 系统是现任者,受到所有主要操作系统的支持。让我们看一下一些内核支持问题,重点关注 FreeBSD 和 Linux。
内核维护的系统时钟(提供众所周知的gettimeofday()函数调用)以及内核对约束它的算法的支持,从历史上看一直与并且仍然与ntpd守护进程的需求密切相关。特别是,计数器抽象(timecounter在 FreeBSD 中和clocksource在 Linux 中),它们使进程能够访问系统中可用的不同硬件计数器,但未能提供对原始计数器值的直接访问。相反,这些只能通过系统时钟获取的时间戳来访问,系统时钟在底层使用计数器。换句话说,内核 API 仅支持反馈范例;前馈算法简直被禁止参与。
现有系统时钟同步架构的ntpd-导向性质的另一个重要结果是,反馈循环鼓励在用户空间和内核之间分离算法“智能”。ntpd守护进程在前者的用户空间中运行,但系统时钟有自己的自适应程序,实际上是一个辅助同步系统。通过反馈循环链接的两个反馈系统很难保持稳定、维护甚至理解。相比之下,通过允许从用户空间访问原始计数器值,前馈算法可以完全避免辅助系统,并将算法智能和设计集中在一个定义明确的位置。然后,劳动分工是明确的:同步算法负责同步;内核处理时间戳。
请注意,正如因果时钟 Cc(t) 中完全一样,计数器可以按常数缩放,以便以更方便和通用的单位读取,这不会影响前馈算法基于它进行同步的能力。Linux 的CLOCK_MONOTONIC_RAW例如,提供了这样一个缩放的计数器,它以(近似且漂移的)纳秒为单位滴答。
目前,RADclock 通过提供补丁来绕过缺乏前馈支持的问题,这些补丁以最小的方式扩展了 FreeBSD 和 Linux 中的上述机制,以允许内核和用户空间都访问原始计数器。RADclock API 包括基于直接计数器时间戳的差分和绝对时钟读取功能,结合最新的时钟参数和漂移估计。
在继续之前,我们应该指出一个令人恼火的事实:通过网络进行同步实际上是不可能的。为了理解这一点,让我们通过假设零网络拥塞和系统负载来简化问题,以便所有延迟都采用其恒定的最小值。
设 A = d↑–d↓ 表示真实的路径不对称性,其中 d↑ 和 d↓ 分别是到服务器和来自服务器的真实最小单向延迟;设 r = d↑ + d↓ 为最小 RTT(见图 2)。问题是存在一个基本歧义,因为路径不对称性无法独立于时钟误差进行测量。其本质如下:如果我在 t = 1.1 收到来自服务器的时间戳 T,读数为 T = 1,我无法判断我是否与距离 d↓ = 0.1 秒的服务器完美同步,或者,或者,我是否落后于真时间 1 秒(数据包实际上在 t = 2.1 到达),并且服务器距离 1.1 秒。
即使原则上,任何算法都无法规避不对称性歧义。然而,有一些好消息。首先,这是一个仅困扰绝对时钟的问题;差分时钟不受影响。其次,双向交换允许来自因果关系(数据包不能在发送之前到达)的约束起作用。因此,即使无法精确得知不对称性和相关的时钟误差,它们也被限制在一个范围内。
问题仍然存在,绝对时钟是如何实现不可能的?它们返回的是什么?实际上,在没有任何关于 A 的外部辅助信息的情况下,我们必须猜测一个值,通常选择 Â= 0,这对应于对称路径。这允许时钟同步,但仅限于某个未知误差 E,该误差位于 [–r, r] 范围内。在某些情况下,此范围可能为数十毫秒宽,并且可能会使其他误差相形见绌。
这里还有另一个关键点要记住。即,真实不对称性(例如,由于路由更改)或算法使用的不对称性估计的任何变化都会使时钟跳跃。例如,基于对主机和服务器之间路由的一些了解,距离 r = 15 毫秒,一位大胆的管理员可能会用 Â= 3 毫秒的最佳猜测替换默认的 Â= 0,从而导致 3/2 = 1.5 毫秒的跳跃。另一个例子是服务器选择的更改,这不可避免地带来了不对称性的变化。关键是跳跃,即使它们导致同步的改进,本身也是一种罪恶。这种不对称性抖动不仅会使此主机中的软件感到困惑,还会使其他主机中的软件感到困惑,因为所有测量到和来自主机的 OWD 也将经历跳跃。
总而言之,网络同步包括两个非常不同的方面。同步算法的作用是看穿并消除延迟可变性。即使不对称性误差以及最终的时钟误差很大,如果它成功地做到了这一点,它也被认为是准确的,因为它对此无能为力。不对称性抖动问题不是关于可变性,而是关于未知的常数。这要简单得多;然而,它本质上是困难的,因为它无法规避,即使原则上也是如此。所以这是挑战:虽然不能消除,但不对称性的实际影响在很大程度上取决于如何管理它。这两个非常不同的问题在一个关键方面相交:两者都受益于附近的服务器。
以下是我们可靠同步的关键要素列表。
时钟的基础是本地硬件。任何有自尊心的算法都应首先使用物理上有意义的模型来结合其行为的本质。特别重要的是对其稳定性的以下简单表征:大规模速率误差界限 (0.1 ppm) 和振荡器变异性最小的时间尺度 (τ = 1,000 秒)。这些特性在 PC 架构中非常稳定,但该算法仍应对其精确值不敏感。
另一个基本的物理组件是延迟的性质。排队延迟以及 OWD 和 RTT 的良好通用模型是常数加上正随机噪声。在 RTT 的情况下,图 3 中清楚地看到了这个常数(最小值)。
前馈方法提供更高的鲁棒性,这在像互联网这样嘈杂且不可预测的环境中至关重要。它还允许定义差分时钟,这反过来又是绝对时钟稳健过滤的关键,并且对于包括网络测量(OWD 除外)在内的大多数时序应用也直接有价值。
同步差分时钟等同于测量长期平均周期 pav。这种“速率同步”比绝对同步更基本、更重要且更容易。对此的稳健解决方案是构建更棘手的绝对同步的坚实基础。
请注意,速率同步我们指的是平均长期速率/周期的低噪声估计,不要与短期速率混淆,短期速率基本上简化为(漂移的导数),因此简化为绝对同步。
如果定时数据包足够幸运地体验到最小延迟,那么其时间戳就不会被破坏,并且可以用于将绝对时钟直接设置为正确的值(不对称性除外)。问题是,我们如何确定哪些数据包是幸运的?
不幸的是,这是一个先有鸡还是先有蛋的问题,因为要测量 OWD,我们必须使用绝对时钟 Ca(t),这正是我们首先要同步的时钟。幸运的是,RTT 的情况有所不同,RTT 可以通过差分时钟 Cd(t) 测量。关键结果是,无需首先绝对同步时钟即可获得可靠的数据包质量度量。只需测量给定定时数据包的 RTT 超出最小 RTT 的程度:差距越小,数据包的“质量”越高。
眼尖的读者会注意到,先有鸡还是先有蛋的问题仍然存在。差分时钟也需要过滤才能同步,那么我们如何在同步之前使用它呢?答案是,即使对 pav 的估计非常差也足以执行有意义的过滤。例如,假设 pav 的已知精度为 100 ppm(这确实非常糟糕),并且 RTT=10 毫秒。那么 RTT 测量中的误差(包括由漂移引起的误差)约为 1 μs 的量级,远低于操作系统引起的噪声(约为 10 μs)。
让我们假设我们的过滤是成功的,因此我们可以可靠地测量定时数据包的质量水平。
速率同步(即,pav 的测量)的关键在于它是一个长期平均值,这意味着我们可以有耐心!可靠的速率同步就像在较长时间间隔(理想情况下几天,但即使少得多也能很好地工作)的两端收集合理的质量时间戳一样简单。时间戳误差和质量评估中的误差然后被时间间隔的大小压缩,并进入 0.001 ppm 区域,在那里它们将永远不会再次困扰您。
一旦同步,pav 值具有很长的寿命。一个结果是,即使与服务器的连接丢失,差分时钟仍将保持良好同步。使用硬件验证的测试平台,我们进行了测试,结果表明,即使在与服务器断开连接 20 天后,RADclock 差分时钟测量的一秒间隔的精度也达到了亚微秒级。将这种鲁棒性水平与绝对同步的鲁棒性水平进行比较,在绝对同步中,在如此长的时间间隔内,本地时钟将不可避免地发生相当大的漂移,甚至更糟。
漂移不断发生,时钟必须随时准备好读取。由此可见,耐心不是一种选择:即使拥塞严重且定时数据包延迟,也必须在糟糕的情况下尽力而为;必须处理漂移!
主要有两个考虑因素。首先是使用定时数据包质量来控制其对时钟误差估计的贡献。控制必须非常严格:如果数据包的 RTT 仅比最小值略高,则该差距直接对应于要避免的误差!
第二个考虑因素是时间尺度。基本的权衡是需要尽可能多地获取定时数据包的数据,以增加幸运的机会,与需要它们是最近的数据,以便估计当前误差,而不是来自过去的过时误差。在这里,时间尺度 τ 起着关键作用,因为它对过去回顾的范围施加了有意义的限制。
绝对时钟可以简单地根据差分时钟定义如下
Ca(t) = Cd(t) – Ê(t)
其中 Ê(t) 是 Cd(t) 的误差估计,当进程读取绝对时钟时,会动态地消除该误差。图 6 显示了 Ê(t) 作为蓝色曲线,它是基于构成它的嘈杂的未过滤的每个数据包误差估计(绿色尖峰)计算得出的。真实误差 E(t) 是黑色曲线,它是使用外部 GPS 同步的 DAG 捕获卡1 在我们的测试平台中测量的。
到目前为止,我们已经讨论了与单个服务器同步。当然,人们可以连接到多个服务器并在它们之间进行选择,以获得更好的结果吗?原则上这是正确的;在互联网实践中,至少以目前的先进水平来看,绝对不是这样,原因有二。
最根本的是,切换服务器意味着路径不对称性的变化,因此时钟会跳跃。想象一下,一个服务器选择算法在质量相似的候选服务器之间移动。结果是不断的跳跃——不对称性抖动的经典案例。这种抖动在ntpd中不难观察到,实际上建议连接到多个对等方。
其次,一旦性能调整到接近系统和网络噪声限制,任何中断都会降低性能。例如,停止查询服务器一段时间然后再返回服务器,就属于中等到大型中断。
给管理员的要点是:如果您想提高系统时钟性能,只需确保配置仅指向单个(附近的)服务器。
服务器确实会更改,即使它们不更改,到服务器的路由最终也会更改。这不仅会出于不对称性原因导致不可避免的跳跃,而且对同步算法本身也是一个挑战。需要仔细设计,以便速率和绝对同步算法平稳且稳健地过渡到新环境。这必须从对过滤基础的质量评估的周全考虑的方法开始。如果这崩溃了,那么质量好的数据包可能会被评估为坏的,而坏的数据包可能会被评估为好的,并且潜在的损害是无限的。
是的,服务器是专家,没有服务器,同步是不可能的。尽管如此,不应信任它。服务器可能会并且确实会有糟糕的时期,盲目信任它们可能会导致严重的麻烦。幸运的是,还有另一个权威机构可用:计数器模型。如果 RTT 过滤告诉您拥塞很低,但服务器时间戳却说您突然偏差很大,请相信硬件并使用模型来对服务器进行健全性检查。基本上,远超 1 ppm 的漂移是不可信的,算法应该闻到老鼠的味道。
如果拥塞变得如此严重,以至于没有可用的时间戳是可接受的质量,该怎么办? 如果我不信任服务器,或者我完全失去了与服务器的联系,该怎么办?
只有一件事可以做:坐下来放松。除非算法选择这样做,否则不会发生任何坏事。在feed-forward范式中,不作为的反应很容易实现,并且只会导致计数器平稳漂移。记住,计数器非常稳定,最坏情况下每秒仅累积约 1 微秒。
更普遍地说,算法的设计应永远不会对任何事物反应过度。记住,它对世界的看法始终是近似的,并且可能是错误的,因此当不作为如此有效时,为什么要试图过于聪明?不幸的是,诸如以下的反馈算法ntpd具有更具反应性的策略,这些策略更强烈地驱动时钟朝着其意见的方向发展。这是它们对破坏性事件不鲁棒性的主要来源。
到目前为止,我们已经考虑了单个主机通过网络与服务器的同步,但是整个系统又如何呢?在 NTP 中,主要的系统方面是服务器层次结构。简而言之,Stratum-1 服务器充当树的根基,因为它们使用额外的硬件(例如,带有 GPS 接收器的 PC 或带有 GPS 的专用同步盒)进行本地同步,而不是通过网络进行同步。根据定义,Stratum-2 服务器与 Stratum-1 同步,Stratum-3 与 Stratum-2 同步,依此类推,主机与它们可以找到的任何服务器同步(通常是 Stratum-2 或公共 Stratum-1)。
在系统级别,存在许多重要且突出的挑战。Stratum-1 服务器彼此之间不通信,而是(除了在有限的情况下进行负载平衡)充当独立的孤岛。查询单个服务器以获取基本信息(例如,它是否已连接到其硬件并认为它已同步)的能力有限,并且无法查询整个服务器集。互连且感知不对称的 Stratum-1 基础设施可以为客户端提供许多有价值的服务。这些服务包括关于客户端最合适的服务器的建议、考虑到不对称抖动的备份服务器的自动提供以及关于服务器质量的验证信息。目前,没有人能够指责有问题的服务器,但它们确实存在。
基于 RADclock 算法,RADclock 项目3 旨在解决这些问题以及其他问题,作为推动在两年内提供强大的新网络定时系统的一部分。有关下载现有客户端和服务器软件(FreeBSD 和 Linux 软件包)、文档和出版物的详细信息,请访问项目页面。
问
RADclock 项目部分由澳大利亚研究委员会的 Discovery Projects 资助计划(项目编号 DP0985673)、硅谷社区基金会的思科大学研究计划基金和 Google 研究奖资助。
1. Endace。Endace 测量系统。DAG 系列 PCI 和 PCI-X 卡; http://www.endace.com/
2. Mills, D. L. 2006. 计算机网络时间同步:网络时间协议。博卡拉顿,佛罗里达州:CRC Press, Inc.
3. Ridoux, J., Veitch, D. RADclock 项目网页; http://www.cubinlab.ee.
4. Veitch, D., Ridoux, J., Korada, S. B. 2009. 网络上绝对时钟和差分时钟的鲁棒同步。IEEE/ Transactions on Networking 17(2): 417–430. DOI10.1109/TNET.2008.926505.
喜欢它,讨厌它?请告诉我们
Julien Ridoux 是澳大利亚墨尔本大学电气与电子工程系超宽带信息网络中心 (CUBIN) 的研究员,自 2006 年以来一直在此工作。他在 CUBIN 的主要研究兴趣是分布式时钟同步和互联网流量建模。他分别于 2001 年和 2002 年毕业于南特大学理工学院(法国)和巴黎第六大学(法国),获得计算机科学工程硕士学位和电信与网络理学硕士学位。2005 年,他毕业于巴黎第六大学,获得计算机科学博士学位。他是 IEEE 会员。
Darryl Veitch 是澳大利亚墨尔本大学电气与电子工程系超宽带信息网络中心 (CUBIN) 的首席研究员。他于 1985 年毕业于澳大利亚莫纳什大学,获得理学学士荣誉学位,并于 1990 年毕业于英国剑桥大学,获得数学博士学位。在目前在 CUBIN 任职之前,他曾在 TRL(澳大利亚电信,墨尔本)、CNET(法国电信,巴黎)、KTH(斯德哥尔摩)、INRIA(索菲亚-安提波利斯,法国)、贝尔科(新泽西)、RMIT(墨尔本)和 EMUlab(墨尔本大学)工作。他的研究兴趣包括流量建模、参数估计、主动测量、流量抽样和时钟同步。他是 IEEE 会士,也是 和 Sigcomm 的成员。
© 2010 1542-7730/10/0400 $10.00
最初发表于 Queue vol. 8, no. 4—
在 数字图书馆 中评论本文
David Collier-Brown - 您对带宽一窍不通
当您的员工或客户说他们的互联网性能很差时,带宽可能不是问题。一旦他们拥有 50 到 100 Mbps 范围内的带宽,问题就是延迟,即 ISP 的路由器处理其流量所需的时间。如果您是 ISP 并且所有客户都讨厌您,请振作起来。这现在是一个可以解决的问题,这要归功于一群专门的人,他们追捕并消灭了它,然后在家庭路由器中证明了他们的解决方案。
Geoffrey H. Cooper - 使用 FDO 和不受信任的安装程序模型的设备入职
设备的自动入职是处理越来越多的正在安装的“边缘”和 IoT 设备的重要技术。设备的入职与大多数设备管理功能不同,因为设备的信任从工厂和供应链转移到目标应用程序。为了通过自动入职加快流程,供应链中的信任关系必须在设备中正式化,以允许自动化过渡。
Brian Eaton, Jeff Stewart, Jon Tedesco, N. Cihan Tas - 通过关键路径跟踪进行分布式延迟分析
低延迟是许多 Google 应用程序(如搜索)的重要功能,延迟分析工具在维持大规模低延迟方面起着至关重要的作用。对于包含功能和数据不断发展的服务的复杂分布式系统,将整体延迟保持在最低水平是一项具有挑战性的任务。在大型、真实的分布式系统中,诸如 RPC 遥测、CPU 性能分析和分布式跟踪等现有工具对于理解整个系统的子组件很有价值,但在实践中不足以执行端到端延迟分析。
David Crawshaw - 一切 VPN 都是全新的
VPN(虚拟专用网络)已有 24 年的历史。这个概念是为与我们今天所知的互联网截然不同的互联网而创建的。随着互联网的增长和变化,VPN 用户和应用程序也随之发展。在 2000 年代的互联网中,VPN 经历了尴尬的青春期,与其他广泛流行的抽象概念交互不佳。在过去的十年中,互联网再次发生了变化,而这个新的互联网为 VPN 提供了新的用途。一种全新的协议 WireGuard 的开发为构建这些新的 VPN 提供了技术基础。