|
||
|
Golden Member
 
加入日期: Aug 2004
文章: 2,892
|
引用:
前段我認同 但是我比較相信 任何資料一定會被controller壓縮 可壓縮資料自然壓了以後 帳面數字出來就比較好看 單位時間內Real資料量比寫入NAND量大 (1GB寫NAND假設他花1秒 經過壓縮變0.5GB寫入 此時寫入速度 就變成2GB/s的速度了) 影音類的媒體無法壓 自然就照最高的controller-Channel-NAND速入寫入 也就是350MB/s左右 不過我說過這是推測 以最後兩句來講 除非你是RD除非拿出原廠paper 不然說實在講話不用這麼嗆 
__________________
|
||||||||
2012-07-24, 09:21 AM
#61
|
|
|
*停權中*
加入日期: Jan 2008
文章: 508
|
引用:
你可以用一般壓縮軟體自己測測看，就結果來說雖然「影音類的媒體無法壓」，但實際上需耗費更長的時間來處理 很抱歉讓你覺得嗆，雖然我也是推測，但假如我是RD的話，除非能力不足，否則絕不願做出比對手差的產品，但原生500MB/sec的輸出實在不是甚麼嚴峻的挑戰，這應該不難理解不是？ 此文章於 2012-07-24 09:50 AM 被 浮出水面 編輯. |
|||
|
2012-07-24, 09:44 AM
#62
|
|
|
Golden Member
加入日期: Jun 2002 您的住址: 地獄18層
文章: 3,236
|
那問題不用猜，我幫你們問看看原廠
__________________
徵你不要的AM4 CPU 徵你不要的SATA接頭斷裂SSD 
|
|
2012-07-24, 09:49 AM
#63
|
|
|
Senior Member
加入日期: Nov 2002
文章: 1,294
|
引用:
蠢...？我也希望我的CPU跑10GHZ，硬碟有20ZB啊 這樣考慮到裝置當時考慮各方面均衡度的設計 SF是去套一間設計VLIW方案Solution的Design House的設計 假如他目前只有這種方案你就得用
__________________
我只是巧合的瞄到了那百分之一的事實 但只要故做神秘的說了千分之一的實話 其他都是靠我的憑空想像來拼湊的胡言 大家以為我早就了解了百分之百的內幕 |
|
|
2012-07-24, 12:09 PM
#64
|
|
|
Senior Member
加入日期: Nov 2002
文章: 1,294
|
引用:
我的意思是全空的acces time反應極快，成績高的驚人 但那個速度沒有意義，放資料後access time是正常的 跟其他廠牌的SSD差不多，我用"全空的AccessTime高的驚人"可能描繪讓人誤解 不好意思。但我的意思其實是上面的說法，他在沒放資料前的access time 應該是只測試到主控而非Flash的回應。
__________________
我只是巧合的瞄到了那百分之一的事實 但只要故做神秘的說了千分之一的實話 其他都是靠我的憑空想像來拼湊的胡言 大家以為我早就了解了百分之百的內幕 |
|
|
2012-07-24, 12:12 PM
#65
|
|
|
Senior Member
加入日期: Nov 2002
文章: 1,294
|
引用:
提出350MB/S是因為測試表現這樣的狀況 另外THG也有這樣的測試，不過他測出來處理能力反而比較低 大概是接近300MB/S http://www.tomshardware.com/reviews...bps,3110-6.html
__________________
我只是巧合的瞄到了那百分之一的事實 但只要故做神秘的說了千分之一的實話 其他都是靠我的憑空想像來拼湊的胡言 大家以為我早就了解了百分之百的內幕 |
|
|
2012-07-24, 12:26 PM
#66
|
|
|
Senior Member
加入日期: Nov 2002
文章: 1,294
|
引用:
優先照顧Flash壽命跟完全不做任何處理並不一樣啊 刪除的資料你完全不去重新Rrcover佔用的區域 你下次再放入資料時還是得去做同樣的事情 盡量降低寫入可以說以零散的Page狀態就少去動 但完整的Block下確定刪除的部分，為何擺著不處理，要等下次資料進來再做？
__________________
我只是巧合的瞄到了那百分之一的事實 但只要故做神秘的說了千分之一的實話 其他都是靠我的憑空想像來拼湊的胡言 大家以為我早就了解了百分之百的內幕 |
|
|
2012-07-24, 12:34 PM
#67
|
|
|
*停權中*
加入日期: Jan 2008
文章: 508
|
引用:
說來說去仍舊只是假設(假設VLIW的性能只有350) 我還是認為我的解釋比較合情合理(最難解壓縮的花費時間最長速度也最慢) 而且以你的要求恐怕只有Ture Speed技術能滿足你，何必浪費時間在SF |
|
|
2012-07-24, 12:46 PM
#68
|
|
|
Power Member
加入日期: Dec 2002
文章: 512
|
引用:
你這是用一般ssd的狀況來想像ssd，那確實是這樣單純 已經完整刪除的block就找機會clear，並不會減少更多的壽命又可以增加效能 因為你反正下次使用還是得clear 為何sf不去做？因為這對sf晶片來說比較麻煩，而且反而會造成多餘的寫入耗損 sf不是採用普通的block/sector level或者混合的mapping table 所以sf比較不積極的去做這件事情 簡單說一般ssd的logical block跟physical block，雖不直接對應但可對襯 但sf的ssd，這兩者既不對應也不對襯 |
|
|
2012-07-24, 12:54 PM
#69
|
|
|
Power Member
加入日期: Dec 2002
文章: 512
|
引用:
sf就是fixed traffic flow的compression 她就是設計在300mb的flow rate 這對sata 600來說是很合理的數值 不然compression的效能益處就沒了（剩下容量的增益） 設計在300就是取兩者的均衡（flow越低容量增益越高） |
|
|
2012-07-24, 01:10 PM
#70
|
|
