世界標準時間架構

說明

Fuchsia 的時間同步處理必須具有彈性:在 Fuchsia 上建構的不同產品必須能夠使用不同的時間來源,且這些來源必須隨著產品演進,也必須能夠重新設定或取代。

本頁定義了提供彈性的基本架構:相關的元件、這些元件的角色和責任,以及元件之間的互動。

架構

下圖說明時間同步處理涉及的元件,以及這些元件之間的基本關係。

這張圖顯示 Fuchsia UTC 架構。

核心

核心定義了時鐘物件的概念,可用於追蹤時間進度。每個時鐘物件都是時鐘單調參考時間軸的一次維度仿轉換,可由使用者空間元件 (「時鐘維護者」) 調整,並可透過許多其他使用者空間元件 (「用戶端」) 觀察。

元件管理服務

元件管理服務負責建立 UTC 時鐘,並發布至其他使用者空間元件。

元件管理服務會建立 UTC 時間的核心時鐘物件,透過讀取建構程序的輸出內容,將「backstop 時間」設為建構作業中最後包含 CL 的時間。請注意,元件管理服務不會啟動這個 UTC 時鐘。

元件管理服務會將唯讀處理常式傳遞至啟動 UTC 的元件執行個體,並公開 fuchsia.time.Maintenance 服務,將讀取/寫入控制代碼發布至世界標準時間。在實際工作環境系統計時器中,應該是唯一可以存取這項服務的元件。

時間客戶

時間用戶端在 Fuchsia 裝置上採用世界標準時間。Fuchsia 實作 libc 會使用元件管理員提供的時鐘處理常式讀取世界標準時間,因此任何元件執行個體都可以使用執行階段提供的標準時間 API,做為時間用戶端。詳情請參閱語言支援

如果元件需要深入瞭解時間同步處理狀態,可以取得世界標準時間時鐘控點,並用來呼叫 zx_clock_get_details 或等待 ZX_CLOCK_STARTED 信號。

計時員

計時器負責依據產品定義的來源和政策,啟動及維護世界標準時間時鐘。

計時器會連線至 fuchsia.time.Maintenance 服務,在啟動時取得世界標準時間時鐘的可寫入控制代碼。它會啟動並連線至產品設定的時間來源元件,並連線至 fuchsia.time.external.PushSourcefuchsia.time.external.PullSource,以接收來自各個來源的時間同步處理資訊。注意: 自 2020 年第 4 季起,時間來源在計時器中是以硬式編碼的方式寫入,目前仍無法由產品設定。尚不支援 PullSource。

對特定產品來說,每個來源都會設為執行四種不同角色的其中一種:

  1. 主要:只要主要來源可用並且與任何限制來源一致 (即主要來源和限制來源回報的時間在一些上限內),主要來源就會用來維持 UTC 時鐘。
  2. 備用來源:當主要來源無法使用或不一致時,備用來源會用來維持 UTC 時鐘,前提是備用來源同時可用且與任何限制來源一致。
  3. 限制:管制來源是用來對另一個 (通常更準確、較不信任) 的時間來源提供有效性檢查。限制來源用於判斷是否應使用主要或備用來源。如果沒有可用的主要或備用來源 (或是可用但不一致時),限制來源即可用來維持世界標準時間時鐘。
  4. 監控:監控來源一律不會用來維持世界標準時間。系統會記錄指標,以便評估監控來源的效能,從而提供安全測試或「深色啟動」新演算法或修改過的演算法。

雖然這個靈活的系統可以支援許多來源,但我們預期大多數產品需要兩個不同的時間來源,其中僅限主要、主要+備用、主要+閘道和主要+監控器都是常用的設定。注意:自 2020 年第 4 季起,僅支援主要和監控來源

時間維護人員可自行斟酌將時間來源的資訊套用至 UTC 時鐘。如果更新不確定性明顯,或似乎是離群值,可能就會捨棄更新。需要套用大幅時鐘調整時,Timekeeper 必須在三種衝突需求之間取得平衡:

  1. 請盡量避免在一段時間後變更步驟。
  2. 透過搖桿套用校正的頻率調整不應過大。
  3. 用搖桿進行更正所需的時間不得過長。

