Synicism wrote:
蘋果工程師們又不是笨蛋，一定是有百分百的把握才敢使用啊
保固期內又不會出問題，又拿記憶體當緩衝
自然不是笨蛋，而是最大利益在賣這機子了
Rayco wrote:
沒有吧,TLC的寫入...(恕刪)
沒想到大大還願意在此回文～～辛苦了！
在此弱弱的一問：
我是否可以將LDPC解讀為讀/寫的控制器？
理論上MLC也能使用？
還有大大有找到蘋果所使用的ECC engine嗎？
有人沒轉出想要玩具的就在那裡耍小孩子脾氣.
一直要店員讓他重轉.直到掉出想要的玩具為止.
APPLE這點的確沒有做好.
問題就出在有差異的晶片沒有給消費者自已選擇的權利.
更深入的原因可能是因為APPLE覺得這兩者間的差異沒有大到必須給使用者選擇.
可能本來全是TLC.但製造商產能不足.所以部份送交MLC給APPLE.
就像我要做果醬需要100噸的B級水果.但果農因產能不足.所以裡面混有5噸的A級水果.
有人會把那5噸A級水果挑出來.說這些驗收不能過嗎?
買到MLC只能說是運氣好.但沒買到的一直在哪耍小孩子脾氣.我想那是不必要的.
使用TLC資料會不見? 機率幾乎是零.因為此晶片只有寫入過程失敗.罕見之後讀取失敗.
寫入失敗就再去找別的BLOCK再寫.直到整個晶片達到讀寫入上限.
讀取失敗的機率.不管是TLC還是MLC甚至是SLC.機率都同樣罕見.
至於使用TLC的人多久後會達到讀寫上限? 等有人達到了出問題再說吧!
Rayco wrote:
TLC用的ECC應該是使用LDPC,而且修訂的極限一但要接近的時候就會mark bad了,另外data retention不是主要問題,TLC的問題應該是read disturbance,不過這個也是經過控制,而且現在對於data retention的問題,TLC NAND基本上都有flush的機制來做避免,不是你說的那樣喔~~~
是這樣嗎?
LDPC的gate count 比BCH ECC大很多, 目前的TLC 60bits/1KB也還用不到LDPC (某牌TLC 除外). 如果硬要用LDPC, 只是讓成本上升罷了. 舉個例子, USB 目前幾乎都是用TLC了, 但USB 控制晶片的ECC engine絕大部分還是在用BCH. 為什麼呢?
至於mark bad 的機制, 每個控制晶片公司做法不同, 這個就不研究.
data retention確實會是問題, TLC 的PE就是幾百次, 接近PE極限的時候, data retention就會是問題了.
Rayco wrote:
沒有吧,TLC的寫入應該跟MLC不相上下~~~ TLC 主要寫入的方式應該是先寫SLC block之後再copy-back回去,所以你實際在用的時候,寫入速度TLC應該不會比MLC差到哪去,特別是如果他還有cache的話,那就更不用說,讀取的時候只要buffer夠大,其實不用load table的話,read也不會比較慢,您應該是不知道從哪邊聽到以訛傳訛的誤解~
TLC 的tprog本來就慢MLC 很多, 怎麼會不相上下?
先寫進SLC block 再copy back的做法並不是沒有缺點的. 我想到的就有2個.
1. 這種做法, 先寫入SLC block, 資料來的時候可以衝很快, 因為tprog跟SLC 的tprog差不多, 但是當資料一直進來, 總有一天, 你的SLC block會飽和, 也就是說, 這時候控制晶片就非得去把資料搬到TLC block去. 這種做法會看到問題就是大量資料持續灌進來時, 前面很快, 但是中間速度就掉下來了, 而且掉的非常多, 因為SLC block 不可能無限多.
2. 要先寫入SLC block再copy back. 那WAI 就不會很好看了, 因為每次資料進來至少就要寫再copy. 這還不算garbage collection 時還要再merge 資料. 而這對TLC SSD會很致命是因為TLC 的PE也就是幾百次. 光是controller 就那裡搬來搬去, 就把TLC 的PE搞完了.
再來, 有cache 也不表示無敵. 當有資料queue 在cache 裡, SPOR就會是很頭痛的問題. 不是每一個application 都可以加super cap去解決這個問題.
這些各家控制晶片廠商的做法不同. 我知道國內某家廠商是如您講的那種做法的.
內文搜尋
從 APP 打開
X