標題: 平野SSD仲要係made in japan [打印本頁]

---

作者: 167pk    時間: 2011-2-19 11:28     標題: 平野SSD仲要係made in japan

提示: 作者被禁止或刪除 內容自動屏蔽

---

作者: rabi    時間: 2011-2-19 12:04

買來 B 野都 ok 喎。

---

作者: Chick    時間: 2011-2-19 12:12

佢話"集成了64M缓存"，會唔會係Toshiba controller？
128GB唔使￥1000又幾底，Kingston用Toshiba controller 64GB都要$900。

---

作者: 167pk    時間: 2011-2-19 12:19

提示: 作者被禁止或刪除 內容自動屏蔽

---

作者: 167pk    時間: 2011-2-19 12:21

提示: 作者被禁止或刪除 內容自動屏蔽

---

作者: rabi    時間: 2011-2-19 12:23

本帖最後由 rabi 於 2011-2-19 12:27 編輯

回復 4# 167pk

你以為我唔知？

就算係 MLC 都一萬次，唔用來做 OS 的話，一日完全覆寫三次，都要用成十年先玩得死成全部 cell，用來 BT 的原因是避免磁頭的頻繁跑動，整死 HD。而且 SSD 的「讀取」次數理論上是無限的，和 HD 好唔同，碎片夠多的話，HD 是很容易「讀」死的。

---

作者: 167pk    時間: 2011-2-19 12:25

提示: 作者被禁止或刪除 內容自動屏蔽

---

作者: kit3    時間: 2011-2-19 12:26

提示: 作者被禁止或刪除 內容自動屏蔽

---

作者: 167pk    時間: 2011-2-19 12:28

提示: 作者被禁止或刪除 內容自動屏蔽

---

作者: rabi    時間: 2011-2-19 12:34

回復 7# 167pk

哈！原來我好有米？說不上。

我只是不會用 HD 來 BT 姐，一係 Ramdisk 一係 SSD，手指唔太理想，會跌速。我真係留意緊一些平價 SSD，入手用來 BT，騰出空間來玩其他野…

師兄推介的這款 SSD 用 32nm 全新制程，唔知會唔會中雷，但售價認真吸引，唔用來做 OS 我先會考慮，如果你會入多隻請 PM 我，預我一只。

---

作者: wgpoon    時間: 2011-2-19 12:35




    其實之前BT 咁易死harddisk 就如上面某師兄所講,
因為磁頭頻繁讀寫,

而SSD 就無呢個問題,
而且當你BT Download 4GB file, SSD 上就只係寫入4GB, 同你解壓個4GB file 無分別

但harddisk 就唔同, BT download 4GB file 讀頭可能來回碟面過萬次

當然啦, 容量上SSD 都唔夠harddisk 大, BT 時可能會唔夠容量

---

作者: nu8976    時間: 2011-2-19 12:38

MIJ 個價好吸引
出report 出report

---

作者: rabi    時間: 2011-2-19 12:41

回復 11# wgpoon

小弟的表達能力差，多謝師兄為我解說，100% 全中。

有些無聊人會話「讀頭可能來回碟面過萬次」和 HD 的死亡無關系，還會進一步要你提出理據，那你會怎樣令這類 lulu 信服呢？

---

作者: 167pk    時間: 2011-2-19 12:43

提示: 作者被禁止或刪除 內容自動屏蔽

---

作者: wgpoon    時間: 2011-2-19 12:50

本帖最後由 wgpoon 於 2011-2-19 12:51 編輯



    讀頭可能來回碟面過萬次

其實呢句都有少少過時
係BT 一出時, 的確係有"讀頭過萬次來回問題"
而家新一代BT software 已經識借ram 來做cache
如bitcom?t 就會寫
[attach]1139284[/attach]

但「讀頭可能來回碟面過萬次」和 HD 的死亡關系
我都只可以講一句, harddisk 點都會死, 要驚就唔好用

---

作者: rabi    時間: 2011-2-19 12:57

回復 14# 167pk

no...no...no......

唔會爽的，只係無手尾俾你跟姐，set RAM cache 都無法解決讀寫頻繁的問題，因為我一開 BT 就會 8 個 job 以上，每個 job 都 5GB…

