基於X86架構的時間管理虛擬化¶
- 作者:
Zachary Amsden <zamsden@redhat.com>
- 版權:
2010, Red Hat。保留所有權利。
1. 概述¶
X86平臺最複雜的方面之一，特別是該平臺的虛擬化，在於其計時裝置種類繁多以及模擬這些裝置的複雜性。此外，時間虛擬化帶來了一系列新的挑戰，因為它引入了一種超出客戶機CPU控制範圍的時間多路複用劃分。
首先，我們將描述可用的各種時間管理硬體，然後提出一些出現的問題和可用的解決方案，併為特定型別的KVM客戶機提供具體建議。
本文件的目的是收集與時間管理相關的資料和資訊，這些資訊可能在其他地方很難找到，特別是與KVM和基於硬體的虛擬化相關的資訊。
2. 計時裝置¶
首先，我們討論可用的基本硬體裝置。TSC和相關的KVM時鐘足夠特殊，值得進行全面闡述，它們將在下一節中描述。
2.1. i8254 - PIT¶
最早可用的定時器裝置之一是可程式設計中斷定時器（PIT）。PIT具有固定頻率為 1.193182 MHz 的基準時鐘和三個通道，可程式設計用於提供週期性或單次中斷。這三個通道可以配置為不同模式，並具有獨立的計數器。在最初的IBM PC中，通道1和2不適用於一般用途，歷史上它們連線用於控制RAM重新整理和PC揚聲器。現在，PIT通常作為模擬晶片組的一部分整合，並且不使用單獨的物理PIT。
PIT 使用 I/O 埠 0x40 - 0x43。對16位計數器的訪問是透過對I/O埠進行單位元組或多位元組訪問來完成的。有6種可用模式，但並非所有模式都適用於所有定時器，因為只有定時器2連線了門輸入，這是模式1和5所必需的。門線由埠61h的第0位控制，如下圖所示
-------------- ----------------
| | | |
| 1.1932 MHz|---------->| CLOCK OUT | ---------> IRQ 0
| Clock | | | |
-------------- | +->| GATE TIMER 0 |
| ----------------
|
| ----------------
| | |
|------>| CLOCK OUT | ---------> 66.3 KHZ DRAM
| | | (aka /dev/null)
| +->| GATE TIMER 1 |
| ----------------
|
| ----------------
| | |
|------>| CLOCK OUT | ---------> Port 61h, bit 5
| | |
Port 61h, bit 0 -------->| GATE TIMER 2 | \_.---- ____
---------------- _| )--|LPF|---Speaker
/ *---- \___/
Port 61h, bit 1 ---------------------------------/
下面將描述定時器模式。
- 模式0：單次超時。
這是一種單次軟體超時，當門為高電平（對定時器0和1始終為真）時開始倒計時。當計數達到零時，輸出變為高電平。
- 模式1：觸發單次。
輸出最初設定為高電平。當門線設定為高電平時，開始倒計時（即使門線降低也不會停止），在此期間，輸出設定為低電平。當計數達到零時，輸出變為高電平。
- 模式2：頻率發生器。
輸出最初設定為高電平。當倒計時達到1時，輸出會保持低電平一個計數週期，然後返回高電平。數值被重新載入，倒計時自動恢復。如果門線變為低電平，計數將停止。如果在門線降低時輸出為低電平，輸出會自動變為高電平（這隻影響定時器2）。
- 模式3：方波。
這會生成高/低方波。計數決定脈衝的長度，當達到零時，脈衝在高電平和低電平之間交替。計數只在門為高電平時進行，並在達到零時自動重新載入。每次時鐘都會將計數器減兩次，以全週期速率生成一個完整的高/低週期。如果計數為偶數，時鐘會保持高電平N/2個計數週期，低電平N/2個計數週期；如果計數為奇數，時鐘會保持高電平(N+1)/2個計數週期，低電平(N-1)/2個計數週期。只有偶數值會被計數器鎖存，因此讀取時不會觀察到奇數值。這是定時器2的預期模式，它透過對方波輸出進行低通濾波來生成類正弦音。
- 模式4：軟體選通。
程式設計此模式並載入計數器後，輸出將保持高電平，直到計數器達到零。然後輸出會持續低電平一個時鐘週期並返回高電平。計數器不會重新載入。計數只在門為高電平時進行。
- 模式5：硬體選通。
程式設計並載入計數器後，輸出將保持高電平。當門升高時，開始倒計時（即使門降低也不會停止）。當計數器達到零時，輸出會持續低電平一個時鐘週期，然後返回高電平。計數器不會重新載入。
除了正常的二進位制計數，PIT還支援BCD計數。命令埠0x43用於設定三個定時器各自的計數器和模式。
傳送到埠0x43的PIT命令，使用以下位編碼
Bit 7-4: Command (See table below)
Bit 3-1: Mode (000 = Mode 0, 101 = Mode 5, 11X = undefined)
Bit 0 : Binary (0) / BCD (1)
命令表
0000 - Latch Timer 0 count for port 0x40
sample and hold the count to be read in port 0x40;
additional commands ignored until counter is read;
mode bits ignored.
0001 - Set Timer 0 LSB mode for port 0x40
set timer to read LSB only and force MSB to zero;
mode bits set timer mode
0010 - Set Timer 0 MSB mode for port 0x40
set timer to read MSB only and force LSB to zero;
mode bits set timer mode
0011 - Set Timer 0 16-bit mode for port 0x40
set timer to read / write LSB first, then MSB;
mode bits set timer mode
0100 - Latch Timer 1 count for port 0x41 - as described above
0101 - Set Timer 1 LSB mode for port 0x41 - as described above
0110 - Set Timer 1 MSB mode for port 0x41 - as described above
0111 - Set Timer 1 16-bit mode for port 0x41 - as described above
1000 - Latch Timer 2 count for port 0x42 - as described above
1001 - Set Timer 2 LSB mode for port 0x42 - as described above
1010 - Set Timer 2 MSB mode for port 0x42 - as described above
1011 - Set Timer 2 16-bit mode for port 0x42 as described above
1101 - General counter latch
Latch combination of counters into corresponding ports
Bit 3 = Counter 2
Bit 2 = Counter 1
Bit 1 = Counter 0
Bit 0 = Unused
1110 - Latch timer status
Latch combination of counter mode into corresponding ports
Bit 3 = Counter 2
Bit 2 = Counter 1
Bit 1 = Counter 0
The output of ports 0x40-0x42 following this command will be:
Bit 7 = Output pin
Bit 6 = Count loaded (0 if timer has expired)
Bit 5-4 = Read / Write mode
01 = MSB only
10 = LSB only
11 = LSB / MSB (16-bit)
Bit 3-1 = Mode
Bit 0 = Binary (0) / BCD mode (1)
2.2. RTC¶
最初的PC中可用的第二個裝置是MC146818即時時鐘。原始裝置現已過時，通常由系統晶片組模擬，有時透過HPET和一些拼湊的IRQ路由實現。
RTC透過CMOS變數訪問，它使用一個索引暫存器來控制讀取哪些位元組。由於只有一個索引暫存器，讀取CMOS和讀取RTC都需要鎖保護（此外，允許hwclock等使用者空間工具直接訪問RTC是危險的，因為它們可能會破壞核心對CMOS記憶體的讀寫）。
RTC會生成一箇中斷，通常路由到IRQ 8。該中斷可以作為週期性定時器、每日一次的額外鬧鐘，並可以在MC146818完成CMOS暫存器更新後發出中斷。中斷型別在RTC狀態暫存器中指示。
即使系統關閉，RTC也會透過電池供電更新當前時間欄位。在更新進行時，不應讀取當前時間欄位，狀態暫存器中對此有指示。
該時鐘使用32.768kHz晶振，因此，如果RTC要計數秒數，暫存器A的位6-4應程式設計為32kHz分頻器。
這是最初用於RTC/CMOS的RAM對映
Location Size Description
------------------------------------------
00h byte Current second (BCD)
01h byte Seconds alarm (BCD)
02h byte Current minute (BCD)
03h byte Minutes alarm (BCD)
04h byte Current hour (BCD)
05h byte Hours alarm (BCD)
06h byte Current day of week (BCD)
07h byte Current day of month (BCD)
08h byte Current month (BCD)
09h byte Current year (BCD)
0Ah byte Register A
bit 7 = Update in progress
bit 6-4 = Divider for clock
000 = 4.194 MHz
001 = 1.049 MHz
010 = 32 kHz
10X = test modes
110 = reset / disable
111 = reset / disable
bit 3-0 = Rate selection for periodic interrupt
000 = periodic timer disabled
001 = 3.90625 uS
010 = 7.8125 uS
011 = .122070 mS
100 = .244141 mS
...
1101 = 125 mS
1110 = 250 mS
1111 = 500 mS
0Bh byte Register B
bit 7 = Run (0) / Halt (1)
bit 6 = Periodic interrupt enable
bit 5 = Alarm interrupt enable
bit 4 = Update-ended interrupt enable
bit 3 = Square wave interrupt enable
bit 2 = BCD calendar (0) / Binary (1)
bit 1 = 12-hour mode (0) / 24-hour mode (1)
bit 0 = 0 (DST off) / 1 (DST enabled)
OCh byte Register C (read only)
bit 7 = interrupt request flag (IRQF)
bit 6 = periodic interrupt flag (PF)
bit 5 = alarm interrupt flag (AF)
bit 4 = update interrupt flag (UF)
bit 3-0 = reserved
ODh byte Register D (read only)
bit 7 = RTC has power
bit 6-0 = reserved
32h byte Current century BCD (*)
(*) location vendor specific and now determined from ACPI global tables
2.3. APIC¶
在奔騰及更高版本的處理器上，每個CPU都有一個板載定時器，作為高階可程式設計中斷控制器（APIC）的一部分。APIC透過記憶體對映暫存器訪問，併為每個CPU提供中斷服務，用於IPI和本地定時器中斷。
儘管理論上APIC是本地中斷的安全穩定來源，但實際上，由於APIC CPU本地記憶體對映硬體的特殊性，已經出現許多錯誤和故障。請注意，CPU勘誤表可能會影響APIC的使用，並且可能需要採取變通措施。此外，其中一些變通措施對虛擬化帶來了獨特的限制——需要額外讀取記憶體對映I/O而產生的額外開銷，或者實現起來計算成本更高的額外功能。
由於APIC在Intel和AMD手冊中有很好的文件記錄，我們將在此避免重複細節。應該指出的是，APIC定時器透過LVT（本地向量定時器）暫存器程式設計，能夠進行單次或週期性操作，並且基於匯流排時鐘經過可程式設計分頻器暫存器分頻而來。
2.4. HPET¶
HPET相當複雜，最初旨在取代X86 PC的PIT/RTC支援。這種情況是否會發生還有待觀察，因為PC硬體的事實標準是模擬這些舊裝置。一些被指定為“無遺留裝置”的系統可能只支援HPET作為硬體定時器裝置。
HPET規範相當寬鬆和模糊，要求至少3個硬體定時器，但允許實現自由以支援更多。它也沒有對定時器頻率施加固定速率，但確實對頻率、誤差和偏移量施加了一些極值。
通常，HPET被推薦作為高精度（與PIT/RTC相比）的時間源，它不受本地變化的影響（因為在任何給定系統中只有一個HPET）。HPET也是記憶體對映的，並且其存在透過BIOS的ACPI表指示。
HPET的詳細規範超出了本文件的當前範圍，因為它在其他地方已有非常詳細的文件記錄。
2.5. 外部定時器¶
某些卡片，無論是專有的（看門狗板）還是常見的（e1000），都內建了計時晶片，這些晶片可能具有可供核心或使用者驅動程式訪問的暫存器。據作者所知，尚未有人嘗試使用這些晶片為Linux或其他核心生成時鐘源，並且通常不鼓勵這樣做，因為它不符合公認的遊戲規則。這樣的定時器裝置需要額外的支援才能正確虛擬化，目前不被認為重要，因為沒有已知的作業系統這樣做。
3. TSC 硬體¶
TSC或時間戳計數器在理論上相對簡單；它計算處理器發出的指令週期，可作為時間衡量標準。實際上，由於存在許多問題，它是最複雜的時間管理裝置。
TSC在內部表示為64位MSR，可以使用RDMSR、RDTSC或RDTSCP（如果可用）指令讀取。過去，由於硬體限制，可以寫入TSC，但通常在舊硬體上只能寫入64位計數器的低32位，而高32位則被清除。然而，現在在Intel家族0Fh處理器（型號3、4和6）以及家族06h處理器（型號e和f）上，此限制已解除，所有64位均可寫入。在AMD系統上，寫入TSC MSR的能力並非架構保證。
TSC可從CPL-0訪問，並且有條件地，對於CPL > 0的軟體，透過CR4.TSD位進行訪問，該位啟用時會停用CPL > 0的TSC訪問。
一些供應商實現了一個額外的指令RDTSCP，它不僅原子地返回TSC，還返回一個與處理器編號對應的指示符。這可以用於索引TSC變數陣列，以確定TSC未同步的SMP系統中的偏移資訊。此指令的存在必須透過查詢CPUID特徵位來確定。
VMX和SVM都在虛擬化硬體中提供了擴充套件欄位，允許客戶機可見的TSC透過一個常量進行偏移。較新的實現承諾允許TSC額外進行縮放，但這種硬體尚未廣泛可用。
3.1. TSC 同步¶
在大多數實現中，TSC是CPU本地時鐘。這意味著在SMP平臺上，不同CPU的TSC可能在不同時間啟動，具體取決於CPU何時通電。通常，同一晶片上的CPU會共享相同的時鐘，但並非總是如此。
BIOS可能會在開機過程中嘗試重新同步TSC，作業系統或其他系統軟體也可能嘗試這樣做。幾個硬體限制使問題更糟——如果無法寫入TSC的完整64位，則可能無法使新加入CPU的TSC與系統其餘部分匹配，從而導致TSC不同步。這可以透過BIOS或系統軟體完成，但實際上，除非所有值都從同一個時鐘讀取，否則不可能獲得完全同步的TSC，這通常只在單插槽系統或具有特殊硬體支援的系統上才可能實現。
3.2. TSC 與 CPU 熱插拔¶
如前所述，在系統引導時間之後加入的CPU的TSC值可能與系統其餘部分不同步。系統軟體、BIOS或SMM程式碼可能確實會嘗試將TSC設定為與系統其餘部分匹配的值，但完美匹配通常無法保證。這可能會導致系統從TSC同步的狀態回到TSC同步缺陷（無論多麼微小）可能暴露給作業系統和任何虛擬化環境的狀態。
3.3. TSC 與多插槽 / NUMA¶
多插槽系統，特別是大型多插槽系統，可能擁有獨立的時鐘源，而不是單一的、普遍分佈的時鐘。由於這些時鐘由不同的晶體驅動，它們的頻率不會完全匹配，並且溫度和電氣變化會導致CPU時鐘（以及TSC）隨時間漂移。根據具體的時鐘和匯流排設計，漂移可能在絕對誤差上是固定或不固定的，並且可能隨時間累積。
此外，非常大型的系統可能會故意偏移單個核心的時鐘。這種技術被稱為擴頻時鐘，它在時鐘頻率及其諧波處降低了EMI，這可能是透過電信和計算機裝置的FCC標準所必需的。
由於這些原因，不建議在NUMA或多插槽系統上信任TSC保持同步。
3.4. TSC 與 C-state¶
C-state，或處理器空閒狀態，特別是C1E和更深度的睡眠狀態，也可能對TSC造成問題。在這種狀態下，TSC可能停止前進，導致在恢復執行時，其TSC落後於其他CPU。作業系統必須根據CPU和晶片組標識檢測並標記此類CPU。
在這種情況下，TSC可以透過追趕已知外部時鐘源來校正。
3.5. TSC 頻率變化 / P-state¶
更值得關注的是，一些CPU可能會改變頻率。它們可能以相同速率執行TSC，也可能不以相同速率執行；而且由於頻率變化可能是錯開或偏移的，在某些時間點，TSC速率可能只知道在一個值範圍內，而不能確定具體值。在這種情況下，TSC將不是一個穩定的時間源，必須根據已知、穩定的外部時鐘進行校準才能成為可用的時間源。
TSC是否以恆定速率執行或隨P-state縮放取決於型號，必須透過檢查CPUID、晶片組或供應商特定的MSR欄位來確定。
此外，一些供應商存在已知錯誤，即在正常操作期間P-state實際上得到了正確補償，但當處理器不活動時，P-state可能會暫時提高，以服務於其他處理器的快取未命中。在這種情況下，停止的CPU上的TSC可能比未停止的處理器上的TSC前進得更快。AMD Turion處理器已知存在此問題。
3.6. TSC 與 STPCLK / T-state¶
給處理器的外部訊號也可能導致TSC停止。這通常是為了熱緊急電源控制以防止過熱情況發生，並且通常無法檢測到這種情況。
3.7. TSC 虛擬化 - VMX¶
VMX提供了對RDTSC、RDMSR、WRMSR和RDTSCP指令的條件捕獲，這足以以任何方式完全虛擬化TSC。此外，VMX允許透傳主機TSC以及VMCS中指定的額外TSC_OFFSET欄位。必須使用特殊指令來讀寫VMCS欄位。
3.8. TSC 虛擬化 - SVM¶
SVM提供了對RDTSC、RDMSR、WRMSR和RDTSCP指令的條件捕獲，這足以以任何方式完全虛擬化TSC。此外，SVM允許透傳主機TSC以及SVM控制塊中指定的額外偏移欄位。
3.9. Linux中的TSC特性位¶
總之，除非架構明確保證，否則無法保證TSC保持完美同步。即使如此，多插槽或NUMA系統中的TSC仍可能獨立執行，儘管它們在本地是一致的。
Linux使用以下特性位來指示各種TSC屬性，但它們僅對UP或單節點系統有意義。
X86_FEATURE_TSC |
硬體中提供TSC |
X86_FEATURE_RDTSCP |
提供RDTSCP指令 |
X86_FEATURE_CONSTANT_TSC |
TSC速率不隨P-state變化 |
X86_FEATURE_NONSTOP_TSC |
TSC在C-state下不停止 |
X86_FEATURE_TSC_RELIABLE |
跳過TSC同步檢查 (VMware) |
4. 虛擬化問題¶
時間管理對於虛擬化來說尤其成問題，因為它帶來了許多挑戰。最明顯的問題是時間現在由宿主機和（可能）多個虛擬機器共享。因此，虛擬作業系統並未以100%的CPU利用率執行，儘管它很可能做了這樣的假設。它可能期望在中斷源停用時仍能嚴格遵守精確的界限，但實際上只有其虛擬中斷源被停用，機器仍可能隨時被搶佔。這導致了問題，因為真即時間的流逝、機器中斷的注入以及相關的時鐘源不再與真即時間完全同步。
同樣的問題在原生硬體上也可能在一定程度上發生，因為當BIOS使用SMM模式時，SMM模式可能會從X86系統（自然開啟SMM）中竊取週期，但程度不會如此極端。然而，SMM模式可能導致與虛擬化類似的問題，這使得在裸機上解決其中許多問題有了很好的理由。
4.1. 中斷計時¶
遺留作業系統最直接的問題之一是，系統時間管理例程通常透過計數週期性中斷來跟蹤時間。這些中斷可能來自PIT或RTC，但問題是一樣的：宿主機虛擬化引擎可能無法每秒提供正確數量的中斷，因此客戶機時間可能會落後。如果選擇了高中斷速率，例如1000 HZ（不幸的是，這是許多Linux客戶機的預設設定），這尤其成問題。
解決這個問題有三種方法；首先，可能可以直接忽略它。具有獨立時間源來跟蹤“掛鐘時間”或“即時”的客戶機可能不需要調整其中斷來維持正確的時間。如果這還不夠，可能需要向客戶機注入額外中斷以提高有效中斷速率。這種方法在極端條件下會導致複雜性，例如宿主機負載過高或客戶機延遲過大而無法補償，因此出現了另一種解決方案：客戶機可能需要意識到丟失的節拍並進行內部補償。儘管理論上很有前景，但此策略在Linux中的實現極易出錯，並且許多帶有bug的丟失節拍補償變體分佈在常用的Linux系統中。
Windows使用週期性RTC計時作為內部時間保持手段，因此需要中斷偏移來保持正確時間。然而，它使用的速率足夠低（編者注：是18.2 Hz嗎？），以至於在實踐中尚未成為問題。
4.2. TSC 取樣與序列化¶
作為可用的最高精度時間源，CPU的週期計數器引起了開發人員的極大興趣。如上所述，該定時器作為本地的、可能不穩定且可能不同步的源，具有許多獨特的問題。一個並非TSC獨有但因其高精度特性而突出的問題是取樣延遲。根據定義，計數器一旦被讀取就已過時。然而，計數器也可能在實際使用結果之前就被讀取。這是指令流超標量執行的結果，指令可能亂序執行。這種執行被稱為非序列化的。強制序列化執行對於使用TSC進行精確測量是必要的，並且需要一個序列化指令，例如CPUID或MSR讀取。
由於CPUID實際上可能透過捕獲和模擬機制進行虛擬化，因此這種序列化可能對硬體虛擬化造成效能問題。因此，準確的時間戳計數器讀取可能並非總是可用，並且在實現中可能需要防範從其他CPU角度來看TSC的“倒退”讀取，即使在其他方面完美同步的系統中也是如此。
4.3. Timespec 混疊¶
此外，TSC的這種非序列化特性在使用TSC結果與另一個時間源進行測量時帶來了另一個挑戰。由於TSC的精度更高，當另一個時鐘仍表示相同值時，可能會讀取到TSC的許多可能值。
也就是說，當外部時鐘C保持相同值時，您可能會讀取到(T, T+10)。由於非序列化讀取，您實際可能得到一個波動的範圍——從(T-1.. T+10)。因此，任何從TSC計算但根據外部值校準的時間可能具有一個有效值範圍。重新校準此計算可能會導致校準後計算的時間相對於校準前計算的時間倒退。
這個問題在Linux內部時間源，即核心時間方面尤為突出，它以理論上的高解析度timespec表示，但其前進是以大得多的粒度間隔進行的，有時以jiffies的速率，在追趕模式下可能以大得多的步長。
這種混疊需要在計算和重新校準kvmclock以及從TSC計算得出的任何其他值（例如TSC虛擬化本身）時特別小心。
4.4. 遷移¶
虛擬機器的遷移在時間管理方面帶來了兩個問題。首先，遷移本身可能需要時間，在此期間無法傳遞中斷，之後客戶機時間可能需要追趕。NTP可能在一定程度上有所幫助，因為所需的時鐘校正通常足夠小，可以落在NTP可校正的視窗內。
另一個問題是，基於TSC（或HPET，如果原始匯流排時鐘暴露）的定時器現在可能以不同的速率執行，需要在虛擬機器監控程式中透過虛擬化這些定時器進行某種補償。此外，遷移到更快的機器可能會排除使用直通TSC，因為更快的時鐘如果對客戶機可見，可能會導致時間比平時更快地前進。較慢的時鐘問題較小，因為它總是可以追趕到原始速率。KVM時鐘透過簡單地儲存相對於TSC的乘數和偏移量來避免這些問題，供客戶機轉換回納秒解析度值。
4.5. 排程¶
由於排程可能基於精確的計時和中斷觸發，作業系統的排程演算法可能會受到虛擬化的不利影響。理論上，這種影響是隨機的並且應該普遍分佈，但在人為設計和真實場景（客戶機裝置訪問、虛擬化退出原因、可能的上下文切換）中，情況可能並非總是如此。這種影響尚未得到充分研究。
為了解決這個問題，一些實現提供了半虛擬化排程器時鐘，它揭示了虛擬機器實際執行的CPU時間量。
4.6. 看門狗¶
看門狗定時器，例如Linux中的鎖檢測器，在硬體虛擬化下執行時可能會由於定時器中斷延遲或對即時流逝的誤解而意外觸發。通常，這些警告是虛假的，可以忽略，但在某些情況下可能需要停用此類檢測。
4.7. 延遲與精確計時¶
精確計時和延遲在虛擬化系統中可能無法實現。如果系統控制物理硬體，或者為了補償裝置緩慢的I/O而引入延遲，就可能發生這種情況。第一個問題對於虛擬化系統通常無法解決；硬體控制軟體在沒有完整的即時作業系統的情況下無法充分虛擬化，這將需要一個RT感知的虛擬化平臺。
第二個問題可能會導致效能問題，但這不太可能是一個重大問題。在許多情況下，這些延遲可以透過配置或半虛擬化來消除。
4.8. 隱蔽通道與資訊洩露¶
除了上述問題，除了虛擬化時間的完美實現之外，時間資訊將不可避免地洩露給客戶機關於宿主機的資訊。這可能允許客戶機推斷虛擬機器監控程式的存在（如紅丸檢測），並且可能透過使用CPU利用率本身作為信令通道，導致資訊在客戶機之間洩露。防止此類問題將需要完全隔離的虛擬時間，這種時間可能不再跟蹤即時。這在某些安全或QA環境中可能有用，但通常不推薦用於實際部署場景。