再談3D XPoint:延時、QoS與隊列深度

2021-02-23 企業存儲技術

本文內容非商業用途可無需授權轉載，請務必註明作者及本微信公眾號、微博ID：唐僧_huangliang，以便更好地與讀者互動。

由於在上一篇《Optane P4800X比快閃記憶體寫快3倍，殺手應用在哪裡？》中我有遺漏的要點，並且周末時間有限分析得不夠透徹，故有必要就Optane SSD的延時再寫點東西。

 


之前我只講了Optane P4800X的典型讀/寫延時小於10μs，這裡的「typical」具體是指什麼條件我會在下文中解釋。

 

而這次要談的是QoS延時——4KB（KiB，4096位元組）塊大小、隊列深度（QD）16、99.999%的讀/寫IO延時不超過150/200μs。我們知道最小延時看看就好，那麼除了平均延時之外，按照目前的行業慣例，在一定QoS範圍內的延時比最大值更有實際意義。

 

這個0.15/0.2ms（換算得來）比NAND快閃記憶體SSD的優勢有多大呢？我們先來看看另一款產品的性能規格。

 

與希捷硬碟重名的WD Skyhawk SSD

 


前不久，被威騰電子收購的SanDisk發布了一個名為Skyhawk的低端系列企業級PCIe SSD，這一點從它的帶寬、IOPS性能上也能看出來。與大多數SSD標註最低延時不同的是，它列出的是4KiB、QD32下的平均讀寫延時。由於企業存儲應用中SSD面對的多是並發訪問，個人感覺高隊列深度下的延時應該比QD=1那些「漂亮」數字參考價值更大。

 

根據電梯算法原理，從HDD硬碟時代起就有通過增加隊列深度來提高IOPS性能的方法，代價就是延時成反比翻倍提高。SSD在也有類似的情況，後面我會給大家列出一些資料來參考。

 

具體到上面的數字，我們看到Skyhawk中表現最好的Ultra 1600GB讀/寫延時為125/351μs，注意這是平均值。如果QoS延時肯定還要高很多，所以不適合與Optane P4800X直接對比，下文中我還會列出Intel P3700的更多參數。另外我還注意到，調大OP（超量分配）之後的Ultra系列SSD延時表現比Standard更好；至於小容量點表現較好是不是因為SSD控制器的通道數不夠多啊？

 

扯點題外話，Skyhawk讓我想起去年希捷發布過一個監控硬碟也叫這名字。當然WD不是故意去碰這個瓷，因為早先他們收購過一家快閃記憶體系統廠商Skyera，Skyhawk曾經是這公司旗下的產品，也可能註冊過商標重新拿出來利用吧。

 

而希捷的那個Skyhawk監控硬碟，我想起接近20年前，曾經有一個低端系列的5400轉SCSI硬碟——捷鷹（Hawk）。當時還沒推出ATA版本的7200轉Barracuda（酷魚）定位就比它高。

 

50針全高SCSI硬碟，這張圖放在文中是不是有點不和諧:）

 

在網上搜了一下懷舊照片，希捷捷鷹（Hawk）HDD並不全是像上面這樣的「厚盤」，也有1英寸半高的型號。而在我的記憶中只剩下盤貼上那隻老鷹，還有中關村電子世界二樓偉仕公司（當年希捷硬碟總代）櫃檯寫出的宣傳牌了。

 

3D XPoint vs. 快閃記憶體SSD延時對比分析

 

前一篇中說過Intel SSD標稱的20μs延時是順序讀寫，隨機訪問的讀/寫延時為115/25μs，顯然寫I/O還是進入了DRAM緩存裡。

 

所謂「典型」測試的條件就是4KB傳輸大小、隊列深度=1；並且應該是FOB（開箱）性能，這個壓力沒有使SSD的快閃記憶體達到「穩態」。

 

相比之下，Optane P4800X小於10μs的延時沒有標註順序還是隨機，暫且按照後者來看吧。Intel曾經宣傳過「3D XPoint在很低的隊列深度下就能達到接近峰值性能」（詳見《從技術到應用：揭開3D XPoint Memory迷霧》一文），那麼QD=1的延時比Flash快閃記憶體低10倍也是正常的。

 


註：上表的測試條件包括4KB隨機工作負載，整盤測試範圍（full LBA）和SSD達到穩態性能等。

 

在Intel現有數據中心SSD的資料中，我只找到了99%和99.99%兩種QoS，以及QD=1、QD=128的延時數字。與Optane P4800X的QoS對比用99.9%那組相對還接近一些吧。

 

同時我發現P3700 NVMe SSD在QoS 99%時的寫延時比較典型，怎麼講呢？就是0.09和11ms這兩個數值恰好與隊列深度的倍數十分接近，這樣我是否可以推算出QD=16時的延時為1.44ms（0.09x16）左右呢？如果可行的話，OptaneP4800X在QoS 99.999%的寫延時也要比它好7倍還多。

 