RAMdisk 爆左，咪用 SSD 囉，到了 SSD 都爆，可能都焗住要用一隻 HD「死士」，驚 HD 死就唔好用，這句我很同意。

---

作者: insanity    時間: 2011-2-19 16:12



其實..SET大BT 個CACHE 已經可以解決大部份問題..

---

作者: insanity    時間: 2011-2-19 16:14


有用RAM 已解決左個問題啦...有RAM做CACHE 咪好似RAMDISK 咁囉..
有RAM 做CACHE 已經變左好次直接抄FILE 過去咁
除非你話你連直接抄FILE 過HDD都驚..

---

作者: Chick    時間: 2011-2-19 16:27

回復 5# 167pk
其實我仲用緊JM，都唔係D人講咁差，普通應用一定快過HDD，開機只係慢過X25M 1秒。
不過唔明佢講話有64MB cache，老作定係新D嘅JMF612/616？係就超值啦。

---

作者: C-Leung    時間: 2011-2-19 16:43



原來係咁！
不過冇錢買隻ssd泥bt
都係繼續用隻80GB ata harddisk bt，死左都唔可惜

---

作者: gum    時間: 2011-2-19 16:54

本帖最後由 gum 於 2011-2-19 16:57 編輯


我都係咁, 識既人之中, 已經冇咩聽到人好似以前一出BT時BT死隻HD, 隻隻都最少2-3年以上. 我隻320GB已經進入第4年, 有時都同時B幾隻1080, 隻隻都十幾廿GB.  有個FRIEND用隻IDE既120GB就更加唔洗講用咗幾耐. 如果真係咁易死, 我估都冇咩人玩BT.就算買隻全新既HD黎B野, 都要買幾隻先等於1隻幾十GB既SSD.

---

作者: rabi    時間: 2011-2-19 17:13



係，係解決左頻繁「寫」的問題，那頻繁「讀」的問題呢？你一定係忽略左喇。

---

作者: wilsonkf    時間: 2011-2-19 23:04

提示: 作者被禁止或刪除 內容自動屏蔽

---

作者: Niel    時間: 2011-2-19 23:32




讀都有cache，而且讀比寫更易cache而且更好控制，因為bt client可以一次過幾個block讀之後再cache再upload比其他人。更何況現代的client(如utorrent)會monitor hdd utilization，hdd太忙的話會只係selectively upload cache左的block，咁就唔會再加重hdd的負擔。

---

作者: Niel    時間: 2011-2-19 23:35




JM新果d係好d，不過response time都係太慢，maximum response time可以慢過HDD，所以都係唔推薦。

---

作者: 167pk    時間: 2011-2-20 00:37

提示: 作者被禁止或刪除 內容自動屏蔽

---

作者: hohohk    時間: 2011-2-20 01:44




    不過HDD咁平, B死左都唔怕...

---

作者: insanity    時間: 2011-2-20 01:54



讀咪一樣..佢都係夠數先會一大個塊咁READ出黎...

---

作者: insanity    時間: 2011-2-20 02:02


CONTROLLER IC 邊有咁易熱死..
SSD 一樣有CONTROLLER..咁SSD快O的
照你個推論SSD咪仲易死？

---

作者: wilsonkf    時間: 2011-2-20 02:06

提示: 作者被禁止或刪除 內容自動屏蔽

---

作者: 絕望之黑暗    時間: 2011-2-20 02:37




    用了半年就只有45%.....10年我不太樂觀

---

作者: sonichkhk    時間: 2011-2-20 02:49

保多久 ,可不可去換@@

---

作者: love19901109    時間: 2011-2-20 02:56

回復 31# 絕望之黑暗
咁睇黎你就要拎去保養

---

作者: Niel    時間: 2011-2-20 03:22




你果隻Indilinx...sure不太樂觀

JM其實差不多...都係不太樂觀

---

作者: kazenorin    時間: 2011-2-20 04:29

本帖最後由 kazenorin 於 2011-2-20 04:31 編輯

回復 6# rabi

咁係唔係應該用 ram disk 黎 b 野

edit: 睇到第二頁已有答案

---

作者: rabi    時間: 2011-2-20 09:38



