[SSD] Kingston SSDnow V Series 40GB - dziwne anomalia

[12 0]

Zachęcony recenzjami http://pclab.pl/art39124.html jak i samą specyfikacją nabyłem ten napęd celem używania go na "Projekt" (aktualnie 450 tyś plików o łącznej objętości 13GB). W związku z tym, że czasy dostępu w SSD są małe, to obsługa tysięcy małych plików powinna być o wiele szybsza niż w tradycyjnym (powiedzmy, bo porównujemy do SASa 15k rpm) dysku HDD. Przerzuciłem więc "projekt" na SSD i poczyniłem testy proktyczne. Okazało się, że "Projekt" otwiera się tylko niewiele szybciej (jakieś 25%) w porównaniu do HDD, a zapisuje nieznacznie wolniej. Ponieważ wogóle nie pasuje to do teorii działania SSD uruchomiłem kilka testów syntetycznych i odkryłem pewne dziwne zachowania napędu.

 

Tak wygląda test ciągłego odczytu w HDtune po skopiowaniu na SSD "projektu".

Widać, że w obszarze tych 13GB odczyt jest strasznie poszarpany. Robiłem testy wielokrotnie, po restarcie komputera i wykres zawsze był identyczny.

No to dokopiowałem jeszcze z 1GB fragment "Projektu" - poszarpanie wydłużyło się odpowiednio. Następnie przerzuciłem 8GB pojedynczy plik. Poszarpania nie przybyło. No to znów dokopiowałem 1GB "Projektu". Poszarpanie pojawiło się w oczekiwanym miejscu (bliżej końca wykresu).

W tym momencie wnioski były już oczywise. Teraz ptanie czy da się to jakoś naprawić?

Skasowałem "Projekt", poszarpanie nie ustąpiły. Pozostał już tylko Format (ale taki sektor po sektorze). Więc do dzieła. Po około 20% dałem anuluj, żeby zobaczyć efekty.

Były zgodne z oczekiwaniami. Poszarpania naprawiły się w obszarze, który zdążył się sformatować.

Tyle testów - teraz wnioski.

Wydaje mi się, że Intel próbując poprawić trwałość coś pokombinował, że w czasie zapisu małych plików nie jest kasowany cały blok we Flashu (4096 bajtów) tylko jakoś sprytnie podmieniane tylko te bity co trzeba. Jednak takie podmienione bity są słabsze i przez to zwalniają odczyt (np: dochodzi korekcja). Dopiero format (czyli kasowanie bloków NAND) powoduje przywrócenie szybkigo odczytu (bez korekcji?).

Wogóle sprawa jest chyba rozwojowa bo dotyczy nowego wadliwego firmware, które to mam w napędzie (02HA). Firmware ten miał poprawić parametry i coś tam poprawił, ale chyba bardzie zepsuł, dyski zaczęły padać i chyba obecnie jest zdjęty ze strony Intela. Tu prosiłbym uzytkowników bądź nowych Kingstonów serii V 40GB lub Inteli serii M z firmware 02G2 lub 02G9, by przeprowadzili testy zapisu małych plików (kilka GB plików po kilkaset bajtów) i sprawdzili czy nie pogorszyły się parametry odczytu (poszarpania). W recenzji brał udział napęd z firmware 02G9. Może ktoś z redakcji ma jeszcze ten recenzowany napęd?

Tak czy inaczej owo zjawisko powoduje, że taki napęd SSD nie nadaje się do zastosowań w których teoretycznie jest najlepszy (krótkie czasy dostępu to szybszy odczyt dużej ilości małych plików).

Na koniec dodam, że mam inny napęd SSD (prawie roczny Transcend) i nie zauważyłem u niego takich anomalii. "Projekt" czytał się kilkakrotnie szybciej niż z HDD, niestety zapisy go "deklasowały" w tym zastosowaniu (JMicron). Nawet po roku użytkowania wykres odczytu nie wykazuje żadnych poszarpań.

 