P3700 QoS 99.99% QD=1的寫延時為2ms，在這種不對等的比較中，3D XPoint做為吃虧的一方仍然領先快閃記憶體十倍。

 

P3700 QoS 99.99% QD=16的讀延時，如果不出意外應該在4-5ms之間，Optane P4800X要勝出幾十倍了。

 

在Tom's Hardware網站上公布的450GB SSD（Intel DC P3520）QD16的99.99%讀/寫延時在1.976/6.752 ms以內，與我在上面分析的依據基本相符。由於目前看到的公開數據有限，討論不夠嚴謹之處還望大家諒解！

 

參考

《Intel's 3D XPoint-Powered Optane DC P4800X 'Cold Stream' NVMe SSDLeaks》

http://www.tomshardware.co.uk/wire-protocol-implementation-security-audit,news-54826.html

注：本文只代表作者個人觀點，與任何組織機構無關，如有錯誤和不足之處歡迎在留言中批評指正。進一步交流技術，可以加我的QQ/微信：490834312。如果您想在這個公眾號上分享自己的技術乾貨，也歡迎聯繫我：）

尊重知識，轉載時請保留全文，並包括本行及如下二維碼。感謝您的閱讀和支持！《企業存儲技術》微信公眾號：huangliang_storage


長按二維碼可直接識別關注

歷史文章匯總（傳送門）：http://chuansong.me/account/huangliang_storage