你這隻盤是 C:

即係 OS 盤，好正常喎。

搵 MLC 來做 OS，一定要夠大，而且不能「常滿」，我成日話 SLC 低買無人信。

---

作者: kazenorin    時間: 2011-2-20 09:46



你指用黎做 OS, 會死得快過 BT

---

作者: rabi    時間: 2011-2-20 10:10

回復 37# kazenorin

當然啦，以 #31 的 30GB Corsair 為例，裝了 OS 後，數得出一日覆寫超過十次的 file 超多，不是 BT 一日覆寫唔夠五次咁少。

---

作者: arimedir    時間: 2011-2-20 10:38




   
[attach]1139829[/attach]

我呢隻都用左半年度
點解唔同controller會差咁遠:funk:

---

作者: 絕望之黑暗    時間: 2011-2-20 22:13

本帖最後由 絕望之黑暗 於 2011-2-20 22:18 編輯



   可是我不知道香港代理是誰？
另外買SSD 不用來裝OS，買來做甚麼。。XD
另外未有壞磁區可以換？
雖然現在已經SSD失去寫入速度了

---

作者: love19901109    時間: 2011-2-20 22:37

回復 40# 絕望之黑暗
我都系拎黎做OS...    暫時未有你呢個情況
我記得好似漢科保

---

作者: 絕望之黑暗    時間: 2011-2-20 23:02




    漢科網站只有V64，V128 沒有V32

---

作者: Niel    時間: 2011-2-20 23:24




用來BT係死得快過做OS drive...

rabi的論點係完全不成立的，因為HDD同SSD的做法不同，大家要分清楚，不可用傳統思想去理解。

對HDD來說，好多時file system overwrite 一個file，HDD都係會立即physically commit.

對SSD來說，file system overwrite 一個file，SSD係不會physically commit (modern controller)。因為SSD要physically overwrite一個file，係需要成個block erase，再成個block rewrite。SSD controller會delay依一類指令，原因有:

1. 如果立即commit，Write Amplication會立即被大幅拉高(i.e.壽命減少)。
2. 如果立即commit，由於成個block read + erase + rewrite需時相對長，performance會大幅下降 (JM controller就係有依類問題)

所以ssd controller會將updated file寫入新page，不會立即rewrite(甚至完全不會rewrite)，然後update LBA，成個過程file system係不會知道。

所以同一file overwrite 不等於 同一NAND block rewrite，對壽命影響同normal write一樣。

所以計SSD壽命唔係計覆寫次數，係計total written data。

如果大家明白的話，就自然會明白一個好的controller + MLC係可以好長命。

---

作者: Niel    時間: 2011-2-20 23:28

本帖最後由 Niel 於 2011-2-20 23:32 編輯


係呀，一個好的controller係極重要。

---

作者: Nightstalker    時間: 2011-2-20 23:31

老老實實,
咁嘅價錢,
我覺得抵玩WO.

---

作者: BA1314BA    時間: 2011-2-20 23:55

hdd效能大提升,恭喜

---

作者: Niel    時間: 2011-2-20 23:57



再寫多少少，假設我有一個25nm，3000 cycle NAND flash，4KB page size，512KB block size，40GiB，7% overprovisioning的SSD (with good controller)

就算OS drive一日有一個2KB的file被overwritten 200次，唔代表有一個 block每日被overwritten 200次 (1 block, 200 cycle)。

個overwritten 200次的2KB file實際只係用左:

4KB (2KB data, 4KB page size as in our SSD) x 200 = 800KB (未計controller data, ECC data, etc)

所以只係用左兩個不同的block，各一個cycle。而唔係同一個block，200 cycle...所以...



條數跟本唔係咁計，大家請注意。

---

作者: arimedir    時間: 2011-2-21 00:01




   
Altech 個網有V32

我隻f40 altech保, 保官網都無f40

---

作者: BA1314BA    時間: 2011-2-21 00:12

唔1tb ssd幾時可以$1000內呢?

---

作者: Niel    時間: 2011-2-21 00:18




比較好的controller今年120GB都應該唔可以1000內，1TB...都幾有排下

---

作者: rabi    時間: 2011-2-21 20:54

