個人積分：255分
文章編號：21377634
小弟我一直對sandforce的架構持不信任的態度，就之前釋出的資料來看
sf的寫入方式，是先把資料寫入預留的block(一顆sf solution多半留20%左右)作cache用
再去對比→壓縮資料→寫入正式的block，問題是預留的block一直被無條件的直接寫入不就掛的很快?
這作法很像是初代沒有dram作cache，掛的很快，那如何重新再去分配正式block及預留作cache的block?
再來sf在寫入資料到一定程度後，作cache的block用完，效能掉的很誇張，約有20%~40%的降幅
在想會不會sf對於cache data refresh的能力有限?還是過度的refresh會加速nand死亡?
個人積分：138分
文章編號：21378775
個人積分：221分
文章編號：21379555
個人積分：201分
文章編號：21380190
whydan wrote:
有業內的人在，那不妨...(恕刪)
我覺得你好像比我利害耶....
我沒做Sandforce的Chip,所以無法100%了解它的流程.
但直接寫入預留的block這個動作擔心會讓block 掛掉,就要由wear leveling將erase平均化.
(我想你講的掛掉是指block壞掉沒錯吧)
cache data refresh的問題,我沒法回答.因為這是sandforce的技術. 我的方法一定跟他們不同. 最多也只跟你一樣了解表面上的做法. 就數學方面來看.我必需說,你講的對.我佩服之處是因為一方面很快,一方面為什麼它能突破我數學公式不足的地方及一些power cycling的問題.
至於performance掉20%的情況, 我想每家都差不多吧..
這讓我想起一件事. 德國和日本都是做工具機的大國,德國公差標2mm的工具機卻賣得比日本標1mm的好和貴(mm只是比喻). 為什麼? 因為德國的工具機在淘汰前都會一直維持2mm, 但日本的只有一開始用是1mm以後慢慢會跑掉...Intel比較老實,但消費者喜歡看比較大的數字.
yyyfly wrote:
SF裝超過一半是啥悽慘模樣
我也沒看過,因為我沒錢買.網上評測沒長期使用的.很難說. 等有人用了一年半載再麻煩來報告一下吧
個人積分：255分
文章編號：21380846
longyeekimo wrote:
我覺得你好像比我利害...(恕刪)
是的，是指壞掉，雖然說有wear leveling，但就我認知data cache的特性是需要不斷的讀寫(所學不精可能有誤)
就好像20%的部分要去負擔60~70% R/W 的工作，而且還是用34nm兩光牌的顆粒
比對那一點是我去推測的啦@@"，就先前SF提出來的資料裡的確是有提到壓縮的部分
但是壓縮後寫入正式block裡一定是非原始資料，如果資料有更新勢必要decode回來不作比對不怕資料error?
至於已經是高壓縮率的檔案我就不清楚了；推論到最後很有可能他宣稱有作壓縮資料的動作可能是沒有
不然還要decode、比對、壓縮接著寫入，這樣controller還能維持這麼高的寫入速度實在不太可能@@"
另外SF掉速的問題，可以看到其他人的測試，其實講掉20%~40%算很客氣的講法了
http://www.pcdvd.com.tw/showthread.php?t=895961
http://picasaweb.google.com/MGPGOD/LP#
http://picasaweb.google.com/MGPGOD/LPPart2#
個人積分：201分
文章編號：21381145
whydan wrote:
是的，是指壞掉，雖然...(恕刪)
嗯..不錯的資料. Update一下我的資料庫.
不過這點上的原理和做法不方便講. 這已經是機密問題了.
大概猜得出來怎麼回事.
只能說, cache block不是一直固定在那邊. 所以還是跟一般的data block一起循環. 所以不用擔心問題.
但performance掉這麼多倒是問題所在. 原因我是知道. 但不方便講. 講了就一堆業內的知道怎麼修了...這很抱歉.
只能說你指壓縮的問題是原因之一,但不是全部. 我甚至懷疑用壓縮的演算法. 因為像高度壓縮的資料,如RAR, MPEG,MP3等是不可能再被壓小很多. 考慮到這點. 壓縮法並不實用.再說壓縮演算法並不是一體適用的, 搞不好越壓越大.所以我並不覺得有用到壓縮.
但很多我也僅只於猜測. 不準不準...哈哈...
我只懂我自己的algorithm啦....
個人積分：255分
文章編號：21381354
個人積分：201分
文章編號：21381970
個人積分：149分
文章編號：21382083
個人積分：328分
文章編號：21384658
whydan wrote:
比對那一點是我去推測的啦@@"，就先前SF提出來的資料裡的確是有提到壓縮的部分
但是壓縮後寫入正式block裡一定是非原始資料，如果資料有更新勢必要decode回來不作比對不怕資料error?
至於已經是高壓縮率的檔案我就不清楚了；推論到最後很有可能他宣稱有作壓縮資料的動作可能是沒有
不然還要decode、比對、壓縮接著寫入，這樣controller還能維持這麼高的寫入速度實在不太可能@@"
...(恕刪)
壓縮、寫入應該是有的，但是您所謂的"decode、比對"的完整動作有兩種可能性：
<1>. 讀出要異動的page、解壓縮、與要寫入的資料比對、如果有變動則進行壓縮、寫入
<2>. 無條件壓縮、讀出要異動的page、在壓縮domain比對、有變動則進行寫入
其中<1>要進行的動作較多，如果SF真的有作比對，<2>是比較可能的作法，此外在壓縮domain進行比對的資料量，平均來說會比在未壓縮domain進行比對的資料來得少，較節省計算頻寬，但是如果壓縮的overhead明顯大於比對，採取<1>的作法也不是不可能。最後，若<1>跟<2>中的讀出、比對動作帶來的overhead過大，那SF控制器也可能只進行單純的壓縮、寫入兩個動作。
SF設計時，應該是收集了使用者對SSD真實使用情況的統計資料，再選定若干的可能代表性資料集、根據SSD控制器內處理器的特性跟能耐進行simulation，最後再決定演算法作法跟取捨，資料集應該不出有作業系統、以及10到20套常見的套裝軟體。一般來說這些軟體所包含的EXE檔、DLL檔、DAT檔、其他種類的binary檔/資料檔，都還可以有不錯的壓縮率，但是碰到已壓縮的圖檔、影音檔，大概就只有在header部分還能被壓縮；如果是RAR、CAB這種檔案，壓縮後還稍微變大的可能性也是有的；此外，NTFS本身也可以由作業系統進行壓縮，因此如果控制器再機車一點，還可以判斷壓縮後資料是否變小，如果不小反大，便以不壓縮的原始資料寫入並標記之。
未來SSD控制器的能耐之爭，可能拼的也包括統計資料的收集跟選定？如果使用者使用SSD的狀況是落在SF設定的情境內，那就會跑出SF的最佳狀況；相對的，如果是拿來存放影音資料檔、圖檔、或是使用者已經設定了NTFS壓縮，那就可能會陷SF控制器於不義；最後，如果統計資料中把市面上常見SSD/HDD人工測試程式的讀寫pattern比重放得過高，也不算是件好事.....即便不管在哪一個PC產品、零組件領域，針對人工測試程式的最佳化，大概都是心照不宣的事，只是程度問題......
因此，longyeekimo兄提到的日本跟德國的工具機公差的比喻，真的很有意思，因為不只可以用來比喻不同廠牌SSD在長時間使用後的效能衰退情況，在SSD控制器廠商跳脫NAND本身特性、演算法也開始從SSD本身所可能存放的"資料"特性下功夫的當下，使用者在全新的SSD存放的資料有哪些種類、比例如何、不同資料的讀寫特性，跟控制器廠商對外宣傳標準效能數據所基於的資料分布種類的差異程度，未來也都會影響使用者是否能跑出類似的數據。