Coś z tymi Intelami M (Kingstonami V 40GB) jest nie tak (lub z tym firmware)......

[dendrytus 0]

Jaki system i czy włączone AHCI?

[12 0]

AHCI nie ma tu nic do gadania (no może jeżeli chodzi o upgrade firmware, ale ja już miałem ten nowy). Napęd był podłączany do ICH10 (AHCI), do kontrolera SAS Marvell i do kontrolera Intela SRCSASBB8I i chyba do Adapteca też podłączałem. Vista x64.

[dendrytus 0]

U mnie TorqX po włączeniu AHCI na win7 wyraźnie przyspieszył.

Vista nie najlepiej sobie radzi z SSD. Wyłączyłeś defragmentację, superfetch i ReadyBoost?

http://blogs.msdn.com/e7/archive/2009/05/0...drives-and.aspx

Co prawda to dotyczy win7, ale można z tego skorzystać.

[12 0]

No tak, ale tu chodzi o skan powierzchni - ciągły odczyt. Po zapisaniu małych plików są potężne spadki odczytu w miejscach gdzie są te pliki. I można test powtarzać kilka razy i jest identycznie. Dopiero po formacie (dokładnym a nie szybkim) skan wraca do normy. Wychodzi na to że zapis małymi porcjami odbywa się w nietypowy sposób i upośledza bloki NAND we Flashu.

Wszystkie umilacze mam powyłączane.

Czekam na nowy firmware, a i może się ktoś ze starszym firmware odezwie, jak jest u niego. Może warto zrobić downgrade?

[=-Mav-= 2]

Bardzo dziwna sprawa, ja bym się zdenerwował gdyby mi nowy ssd taki numer wyciął. Pisz do supportu. No i jednak trzeba było się zdecydować na "pełnego" intela, nie tego kastrata od kingstona, jeśli już chodzi o poważną pracę.

[kresek 0]

cóż:

 

http://anandtech.com/showdoc.aspx?i=3631&p=10

 

wyniki i tak powinny być lepsze, niż na tradycyjnych dyskach - i z tego co piszesz - są.

 

jak wygląda dostęp do tych danych? może dużo dawał tu cache OS...

 

zresztą, niezły z Ciebie abuser systemu plików - kilkaset tysięcy sztuk, średnio po ~30 bajtów. nie dało się tego zapisać jakoś inaczej? nie dość, że potencjalnie dysk dostaje po tyłku, to szczerze mi szkoda systemu operacyjnego, który musi to ciągnąć...

[zawadaki 0]

ten wynik jest poprawny jak na NIE pusty SSD taki urok SSD większość testów na potrzeby recenzji jest robione na pustych dyskach wiec jak ktoś zrobi test po wgraniu danych przeżywa szok

 

test w ATTO lub innym programie wykaże ze wszystko jest OK z wydajnością

[12 0]

Bardzo dziwna sprawa, ja bym się zdenerwował gdyby mi nowy ssd taki numer wyciął. Pisz do supportu. No i jednak trzeba było się zdecydować na "pełnego" intela, nie tego kastrata od kingstona, jeśli już chodzi o poważną pracę.

To jest Intel z nalepką Kingstona. Mniejsza pojemność nie usprawiedliwia poszarpanego wykresu wydajności.

 

zresztą, niezły z Ciebie abuser systemu plików - kilkaset tysięcy sztuk, średnio po ~30 bajtów. nie dało się tego zapisać jakoś inaczej? nie dość, że potencjalnie dysk dostaje po tyłku, to szczerze mi szkoda systemu operacyjnego, który musi to ciągnąć...

Nie jest tak źle, wychodzi średnio po 28k na plik. Tak działa program, którego używam - każde kliknięcie myszy lub klawiatury jest zapamiętywane. "Projekt" ma charakter bazodanowy, przy czym ma tendencje do kreowania malutkich plików. Można to porządkować i pliki się scalają, ale porządkowanie "Projektu" to jakaś godzinka z głowy i pewne ryzyko (program każe wcześniej zrobić kopię) - dlatego robię to rzadko. Normalnie "projekt" siedzi na SASie Fujitsu (15k rpm), siedzi na nim też stary "projekt, który liczy sobie 1.270.000 plików. Może jeszcze dzisiaj przeprowadzę test i przerzucę "projekt" na RAID0 z trzech takich SASów.

 