本帖最後由 rabi 於 2011-2-21 23:56 編輯

回復 47# Niel

多謝你的寶貴資料，但師兄你似乎太過高估 bast case 的 hit rate（發生機率），那就是你的這一句：

所以ssd controller會將updated file寫入新page，不會立即rewrite(甚至完全不會rewrite)，然後update LBA，成個過程file system係不會知道。

要發生你的 best case，controller 首要條件是具備有足夠的 cache 來作你說的「新 page」，可惜，一般 SSD 的 cache 來說都只得 64MB-128MB，而 OS 的 page file 動不動都超過 1GB，加上其他的系統檔、記錄檔、瀏覽記錄檔、嘜檔物檔…，你的 bast case，發生機會是無法多的，何來証明：「rabi的論點係完全不成立的…」？

再說，上述的 best case，如果 OS 唔知的話，就會很弊，究竟 SSD 的 controller 幾時先把 cache 的內容寫入？接到硬盤關機指令時？仰或是你覺得 SSD 懂得察覺「登出」動作？好攪笑喎！Windows 登出時就會把快取寫入硬盤，包括 USB 手指，你係咪將這個和 SSD controller 的內客運作程序混淆了？

上一代的 MLC 每個 cell 的寫入次數是 10000 次，如果製程改為 25nm 就退化變成 3000 次，咁，除非唔知，否則真係傻瓜才會買咯。

---

作者: Niel    時間: 2011-2-21 23:56



唔係best case，都唔係寫去cache，因為依個做法係完全不需要cache都可以做到。

將rewrite寫去其他available NAND page，而唔係overwritten the same page，依一個method係各大controller都有implement的。

---

作者: Niel    時間: 2011-2-22 00:08



"多謝你的寶貴資料，但師兄你似乎太過高估 bast case 的 hit rate（發生機率）"

1. 由於同cache無關係，所以不存在hit rate問題。就算SSD係full (full user available capacity)，modern SSD controller會用spare area去handle overwrite request。

"要發生你的 best case，controller 首要條件是具備有足夠的 cache 來作你說的「新 page」，可惜，一般 SSD 的 cache 來說都只得 64MB-128MB，而 OS 的 page file 動不動都超過 1GB，加上其他的系統檔、記錄檔、瀏覽記錄檔、嘜檔物檔…，你的 bast case，發生機會是無法多的，何來証明：「rabi的論點係完全不成立的…」？"

1. 由於同cache無關係，所以同cache size/flush cache無關係。
2. Page file read:write 比例係 40:1，SSD read係無限的。由於我之前已經解釋SSD係計actual committed data 而唔係計 overwritten左幾多次。所以唔係best case。

"再說，上述的 best case，如果 OS 唔知的話，就會很弊，究竟 SSD 的 controller 幾時先把 cache 的內容寫入？接到硬盤關機指令時？仰或是你覺得 SSD 懂得察覺「登出」動作？好攪笑喎！Windows 登出時就會把快取寫入硬盤，包括 USB 手指，你係咪將這個和 SSD controller 的內客運作程序混淆了？"

Windows shutdown時，ACPI係會send command去hardware device，所以SSD係懂得察覺關機/standby等等動作。

---

作者: rabi    時間: 2011-2-22 00:14

本帖最後由 rabi 於 2011-2-22 00:30 編輯

modern SSD controller會用spare area去handle overwrite request

spare area？有幾大？大到可以 hit rate 100% 所以無「發生機率」的問題嗎？那麼這個 area 理論上要大於或等於這個 SSD 盤的容量了，老老實實喇，你作的嗎？

MLC 最怕「常滿」，就是因為當無「spare area」時，寫入資料要先 erase 才可寫入。你似乎嚴重地誤解了一些事情。

正常覆寫檔案的程序：
1. 將檔案快速寫入 spare area
2. update FAT
3. 將舊檔案 delete
4. 執行 trim 指令，將 delete 的相關 cell，全部 earse，已 erase 的 cell 就是 spare area，而你說的 block，是一群 cell 而已

spare area 不足：
被迫先執行 erase 指令，將「寫入」這個動物 delay，造成「跌速」，會很嚴重的。

所以，用 SSD 架 OS 而唔用 SLC 的，真係好打有限。