相關焦點

  • PointConv:基於3D點雲的深度卷積網絡
    使用該卷積，我們可以直接在3D點雲上構建深度卷積網絡。我們提出了一種有效的實現方法，大大提高了它的可擴展性。我們展示了其在多個具有挑戰性的基準測試中的強大性能以及在2D圖像中足以媲美基於網格的卷積性能的能力。在未來的工作中，我們希望將PointConv運用於更多主流的圖像卷積網絡架構中，例如ResNet和DenseNet。代碼請參見DylanWusee/pointconv。
  • RabbitMQ 消費端限流、TTL、死信隊列
    聲明String exchangeName = "test_qos_exchange";String queueName = "test_qos_queue";String routingKey = "item.
  • 大神帶你讀懂HCIE-Routing&Switching面試QoS之流量管理
    再回到我們的老丈人測女婿酒量，這次老丈人不再一個人往兩個桶倒酒了，叫上了丈母娘，一人負責一個桶。PIR（Peak information rate）：表示向P桶中投放令牌的速率，PIR大於CIR。可以根據三色來自定義行為，默認是綠色轉發，黃色重新分析再標記，紅色丟棄。流量整形TS 通常使用gts來限制流量。使用單桶單速雙色。綠色轉發，紅色緩存。接口限速LR 通常使用lr +inbound/outbound來限制流量速率，使用單速單通雙色。綠色轉發，紅色（如果在交換機出方向為緩存，入則丟棄）。
  • 第一款3D Xpoint快閃記憶體SSD銷量差 美光:不放棄、將繼續推進
    不過，傲騰的3D Xpoint晶片仍要靠猶他州的IM工廠生產提供，也就是仰仗美光。據美光最新表態，3D Xpoint仍是公司關注的領域和業務，且有明確的路線圖。日前出席伯恩斯坦運營決策會議時，美光CFO David Zinsner坦言，3D Xpoint的收入幾乎全來自外售存儲晶片。
  • Keras實例:PointNet點雲分類
    本示例實現了點雲深度學習論文PointNet。原文連結：https://keras.io/examples/vision/pointnet/準備工作首先使用下列命令安裝trimesh庫，這個包用於可視化數據：然後安裝引入相應的庫import osimport globimport
  • 基於HTML5的WebGL經典3D虛擬機房漫遊動畫
    = new ht.graph3d.Graph3dView(dm); //.......構建好場景 dm.serialize();//可以填入number參數，作為空格縮進值既然我們已經搭建好環境，轉成了 json 文件，代碼中不好控制，這種情況下我們會將 DataModel 數據模型再反序列化，這個函數的功能就是將 json 格式轉成對象，並將反序列化的對象傳入到 DataModel
  • 怎麼實現的延時隊列?以及訂閱模式、LRU
    正常的一次Redis網絡交互如下：pipeline主要就是將多個請求合併，進行一次提交給Redis伺服器，Redis伺服器將所有請求處理完成之後，再一次性返回給客戶端。Redis實現消息隊列和延時隊列消息隊列Redis的實現消息隊列可以用list來實現，通過lpush與rpop或者rpush與lpop結合來實現消息隊列。
  • 3D點雲 | 基於深度學習處理點雲數據入門經典:PointNet、PointNet++
    因此，在使用圖像識別任務的深度學習模型處理點雲數據之前，需要對點雲數據進行一些處理。目前採用的方式主要有兩種：1、將點雲數據投影到二維平面。此種方式不直接處理三維的點雲數據，而是先將點雲投影到某些特定視角再處理，如前視視角和鳥瞰視角。同時，也可以融合使用來自相機的圖像信息。
  • plot3d網格讀取寫入與可視化
    說明plot3d格式是NASA制定並大量使用的CFD網格文件格式，在CFD編程過程中經常涉及到。
  • "黑科技"怕了沒 小白如何搞懂3D Xpoint
    作為直接參與了本次IDF 15前方報導的人，筆者決定對3D Xpoint技術做一個簡單易懂的解析，以幫助大家搞清楚3D Xpoint到底是個啥技術。·存儲結構從2D走向3D  3D Xpoint是一種立體化的存儲技術，它看起來與同為3D設計的TLC NAND技術相似，但其實本質卻不同，3D Xpoint並不單純是NAND，而是一種新的存儲介質，是一種新的非易失性存儲技術。
  • Java中常用隊列的總結
    在這篇文章中，凱哥對這三個隊列做了詳細的介紹以及代碼演示。DQueue：是一個支持優先級的無界阻塞隊列。支持優先級是應該底層使用的是PriorityQueue隊列來實現的。而PriorityQueue隊列在添加元素的時候使用了siftUpComparable方法。這個對了的一個特點：支持延時獲取。
  • 用3D XPoint的傲騰900P有多強?高不可攀的性能天花板
    因為NAND快閃記憶體的這一特性所以SSD主控得使用極其複雜的垃圾回收算法，以保持SSD的高效運作，但這始終會消耗主控的資源，而已bit為讀寫單位的3D XPoint來說它並不需要什麼垃圾回收機制，而且它的寫入操作是和HDD一樣是可以直接覆寫的，沒有擦除這步操作，所以寫入延時要大大低於NAND快閃記憶體，而且主控和固件也可以簡化不少，當然了以bit為單位進行尋址是需要大量高速緩存配合的
  • Darnell Mayberry:At no point in Thunder h
    At no point in Thunder history has the franchise so closely mirrored its mercurial superstar point guard: How Oklah… https://t.co/3d0eY7T3LQ
  • 消息隊列:Rabbitmq如何保證不丟消息
    消息的流程：消息是由生產者生產了之後，上報給exchange，exchange綁定並存儲到queue中，再傳遞給最終的消費者手裡。如此以來，整個過程就分成了三大場景：場景1: 生產者與exchange的上報消息，如何保證不丟失？
  • Python繪製3D圖形:Axes3D
    3D圖形繪製需要（x,y,z)三組值，下面通過numpy和Axes3D函數會議3D圖形。其中Axes3D是mpl_toolkits.mplot3d中的一個繪圖函數，mpl_toolkits.mplot3d是Matplotlib裡面專門用來畫三維圖的工具包。
  • Java中常用的七個阻塞隊列第二篇DelayQueue源碼介紹
    再來看看為什麼說DQueue隊列使用的是PriorityQueue實現的呢?來看看源碼：在添加元素的offer方法源碼中，我們可以看到最終調用的是q.offer(e)這個方法的。那麼q又是什麼呢？發現q是PriorityQueue這個隊列。如下圖：為什麼說可以延時呢？
  • 這些MQ概念你都懂嗎:死信隊列、重試隊列、消息回溯等
    消息隊列(MQ)的基本概念，很多時候都要了解清楚，這樣在學消息隊列中間件就比較能夠遊刃有餘，遇到不清楚的也可以重新翻來看看，加深理解。這裡有關於：優先級隊列、延遲隊列、死信隊列、重試隊列、消息回溯、消息堆積、消息追蹤/消息軌跡、消息過濾、消息審計、消息路由等的介紹。
  • 單片機延時方法小結
    實現延時通常有兩種方法：一種是硬體延時，要用到定時器/計數器，這種方法可以提高CPU的工作效率，也能做到精確延時;另一種是軟體延時，這種方法主要採用循環體進行。2 軟體延時與時間計算在很多情況下，定時器/計數器經常被用作其他用途，這時候就只能用軟體方法延時。下面介紹幾種軟體延時的方法。
  • Open3d 學習計劃—13(Azure Kinect)
    在Windows,Open3d將從默認的安裝路徑加載共享庫.舉個例子,對於v1.2.0版本的K4A,默認的安裝路徑是 C:\Program Files\Azure Kinect SDK v1.2.0 .如果這個不起作用,複製 depthengine_x_x.dll, k4a.dll 和 k4arecord.dll文件到Open3d Python模塊安裝的路徑(如果你用的Python),或者到你的
  • 圖解堆算法、鍊表、棧與隊列
    在隊列中，調度程序反覆提取隊列中的第一個作業並運行，因為實際情況中某些時間較短的任務卻可能需要等待很長時間才能開始執行，或者某些不短小、但很重要的作業，同樣應當擁有優先權。而堆就是為了解決此類問題而設計的數據結構。