ten wynik jest poprawny jak na NIE pusty SSD taki urok SSD większość testów na potrzeby recenzji jest robione na pustych dyskach wiec jak ktoś zrobi test po wgraniu danych przeżywa szok

 

test w ATTO lub innym programie wykaże ze wszystko jest OK z wydajnością

Otóż nie, zarówno HDtune, Everest jak i HDTach pokazują poszarpania w tym konkretnym obszarze. A Atto to w zasadzie tester cache i ogólnikowe wyniki.

[zawadaki 0]

....

Otóż nie, zarówno HDtune, Everest jak i HDTach pokazują poszarpania w tym konkretnym obszarze. A Atto to w zasadzie tester cache i ogólnikowe wyniki.

 

no proszę specjalista się znalazł ATTO jest akurat najlepszym programem do testowania wydajności odczyty i zapisu danych na dysku SSD żadna aplikacja nie działa sam ale w połączeniu z systemem sterownikiem i pamięcią cache.

Liczy się efekt końcowy czyli jak szybko program procujący w jakimś systemie może dane odczytać lub zapisać

 

HDtune, Everest itd.... to w zasadzie te same programu co do zasady działania, żaden się nie nadaje bo zostały napisane do testowania HDD a nie SDD

[kresek 0]

Nie jest tak źle, wychodzi średnio po 28k na plik.

no tak, rąbnąłem się o mało znaczące trzy rzędy wielkości

 

mój Kingston reaguje tak samo - na obszarach "używanych" są analogiczne spadki.

[12 0]

Skoro jest najlepszy to czemu pokazuje że z wydajnością jest OK, skoro nie jest OK?

[zawadaki 0]

Skoro jest najlepszy to czemu pokazuje że z wydajnością jest OK, skoro nie jest OK?

przecież jest OK, podczas odczytu system się zacina kopiowanie plików zajmuje więcej czasu system uruchamia się godzinami skąd wiesz ze nie jest OK

 

spójrz sobie na mojego w pełni OK Vertex-a

 

poszukaj sobie w sieci wyników innych użytkowników będą podobne o ile dysk nie jest pusty

[=-Mav-= 2]

To jest Intel z nalepką Kingstona. Mniejsza pojemność nie usprawiedliwia poszarpanego wykresu wydajności.

Wiem doskonale że to intel, tyle że obcięty. Dlatego piszę, że lepiej było jednak kupić pełnego x25-m zamiast tego kastrata.

[12 0]

przecież jest OK, podczas odczytu system się zacina kopiowanie plików zajmuje więcej czasu system uruchamia się godzinami skąd wiesz ze nie jest OK

 

spójrz sobie na mojego w pełni OK Vertex-a

 

poszukaj sobie w sieci wyników innych użytkowników będą podobne o ile dysk nie jest pusty

Heheh, no dobra, jeżeli takie coś jest OK to ja też mam OK

Nawet gdybym przebolał to, że nie przyspieszyło mi to operacji, na które liczyłem najbardziej to co powiesz na to:

 

Napęd Transcend 32GB. Był na nim "projekt" i odczyt "projektu" przyprawiał mnie o opad szczeny - no z 5 razy szybciej działało niż z HDD. Niestety zapisy to była porażka bo to napęd na Jmicronie bez cache.

Musiałem wrócić do HDD, a Transcend poszedł do desktopa gdzie służy do dzisiaj. Nie robiłem mu żadnego formatowania, trimowania i wykres odczytu jaki miał po zakupie taki ma teraz. Wydaje mi się, że Transcendzik robi tryma na żywca, jak ma zapisać jakiś blok, to go najpierw formatuje (przywracając początkową sprawność), potem zapisuje, stąd zapisy wolne ale nie mamy utraty wydajności przy odczycie. Teraz odnośnie nowych napędów: chyba bym wolał, żeby działały na tej samej zasadzie co ten prawie roczny Transcend. Cache napędu i tak by przyspieszył zapisy, a przynajmniej nie byłoby spadków na odczycie.

 

