NVMe · Q1–328

NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4

Q217–Q222

Keep Alive

Keep Alive 用來偵測 Host 是否仍維持連線活動，在 PCIe 上屬選配。本冊分開命令模式與流量模式，說明何時開始計時及到期後的結果。

每個問題都接著完整解說，依內容帶讀欄位、比較機制或追蹤流程。先看本冊總覽，再沿問題閱讀；必要條件與正常路徑直接顯示。所有數字案例均為教學假設；Status 以 SCT/SC 表示，代碼後的 h 代表十六進位。

SCT
Status Code Type，完成狀態代碼類型

兩種模式，兩種重新計時依據

一筆命令長期 outstanding，不等於每個流量區間都有新活動。

條件查詢或動作判讀
支援與粒度KAS、TBKASKAS 單位 100 ms；模式另確認
逾時設定FID0Fh.KATO要求值可能向上調整
命令模式成功 Keep Alive／KATO Set依成功操作重新計時
流量模式區間內取得命令不能只看仍有 outstanding

舉例看懂：KAS=2 表示 200ms 粒度；KATO 要求 250ms 時需向上配合粒度。Host 應讀回實際值，用它安排後續活動，而不是堅持回值必須等於 250。

來源：Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4

先把觀念接起來

教學 1 · 支援不代表已經啟動

先看 KAS 判斷能力，再看 KATO 是否非零，以及 controller 是否處於 EN=1、RDY=1 且沒有 shutdown 的適用狀態。少了這些前提，就不能只因過了某個時間要求出現 Keep Alive Timeout。這是能力、設定與運作狀態共同決定的計時器。

教學 2 · 流量模式觀察的是每個區間

假設一筆長命令在第一個區間被取得，之後一直執行。這只能證明第一個區間有活動，不能替所有後續區間提供新活動證據。Host 需依模式的活動觀察與 Keep Alive 策略維持需求，不能把一筆尚未完成的命令當作永久保活。

教學 3 · 到期是controller狀態變化

PCIe Keep Alive 到期會有指定錯誤記錄、停止處理及 CFS 等要求。這不是一般命令多等一下即可的延遲；Host 應保存時序與狀態，再按恢復流程重建通道。也不要套用本題範圍以外的傳輸資源清理規則。

需要時回顧本篇名詞
Controller / namespace
controller 接收命令並管理存取；namespace 是命令可指定的一份邏輯儲存空間。NVM subsystem 則包含 controller 與非揮發儲存資源，同一 subsystem 可以有多個 controller。
SQ / CQ / SQE / CQE
Submission Queue（SQ）是提交佇列，Completion Queue（CQ）是完成佇列；SQE 與 CQE 分別是其中的一筆命令及完成項目。QID 識別 queue，CID 區分同一 SQ 中尚未完成的命令，NSID 則識別 namespace。
Register / Identify / Feature / Log
Register 提供可存取的控制或狀態資訊；Identify 查詢物件的能力與屬性；Feature 用來讀取或變更工作設定；Log Page 回報特定種類的狀態或紀錄。FID、LID、CNS、CSI 則分別用來選擇 Feature、Log Page、Identify 資料結構及命令集。
index / offset / zero-based
index 指出清單中的第幾筆，通常從 0 起算；offset 表示與起點相隔多遠，解讀時必須確認單位。若數量欄位採 zero-based 編碼，實際數量等於欄位值加 1；但不是所有欄位看到 0 都要加 1。Dword 是 4 bytes，1 byte 是 8 bits。
Scope / reset / retention
scope 表示操作影響哪些物件；retention 表示狀態是否保留。清除 CC.EN 所觸發的 Controller Reset，是 Controller Level Reset（CLR）的一種。同屬 CLR 的不同觸發方式，仍可能採用不同的 Register 保留規則。

本冊題目

  1. Q217 · PCIe Host 如何確認 Keep Alive 支援？
  2. Q218 · Keep Alive Timer 如何設定、調整與停用？
  3. Q219 · Host 如何在 Timer 到期前維持 Keep Alive？
  4. Q220 · Keep Alive Timeout 後，Controller 必須做哪些清理？
  5. Q221 · Controller Reset 後，是否要重新設定 Keep Alive？
  6. Q222 · Command Based 與 Traffic Based Keep Alive 有何不同？

Q217 PCIe Host 如何確認 Keep Alive 支援？

跟著解說理解

Keep Alive 是通訊存活監測，不是每筆 I/O 的執行期限。PCIe 不要求所有 SSD 都啟用它。

1. 要查哪個對象、哪份資料

每個 controller 各自有 Timer，不能以另一個 controller 的活動替代。

Identify.KAS 非零表示支援，並給出以 100 ms 為單位的設定粒度；CTRATT.TBKAS 表示 Traffic Based 模式。

支援 Timer 就必須支援 Keep Alive 命令；設定透過 FID0Fh.KATO，單位為毫秒。