計時工具是裝置硬體調節器效能的核心,它會追蹤觀察到的具體錯誤,並套用世界標準時間修正來因應這個錯誤。計時工具會使用衝刺來儲存循環器錯誤。注意:自 2020 年第 4 季起,尚未執行完整頻率校正演算法

在設有即時時鐘 (RTC) 的裝置上,計時器負責在初始化期間讀取 RTC,並定期更新 RTC 以反映世界標準時間。

時間來源

每個時間來源元件都有責任根據時間來源通訊的一或多個遠端來源,提供可用來同步處理世界標準時間的資訊。每個來源元件都會公開 fuchsia.time.external.PushSourcefuchsia.time.external.PullSource 服務 (或兩者皆公開)。

許多時間來源是透過一些能進行時間同步處理的通訊協定,透過網路與伺服器通訊,例如 NTP、Roughtime 或 HTTPS (請參閱 HTTPS 日期時間來源)。有些時間來源可以改為與本機硬體通訊,例如 GPS 接收器或 VLF 接收器。

時間來源元件封裝了用來與遠端來源互動的通訊協定知識,負責遵循此通訊協定的規則。這表示如果多個遠端來源使用相同的通訊協定,則單一時間來源元件執行個體通常負責與所有來源通訊,並在通訊協定中實作任何跨遠端來源要求。

每個時間來源都應獨立於其他時間,可讓您靈活選擇來源的安裝方式,並避免由多個時間來源之間的互動造成的複雜失敗模式。這表示時間來源一律不應在實作中直接使用系統世界標準時間 (UTC),因為系統 UTC 可能已納入其他時間來源的輸入內容。所有時間來源都會改為使用系統單音時鐘做為參考時間。

介面

時間資訊來源

時間來源可為計時器提供時間更新。

每次更新時,都會以更新時間最有效時的單音時鐘與時間來源決定的世界標準時間,表示。以通訊內容組合 (而非絕對時間) 的形式傳送更新,代表時間來源與時間保留工具之間的 FIDL 延遲不會直接影響準確度,可以清楚傳達更新最有效的單調時間。除了對應組合,時間來源也會傳送標準差,以表示與更新相關的不確定性。

時間來源可能支援兩種不同的作業模式:

  • 推送模式中,時間來源可決定何時產生更新時間,並自動將這些更新傳送至計時器。
  • 提取模式中,計時器會決定何時產生更新,並從時間來源要求這些更新。

在幾乎所有情況下,都適合使用推送模式,因為時間來源深入瞭解通訊協定、遠端資源使用率,以及任何依附元件的可用性,進而做出更適當的決策。提取模式可能適用於小型時間來源,或是很少使用時間來源 (例如每隔幾小時) 做為閘道來源的情況。如果使用提取模式,時間來源可能會拒絕時間更新要求,例如要求違反通訊協定的頻率限制上限。對於支援這兩種模式的時間來源,計時器會判斷要使用的模式,並連線至對應的服務。在沒有對這些服務的連線開放連線時,時間來源可能會選擇降低產生更新的頻率,或甚至完全不產生。

在推送模式下,Timekeeper 無法得知何時應該更新,因此不能從沒有成功更新的情況下推斷失敗:在推送時間模式中,時間來源也可提供整體健康狀態,讓計時器在何時切換時間來源時做出更好的選擇。

計時器到時間來源

時間管理程式提供的全域資訊可協助產生時間更新,包括:

  • 振盪器的頻率容忍度。
  • 觀察到的震盪頻率。

提供這些資料可確保時間來源不需要重複計時功能。自 2020 年第 4 季起,由於沒有時間來源需要這些資料,因此尚未定義 API

計時器不提供系統全域同步狀態的相關資訊,也未提供特定來源的更新是否會實際用於維持系統時鐘。這項刻意制定的決策可避免在時間來源之間產生意見回饋循環,並確保不同角色之間的時間來源行為一致。