Wiem doskonale że to intel, tyle że obcięty. Dlatego piszę, że lepiej było jednak kupić pełnego x25-m zamiast tego kastrata.

Ale co by to zmieniło? "Pełne" intele mają takie same spadki po zapisie.....

 

Jeszcze wykonam jeden test. Zgram dysk na którym jest "projekt" w Ghoście i odtworzę obraz na Kingstonie - nie powinno to zmęczyć komórek (będzie to jak zapis pojedynczego dużego pliku), zobaczę co wtedy. Jak się nie powiedzie to przenoszę "projekt" na zestawik na którym miałem do tej pory system, czyli 3x Fujitsu SAS 36GB 15k rpm (prawie trzy razy szybciej bangla), a system pójdzie na 4x HITACHI SAS 74GB 10k rpm 2,5"(właściwie to już jest - wersja próbna stanie się podstawową). Za rok się znów zrobi przegląd rynku...

[=-Mav-= 2]

Ale co by to zmieniło? "Pełne" intele mają takie same spadki po zapisie.....

Mają jednak wiecej kanałów w kontrolerze, więc byłoby szybciej.

 

 

A już przy zapisie to nie ma porównania:

 

 

http://anandtech.com/printarticle.aspx?i=3667

[kain 31]

Wielkie dzieki za ten temat. Planowalem kupic SSD pod identyczne zastosowanie, ale wychodzi na to ze faktycznie jeszcze nie warto. Zaskoczony jestem mocno nie ukrywam.

[12 0]

Mają jednak wiecej kanałów w kontrolerze, więc byłoby szybciej

2MB pliki?, nie żartuj kolego, na "Projekt" składają się pliki o przeciętnej wielkości 0,5-4kB. Przy tej wielkości różnice między Intelem a Kingstonem się zacierają, dlatego zdecydowałem się na tańszego Kingstona. Przy takiej wielkości plików trudno osiągnąć prędkość kopiowania większą jak 15-20MB/sec. SASowy Fujitsu robi to ze średnią prędkością 9MB/sec.

[=-Mav-= 2]

No więc wygląda na to, że wyrzuciłeś pieniądze w błoto.

[12 0]

No więc wygląda na to, że wyrzuciłeś pieniądze w błoto.

Na to wygląda....

[Bono[UG] 1916]

Jak masz czas i chęć, to sprawdź jak będzie chodziło po zmianie offsetu pierwszej partycji na 64 lub 128 sektorów (diskpar).

[12 0]

Więc wykonałem jeszcze operację "SuperTrim" i do pewnego stopnia poszło zgodnie z planem. Ale od początku. Wydzieliłam na jakimś dysku partycję 40GB. Przekopiowałem tam pliki "Projektu". Następnie Hexedytorem zgrałem tą partycję sektor po sektorze do pliku...

Następnie sformatowałem Kingstona jeszcze raz co by miał równiejszy wykres. Test HDTunem i jest gładko. Następnie powrót do Hexedytora i restore sektorów z pliku na Kingstona. Po kilkunastu minutach miałem kopię dysku "Projekt" na Kingstonie, a jednocześnie niezmęczone komórki - wszak zapis szedł tak jakby to leciał jeden duży plik:

Można porównać z wykresem na początku tego topicu.

Więc przyszła pora na test praktyczny. Uruchamiam program i wczytuję projekt. Tak na oko to podobnie lub niewiele szybciej. Test zapisu i tu copy-paste sceny (144 pliki, 22MB) dwa razy dłużej niż na HDD. No i zagadka - czemu tak wolno? Czyżby MLC nie nadwało się do poważniejszych zastosowań? Albo ograniczeniem jest w pewnym stopniu system? Tu jeszcze wykonam inny test, zamontuję 16GB ramdisk i przerzucę tam projekt - to będzie chyba ostateczny sprawdzian o ile da się przyszpieszyć działanie "Projektu".