2. 查詢順序與回覆判讀

先讀 KAS，再判斷模式及需要的 KATO，最後 Get 確認實際採用值。

PCIe 的預設 KATO=0，即停用；支援能力非零與目前有啟用，是不同資訊。

3. 證據不足或不一致時怎麼判斷

KAS=0 時不能要求它接受 Keep Alive 或 Timer 設定；依實際不支援的 Opcode／Feature 回應判讀。

KAS、TBKAS、Commands Supported and Effects 與實際 FID 行為需一致。

FID
Feature Identifier，功能識別碼

先檢查是否誤把 PCIe 的選配能力當成所有裝置的必要功能。

來源：Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

Q218 Keep Alive Timer 如何設定、調整與停用？

跟著解說理解

Host 設定可容忍的通訊空窗；controller 依支援粒度採用可實作的值。

1. 操作前先準備什麼

設定作用於此 controller，不是整個 subsystem 的共同 I/O timeout。

先讀 KAS 與目前 FID0Fh.KATO，並確認 Feature 的保存能力。

Set Features CDW11.KATO 指定毫秒；controller 必須向上取到 KAS 的粒度。非零值低於實作最小值時，採最小值。

2. 先後順序與完成條件

Set 成功後 Get 讀實際值，再更新 Host 的發送排程；PCIe 可設 KATO=0 停用。

例如 KAS=10 表示 1000 ms 粒度，要求 1500 ms 會向上成 2000 ms，前提是沒有更大的最小值。

3. 未符合條件時如何處理

若要求超過適用傳輸允許的最大值，回 Keep Alive Timeout Invalid 且保留原設定；不能自行替 PCIe 編造固定最大限制。

Get 的回值可合法大於要求值；只有確認粒度與最小值後，才能判定調整是否不合理。

來源：Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

Q219 Host 如何在 Timer 到期前維持 Keep Alive？

跟著解說理解

預留時間餘裕，才能容納排程、命令處理與傳輸延遲；在最後一刻送出不代表 controller 已及時處理。

1. 操作前先準備什麼

只有 EN=1、RDY=1、SHN=00b、SHST=00b 且 KATO 非零時 Timer 才 active。

讀實際 KATO，並確認 Command Based 或 Traffic Based 模式。

Command Based 的 controller 在 Keep Alive 成功完成，或成功設定非零 KATO 時重新計時；普通 Read 不會替代它。

2. 先後順序與完成條件

Host 建議每 KATT/2 送 Keep Alive，並在 Admin SQ 保留可提交空間；調整 KATO 成功後也更新排程。

SQ
Submission Queue，提交佇列

持續收到成功 Completion 能證明這條通訊路徑仍能往返；不是證明每筆媒體操作都已完成。

3. 未符合條件時如何處理

Keep Alive 自己長時間沒有 Completion 時，Host 依其送出後 KATT 的判斷與恢復規則處理，不能無限補送來掩蓋失聯。

把 Host 送出、controller 完成與 Host 收到的時間分開，才能解釋兩端觀察差異。

來源：Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

Q220 Keep Alive Timeout 後，Controller 必須做哪些清理？

跟著解說理解

Timeout 清理讓失去可靠通訊的 controller 停止繼續處理命令，降低 Host 轉移工作後仍有舊操作進行的風險。

1. 先界定觸發方式與影響對象

本題只列 PCIe 適用動作；它不刪 namespace、不執行 Sanitize，也不承諾回復已寫入資料。

查 Identify.CQT、CSTS.CFS 與 Error Information，並保留 outstanding 清單。

2. 哪些狀態改變，恢復後怎麼處理

規範要求在 CQT 內記錄 Keep Alive Timeout Expired、停止命令處理，並設 CSTS.CFS=1。

Host 停止提交到該路徑，保存可取得的狀態，再依通訊恢復與 Reset 流程重建。

完成清理表示停止處理；不代表每筆 outstanding 都會取得成功或錯誤 CQE。

CQE
Completion Queue Entry，佇列中的完成項目

3. 如何驗證保留或恢復結果

不能以 Keep Alive Timeout 直接指定舊 Write「沒有執行」，也不能假設所有舊命令可以安全原樣重送。

CFS、Error entry 與清理時間應一致，資料操作則另查實際效果與重試相依性。

先確認逾時是 Host 自己判斷，還是 controller 已偵測並完成清理。

來源：Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

Q221 Controller Reset 後，是否要重新設定 Keep Alive？

跟著解說理解

Reset 結束舊命令環境，但 Timer 的恢復還取決於 Feature 保存與持續性，不能只因記得舊 KATO 就直接沿用排程。

1. 先界定觸發方式與影響對象

針對被重設的 controller，重新確認設定與 Timer active 條件。

查恢復後 Current KATO、支援能力及適用的 Saved／Default 規則。

2. 哪些狀態改變，恢復後怎麼處理

