虚拟机器中的POSIX时钟是如何“真实”的？

Question

简介：

时间是操作系统，Linux通常是从时钟芯片(RTC)派生出来的，或者由软件维护，使用周期性中断或一些硬件寄存器(例如CPU的TSC周期计数器)来实现。

显然，在虚拟机中没有直接的硬件访问(例如RTC)，因此保持正确的时间可能很棘手。

具体来说，我想知道两个POSIX时钟实现：CLOCK_REALTIME和CLOCK_MONOTONIC (还有更多的)。

扰动

我正在考虑两种主要的“干扰”：

1. "CPU过度提交“：向VM提供比物理CPU更多的虚拟CPU
2. “实时迁移”：将VM从一台计算机移动到另一台“不影响”操作的机器上

正常操作

在裸硬件上运行的操作系统中运行的进程只被操作系统(随后有控制)中断。这样，操作系统就可以轻松地保留时间。

VM操作

在VM中运行的操作系统不能连续地控制CPU。例如，如果操作系统“没有CPU"，它就不能处理定时器中断。反过来，这可能导致计时器中断完全丢失，以某种看似随机的量(抖动)延迟，甚至可能按快速顺序处理(现在处理“延迟”中断)。同样，时钟也不会像预期的那样线性地前进。

Choice

• CLOCK_REALTIME：如果操作系统缺少CPU，实时时钟要么被放慢(缺少后面)，要么偶尔向前跳以跟上。
• CLOCK_MONOTONIC：如果操作系统缺少CPU，实时时钟要么被减慢(相对于其他VMs或墙壁时间)，要么偶尔向前跳以跟上速度。

效应

• CLOCK_REALTIME：显然，如果实时时钟很慢，它就不能作为绝对的计时度量，但是在VM中它看起来是一致的。如果时钟通过跳转可变时间保持不变，那么它可以被用作绝对测量，但这对衡量VM中的任何性能(持续时间)都是有害的。
• CLOCK_MONOTONIC：只有当VM“有CPU”才能提供VM内运行时间的一致视图时，才能推进单调时钟。让时钟向前跳转可变的时间将防止在VM中使用性能(持续时间)度量。

Live-Migration

当动态迁移需要将内存的千兆字节从一个节点复制到另一个节点时，当VM无法运行时，会出现一些“冻结时间”，比如说3秒。

现在，实时时间也应该向前跳3秒，还是应该松开这3秒，直到在以后的某个时候被手动或自动更正？同样地，当单调时钟被用来测量“正常运行时间”时，它是应该通过添加这些时间来考虑这3秒，还是应该考虑VM实际拥有CPU的时间？

过度提交CPU

像上面一样，但是有更频繁的短期延迟，而不是偶尔更大的延迟。

问题

Xen使用什么方法？

VMware是如何处理这个问题的？有可配置的选项吗？(我知道在Xen中，VM可以与系统管理程序同步，也可以独立运行(例如，通过使用NTP从外部同步))

有什么“最佳做法”吗？

Answer 1

从某种意义上说，POSIX (和Linux )从来没有真正保证计时器--如果你把一些东西放在睡眠中，你可以期望它在某个特定的时间醒来。您只能保证唤醒发生在所述时间之后，而不是确切地发生在上面，也从未发生在它之前*。

Linux并不是实时的，它只是尽力做到最好。

来自符合POSIX标准的man 2 nanosleep：

Nanos休眠()挂起调用线程的执行，直到*req中指定的时间至少已经过去，或者传递一个信号来触发调用线程中的处理程序调用或终止进程。

如果您期望滴答是可靠的，那么这里的问题更可能是您没有一个启发式的地方来管理一个给定窗口内的幻灯片。

这里我的建议是重新考虑您的应用程序设计，以便在确切的唤醒上不那么可靠，或者在意外延迟的情况下具有故障安全。

即

• 该软件由于一些延迟异常而中止。
• 唤醒软件注意到与其他权威的时间来源的不同，并“步骤”它的想法下一个唤醒补偿。
• 您可以打印警告或提供其他通知.

认为时间在可抢占的系统中是可靠的是不可能的。即使是赤裸的金属。

• 不可掩蔽的中断不能阻止。
• 高负荷意味着你被安排了很长一段时间。
• 硬件调用的CPU中断会导致延迟。
• 小的和主要的页面错误会在计时器唤醒之间产生很长的延迟。
• CPU在非拥有内存库上分配内存会增加延迟。

这实际上只是现代x86计算的一个功能。

至少在KVM上，有一个称为‘kvm-时钟’的时钟源，它应该表示来自底层管理程序的滴答声，而不管VM中是否有任何未知的延迟。您可以找到该文件以及在此路径中设置的内容：/sys/devices/system/clocksource/clocksource*/current_clocksource，并查看您在/sys/devices/system/clocksource/clocksource*/available_clocksource中的选项。

但是，底层主机也可以有自己的延迟。所以它一直都是海龟..。

在不存在的情况下，不要依赖实时保证。构建软件，以应对意想不到的延迟，或者至少了解它们。

一般来说，NTP是一个完整的协议，用于处理时间问题、什么时间是“正确的”以及如何处理对时间的更改。这是个相当复杂的问题。

最佳实践是，您希望设置系统，以便在统计上使问题不太可能发生，考虑什么(如果有的话)将构成应用程序中时间的可靠权威，然后考虑如何处理时间确实发生变化的不可能事件。

也许你设置了一些SLA，说时间不对，1检查1000000个样本。这是--这是可能的，尽管从统计上讲，滴答是不太可能的。

我认为，在处理所有相关的不同系统组时，时间更重要的是，它们的时间位置*在一个很小的差异窗口内。在这个程度上，我将有一个本地时间服务器设置，它本身使用一些权威的源，然后将该组中的所有计算机同步到该本地系统。本地时间服务器的低延迟可以减少本地抖动，并且所有主机都应该保持非常紧密的同步。

• 一些计时器实现使用信号处理程序来捕获事件。，如果您在定时器之外发送一个进程一个ALRM信号，它会在它之前醒来。
• 这里的局部性将是所有逻辑上相互关联的计算机，所有的计算机都在几毫秒之内。但是，它们可能在另一个地方之间有很大的不同，IE是一组在500 is之外的延迟系统。