Ktoś spostrzegawczy zauważy, że właściwie to wyniki SSD się pogorszyły, ale to tylko dlatego, że w międzyczasie zrobiłem defragmentację dysku HDD z "Projektem" - kilka godzin zajęło (wszak ponad 2mln plików w sumie). Póki co plan B jest wciąż aktualny - RAID 0 z trzech dysków SAS Fujitsu 36GB 15k rpm, aktualnie "Projekt" siedzi na jednym SASie Fujitsu 73GB.

 

Na powyższym przykładzie widać, jak system NTFS jest archaiczny. Wystarczyłoby aby filesystem "spojrzał w przyszłość" choćby na 4096 bajtów i nie zapisywał bezmyślnie kolejno kilkuset bajtowych plików pojedynczo tylko "scalił w myślach" kilka kolejnych plików przeznaczonych do zapisu i wykonał jeden zapis od razu całego bloku. No ale... chyba za dużo wymagam....

 

A ten offset to kiedyś zmieniałem i w benchmarkach nie było widać różnicy, w praktyce może coś by to dało, jak znajdę chwilę to przetestuję praktycznie.

[=-Mav-= 2]

Wystarczyłoby aby filesystem "spojrzał w przyszłość" choćby na 4096 bajtów i nie zapisywał bezmyślnie kolejno kilkuset bajtowych plików pojedynczo tylko "scalił w myślach" kilka kolejnych plików przeznaczonych do zapisu i wykonał jeden zapis od razu całego bloku. No ale... chyba za dużo wymagam....

System plików nie wróżka, robi co mu się każe. Takiego czegoś można wymagać co najwyżej od kontrolera dysków i jego oprogramowania, było nie było ma te kilkadziesiąt mb pamięci podręcznej. Więc pretensje raczej do producenta dysków.

[Bono[UG] 1916]

A ten offset to kiedyś zmieniałem i w benchmarkach nie było widać różnicy, w praktyce może coś by to dało, jak znajdę chwilę to przetestuję praktycznie.

Na moich dyskach twardych i pendrive w testach wychodziło nawet trochę wolniej, ale kopiowanie małych plików szło sprawniej.

Możesz też kombinować z wielkością jednostek alokacji, tak żeby zgadzała się z blokami na SSD.

[12 0]

System plików nie wróżka, robi co mu się każe. Takiego czegoś można wymagać co najwyżej od kontrolera dysków i jego oprogramowania, było nie było ma te kilkadziesiąt mb pamięci podręcznej. Więc pretensje raczej do producenta dysków.

Miałoby to być takie NCQ, tylko że dla zapisu, nie widzę w tym nic z wróżbiarstwa. Czy trzeba wiedzy tajemnej systemowi aby zrobił sobie listę plików jakie stoją do zapisu i zapisywał je blokami? Na pewno nie jest to zadanie dla cache w dysku twardym, co najwyżej w kontrolerze, ale chyba łatwiej zrobić implementacje w systemie polików niż w każdym z wielu rodzajów kontrolerów? Ponadto większość użytkowników nie ma kontrolera z cachem. Tak czy inaczej nie ja pierwszy uważam, że NTFS to archaizm i już dawno powinno być coś nowego.

 

Na moich dyskach twardych i pendrive w testach wychodziło nawet trochę wolniej, ale kopiowanie małych plików szło sprawniej.

Możesz też kombinować z wielkością jednostek alokacji, tak żeby zgadzała się z blokami na SSD.

Domyślna jednostka alokacji jest akurat zgodna z wielkością bloku SSD. Ale z tym sektorem 64 to chyba chodziło w wydłużenie żywotności. Natomiast wygląda na to, że zapis w systemie NTFS jest niezoptymalizowany i szczególnie wychodzi to w przypadku SSD.