Timer 在 EN／RDY／SHN／SHST 任一條件不符時 inactive；再次由 inactive 轉 active 時初始化為有效 KATO。

完成初始化，Get 確認 KATO；若為 0 而 Host 需要啟用，再 Set 非零值並讀回，然後重啟 Host 維護排程。

Host 排程與 controller 的實際值、模式及新使用期間一致。

3. 如何驗證保留或恢復結果

Reset 前尚未完成的 Keep Alive 不能拿舊 CQE bytes 當成 Reset 後成功的存活證據。

CQE
Completion Queue Entry，佇列中的完成項目

重設前後比較的是設定恢復規則，不是要求倒數值接續到最後一毫秒。

先讀 Current KATO，再決定是否需要重設值，避免把「必須重查」誤寫成所有裝置都「必須重設同一值」。

來源：Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

Q222 Command Based 與 Traffic Based Keep Alive 有何不同？

跟著解說理解

兩種方式判斷存活的證據不同：前者靠專用命令，後者可利用一般命令流量。

1. 差別在哪裡

模式由支援 Keep Alive 的 controller.TBKAS 決定，不是 Host 任意忽略專用命令就算啟用 Traffic Based。

Traffic Based 的 controller 看每個 KATT 區間是否曾 fetched Admin 或 I/O command；Host 則用已提交且已處理 Completion 的活動作為省略 Keep Alive 的證據。

2. 如何選擇與確認

確認 KAS 非零與 CTRATT.TBKAS；TBKAS=0 使用 Command Based。

Host 在 Traffic Based 模式建議每 KATT/4 檢查是否需送專用命令；沒有足夠活動時仍送 Keep Alive。

一個區間有取得命令，controller 可開始下一區間，因此最後一次 fetched 後到偵測 Timeout 可能接近 2×KATT。

3. 比較時要保留的條件

不能要求 Traffic Based 在最後一筆命令後剛好 KATT 就一定 Timeout，也不能只因一筆長命令仍 outstanding 就認為每個後續區間都有新流量。

依 fetched、completed 與區間邊界核對，不把「Host 已寫 SQE」當成 controller 已取得。

SQE
Submission Queue Entry，佇列中的命令項目

來源：Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §3.9 (common and PCIe rules), 5.2.30.1.9 · Base 2.4 §5.2.14.2.1 · Base 2.4 §4.4 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

原文定位與既有圖表判讀

Base 的文件頁碼等於 PDF 頁碼減 26；NVM 與 PCIe 兩份規格的文件頁碼則與 PDF 頁碼相同。以下依提供的 PDF 本文列出章節、頁碼及 Figure 編號。若同一頁包含其他主題，只引用本題需要的定義，不納入 Fabrics 或 PCIe Link、封包內容。

  • Base 2.4 · §3.7.1–3.7.4
    文件頁 120–124 · PDF 146–150
  • Base 2.4 · §3.9 (common and PCIe rules), 5.2.30.1.9
    文件頁 129–135, 471 · PDF 155–161, 497 · Figure 481
  • Base 2.4 · §4.2.3
    文件頁 145–155 · PDF 171–181 · Figure 101–105
  • Base 2.4 · §4.4
    文件頁 166–169 · PDF 192–195 · Figure 126–127
  • Base 2.4 · §5.2.2
    文件頁 183–190 · PDF 209–216 · Figure 150–156
  • Base 2.4 · §5.2.13.1.2
    文件頁 218–220 · PDF 244–246 · Figure 212
  • Base 2.4 · §5.2.13.1.14 (header, reset, hardware, Set Feature events)
    文件頁 244–256, 258, 262–264 · PDF 270–282, 284, 288–290 · Figure 232–244, 246, 252–253
  • Base 2.4 · §5.2.14.2.1
    文件頁 340–387 · PDF 366–413 · Figure 338–341
  • Base 2.4 · §5.2.30.1 (common fields, scope and persistence)
    文件頁 456–460 · PDF 482–486 · Figure 463–466
  • Base 2.4 · §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2)
    文件頁 825–828 · PDF 851–854

需要看欄位圖時

以下連結可開啟對應的圖表教學，查閱欄位及判讀方式。每張圖保留固定的教學位置，方便之後反覆查詢。

使用的原始文件
  • NVM Express Base Specification · Revision 2.4 · 2026-07-31
    NVM-Express-Base-Specification-Revision-2.4-Ratified-2026.07.31.pdf
  • NVM Express NVM Command Set Specification · Revision 1.3 · 2026-07-31
    NVM-Express-NVM-Command-Set-Specification-Revision-1.3-Ratified-2026.07.31.pdf
  • NVM Express NVMe over PCIe Transport Specification · Revision 1.4 · 2026-07-31
    NVM-Express-NVMe-over-PCIe-Transport-Specification-Revision-1.4-Ratified-2026.07.31.pdf