---

作者: Niel    時間: 2011-2-22 00:29

我地可以簡單估計一下25nm的SSD可以用幾耐:

以Vertex 2E 60GB 25nm為例:

Basic conversion:
60GB = 55.87935448GiB
55.87935448GiBx 3k cycle = 163.7090TiB (3k係下限，大多數係3k-5k)

OP (Over-provisioning):
V2E有13% overprovisioning
163.7090TiB x (1+13%) = 184.9912TiB

WA (Write Amplification):
Anandtech指出SF-1200 controller在real life可以有大約0.6 WA
(source: http://www.anandtech.com/show/41 ... -first-sf2500-ssd/2 )
388.5361TiB/0.6 = 308.3187TiB

當你係heavy user，一日寫20G data去OS drive:
308.3187 x 1024 / 20 = 43.249 years

我當Anandtech吹水，SandForce又講大話，所以成條數除2... = 21.6245 years...

---

作者: rabi    時間: 2011-2-22 00:40

本帖最後由 rabi 於 2011-2-22 00:46 編輯

回復 55# Niel

你知不知一文書部機，一般是 2GB RAM，只是簡簡單單的開 word、excel、IE、和 outlook，秘書小姐連續操作了四小時，系統總共「寫入」多少 data？

heavy user 一日寫入 data 是 20GB？你聽那個說的？條數究竟點計？你真的相信 page file 的 update 次數是個位數？

條數可能是咁計的：
就當 MLC 寫入次數是 3000 次，一隻 60GB 的 MLC 的寫入壽命為 60GB x 3000 = 180000GB，表示當用戶的寫入數據接近或超越這個數，這個 SSD 的 cell 理論上全部失效，如果 spare area 來來去去都是同一區，這個部份就先死，一隻 spare area 已死（或死一半）的 MLC，嚴重跌速，唔死都無用喇，強如 intel controller，空有十通道都無補於是喇…

比較一下 MLC 和 SLC 的價錢和性能，你還會說 MLC 低買嗎？

---

作者: lagfix    時間: 2011-2-22 00:51

ching可以貼個測試圖嗎?

---

作者: 167pk    時間: 2011-2-22 01:03

提示: 作者被禁止或刪除 內容自動屏蔽

---

作者: Niel    時間: 2011-2-22 01:03



...
為左令你明白，我地又做一個簡單計算:

又用V2E 60G做例，spare area有7.26GiB。
係話spare area可以滿，所以再不能作"正常覆寫檔案的程序"，所以其實你係講緊不停overwrite some files令7.26GiB滿左，之後controller又一直不commit TRIM command (or internal GC)，等7.26GiB用曬先做。

以OS drive來說:
1. SSD係唔會等用曬spare area先commit TRIM/ GC
2. 我當controller完全唔做野，用曬先做，不過以SF-1200為例block recycler都有70MBps。

不過你的例子係有可能發生，不過唔係一隻OS drive，而係你不停overwrite random data，不過你唔會不停寫random data去OS drive掛....

---

作者: 167pk    時間: 2011-2-22 01:06

提示: 作者被禁止或刪除 內容自動屏蔽

---

作者: Niel    時間: 2011-2-22 01:18




我只可以講，你個秘書小姐好做得野，唔好炒佢...佢可以日日四個hour做到20GiB...1.42MBps

Anand都係7.7GB per day:
"The worst write amplification we saw was around 0.6x. Actually, most of the drives we've deployed in house came in at 0.6x. In this particular drive the user (who happened to be me) wrote 1900GB to the drive (roughly 7.7GB per day over 8 months) and the SF-1200 controller in turn threw away 800GB and only wrote 1100GB to the flash. This includes garbage collection and all of the internal management stuff the controller does."

仲有1: 你個計法係omit左spare area，2: spare area係dynamic唔會"來來去去都是同一區"

...唉

---

作者: Niel    時間: 2011-2-22 01:19



無錯，所以唔通d生產商及代理自己玩自己...

---

作者: rabi    時間: 2011-2-22 01:34

回復 59# Niel

我嘔血了，…

我話你知不停寫入大量 data 的正正就是 OS，你就話 OS 唔會，還把那些 trim 的 basic principle 拿出來故弄玄虛，你當我 lulu？

就算我一日將整隻 60GB 完全覆寫三次，都要需時十年，才平均將每個 cell 寫入 1 萬次，拿來 BT 和用作 OS 的做法係好唔同的，OS 有系統檔，64bit Win7 裝埋 office 已用了接近 30GB，你隻 MLC 係唔係用來用去都是拿餘下的 30GB 做 spare area 呀？係就對了，這 30GB 的區塊咪快速老化囉。

然而，你說的「spare area」會唔會係那個隱藏的小區？那是用作不時之需的，唔會大得去邊，忘記它算吧啦。

---

作者: rabi    時間: 2011-2-22 01:39

給你看看 Win7 在做甚麼：

[attach]1140665[/attach]

我的 page file 已經 set 到好細，256MB，你看看有幾個寫入動作吧！

這是 windows 7 的資源監視器，你自已也可以開來看看。

---

作者: rabi    時間: 2011-2-22 01:42



有圖有真相，你去睇睇自已部機先啦。

---

作者: Niel    時間: 2011-2-22 02:44

本帖最後由 Niel 於 2011-2-22 03:11 編輯


...你又錯了...

"64bit Win7 裝埋 office 已用了接近 30GB，你隻 MLC 係唔係用來用去都是拿餘下的 30GB 做 spare area 呀？係就對了，這 30GB 的區塊咪快速老化囉。"

controller係會做block rotation...所以你果句"你隻 MLC 係唔係用來用去都是拿餘下的 30GB 做 spare area 呀？係就對了，這 30GB 的區塊咪快速老化囉。" 又係全錯...

"然而，你說的「spare area」會唔會係那個隱藏的小區？" 你又錯了...Spare area成13% (Vertex 2E)...

"那是用作不時之需的，唔會大得去邊，忘記它算吧啦。"...again...你又錯了...那不是用作不時之需的...controller係時時都用盡所有space做wear leveling，block rotation，garbage collection等等，可能你用開JM 咁就難講d...

你睇返之前你打d野大部份都係錯...仲話其他人lulu??...

---

作者: Niel    時間: 2011-2-22 03:02



好大個Byte per second...

果然係有圖有真相

---

作者: rabi    時間: 2011-2-22 03:47

本帖最後由 rabi 於 2011-2-22 03:56 編輯

噢，我錯，高估了 Niel 師兄的智商，找一個會加總的程式讓你看得更明白…

這部機 2GB RAM，開一開 Office Excel、Acrobat、IE、Outlook、小畫家，沒有開啟任何檔案下，用 IE 上網 6 分鐘，錄得寫入數據超過 300MB：

[attach]1140694[/attach]

實際使用環境下，必定會開啟檔案，造成寫入更多 pagefile、log file、temp file…

Windows update 果 D 大量寫入都唔想計喇，粉多的！

Config：
eeePC901 with 2GB ram
16GB SLC （多得它，無視 C: 常滿的問題，工作一整年不掉速，7x24）
Windows7 Ultimate 16bit

（Pagefile was set to 256MB，default 的話，2GB 起，唔好話唔公平）

---

作者: Niel    時間: 2011-2-22 03:56

本帖最後由 Niel 於 2011-2-22 03:57 編輯


deleted

---

作者: rabi    時間: 2011-2-22 03:58

本帖最後由 rabi 於 2011-2-22 04:02 編輯

回復 69# Niel

係呀，All disk 呀，都係一隻呀。

我唔用 MLC 的，那隻爛鬼 8GB 拆了，你還要撐到幾時？看到真相了無？

---

作者: Niel    時間: 2011-2-22 04:01

本帖最後由 Niel 於 2011-2-22 04:05 編輯


唔怪得啦，你用第一代MLC controller...根本果代d controller好似一隻multichannel的usb thumb drive咁...

我撐咩? 隻MLC仲有好長命。如果你話我講的東西都係撐，咁請你睇下之前你講d野...錯到...

之前你用windows個resource monitor，依加要用hdtune...大家都明...

---

作者: rabi    時間: 2011-2-22 04:07

本帖最後由 rabi 於 2011-2-22 04:09 編輯


好一招「亂扣帽子」：

仲話其他人lulu??..

第一，我重申，我唔用 MLC 的；第二，我在這個帖，無話過邊個邊個 lulu。賣弄那麼多 basic principle，你係咪當我 lulu？

---

作者: Niel    時間: 2011-2-22 04:15

本帖最後由 Niel 於 2011-2-22 04:18 編輯


"我唔用 MLC 的，那隻爛鬼 8GB 拆了" << what's that? 我中文差? 你咁打唔係講緊你之前用MLC? 我諗你之前隻MLC由於係第一代，好廢，所以唔再用，而且對MLC印象唔好。

誰在賣弄，誰對SSD根本連 basic principle 都錯...不用說了。

我亂扣帽子?你之前無話人lulu?
http://www.hkepc.com/forum/viewt ... 5196&highlight=

哈哈。算了吧。

---

作者: rabi    時間: 2011-2-22 04:21

哦，原來玩針對的，好了好了，我承認我錯了，看到這些理論，應該早點去睡，唔應該太認真的，Please forgive me：

#43 所以計SSD壽命唔係計覆寫次數，係計total written data。

偉論，配服，配服。

---

作者: rabi    時間: 2011-2-22 04:29



部 901 一買返來，我就拆了那張原裝 8GB MLC 了，事實上我真係無用過喎，你唔清唔楚，係度含血噴人。

你係要對號入座屈我話人 lulu 你咪認飽佢囉，不過你唔配這個稱號，無懶比較適合你。

---

作者: rabi    時間: 2011-2-22 04:30

本帖最後由 rabi 於 2011-2-22 04:31 編輯

double delete...

---

作者: rabi    時間: 2011-2-22 04:30

本帖最後由 rabi 於 2011-2-22 04:31 編輯

double delete...

---

作者: rabi    時間: 2011-2-22 04:30

本帖最後由 rabi 於 2011-2-22 04:31 編輯

double delete...

---

作者: rabi    時間: 2011-2-22 04:30

本帖最後由 rabi 於 2011-2-22 04:31 編輯

double delete...

---

作者: Niel    時間: 2011-2-22 04:33



你誤會了，不是針對人，是針對錯的basic principle。

"#43 所以計SSD壽命唔係計覆寫次數，係計total written data。" << 依一句係對的，不是甚麼偉論。

---

作者: Niel    時間: 2011-2-22 04:38




如果我誤會了你，我先道個歉。

不過我一直回應你，都是希望你更了解現時SSD的做法，不是針對你個人。

---

作者: Niel    時間: 2011-2-22 06:00



之前你張resource monitor的單位是byte，所以不論我智商如何，紅圈加總就只有19.94kibps，當然你可以說有部份data未scroll出黎。

所以我再test一次。

好抱歉，hdtune detect唔到我隻Vertex 2的activity，所以用唔到同你一樣的方法去test。

[attach]1140697[/attach]

所以我用更準確的方法去收集data。我用了一小時去平常地使用自己的電腦，盡量用和你一樣的軟件，e.g. MSWord打report，上網(cache已set回C Drive)，chrome，uTorrent(destination係普通HDD)。

[attach]1140698[/attach]


一小時內的average只有110,260.801 bytes per second。即一小時只寫入了378.55MiB，由於沒有甚麼heavy browsing (看了動新聞，一些hardware網，及google search一些research paper)及打打report，所以可算是文書工作。

如果每日做12小時，當一小時寫入了600MiB，一天只是7GiB。所以唔係好明白你位秘書小姐如何做野做到write 1.42MBps...




我估佢可能有職業病，一秒save一次個report，怕唔見data...又可能佢同你一樣，b野落SSD...




之前的所有解釋，希望你能明白吧，現時的controller (e.g. Intel, SandForce) 都設計得很好了。

---

作者: kelvinkkkkkk    時間: 2011-2-22 09:30

唔怪得個ＰＯ咁長啦Ｔ．Ｔ　Ａ＿Ａ都係等我存到錢都選擇ＭＬＣ／ＳＬＣ吧～～　

---

作者: 絕望之黑暗    時間: 2011-2-22 19:49

事實是我ssd 快死,而且是水貨無保..........q.q