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

[zawadaki 0]

z testów wynika ze ten SSD Kingstona ma bardzo niską prędkość zapisu, wiec czego się spodziewasz po kopiowaniu będzie tyle co przy zapisie jeśli nie mniej

 

PS. HDD jest najszybszy podczas zapisu SSD jest najszybszy podczas odczytu

[12 0]

z testów wynika ze ten SSD Kingstona ma bardzo niską prędkość zapisu, wiec czego się spodziewasz po kopiowaniu będzie tyle co przy zapisie jeśli nie mniej

 

PS. HDD jest najszybszy podczas zapisu SSD jest najszybszy podczas odczytu

W przypadku małych plików prędkość zapisu nie ma znaczenia (ma, ale małe). Mówimy tu o sytuacji, kiedy wyszukiwanie pliku trwa dłużej niż jego obsługa (czyli wszystko zależy od czasu dostępu). Pliki "Projektu" typowy dysk twardy kopiuje ze średnią prędkością 5MB/sec, dysk SAS 15k rpm robi to dwa razy szybciej. Niechby SSD robił to jeszcze dwa razy szybciej (20MB/sec) to jeszcze miałby podwójny zapas jeżeli chodzi o prędkość zapisu (dla tego Kingstona to ok. 40MB/sec).

Dziwne jest to, że ten Kingston mający procesor Intela z cachem zachowuje się podobnie jak roczny napęd Transcenda na Jmicronie bez cache, a nawet jeszcze gorzej, bo osłabia wydajność komórek podczas zapisu małych plików, czego Transcend nie robił. Zastanawiam się, bo Intel coś kombinuje z firmware, może tu jest problem. A może te pamięci 34nm są gorsze niż te wcześniejsze - trudno określić na tą chwilę. Niedługo ma wyjść nowy firmware - zobaczymy co się zmieni.

[Firekage 1]

Czyżby MLC nie nadwało się do poważniejszych zastosowań?

Zaleta MLC jest cena do pojemnosci, wada zas to co wyszlo Ci w testach - zapis, malo trgo : przy zapisie czesto moga pojawiac sie bledy przez co trzeba lepszej mechniki korekcyjnej przy takich dyskach. Do takich zastosowan przeznaczone sa pamieci SLC.

[=-Mav-= 2]

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?

Ty chyba nie bardzo wiesz o czym piszesz. NCQ nie ma nic wspólnego z systemem plików. Musi to obsługiwać kontroler dysku i sam dysk, system plików nie ma tu zupełnie nic do gadania.

 

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?

Po pierwsze: jest to jak najbardziej zadanie dla keszu w dysku twardym i układu który go kontroluje, bo może on zoptymalizować sposób w jaki zapisywane są dane. Dyski SSD intela są w tym obecnie najlepsze, tj najszybciej zapisują małe pliki, tylko mają stosunkowo niewielką ciągłą prędkość zapisu dla dużych plików.

 

A po drugie takie grzebanie w systemie plików może prowadzić do niekompatybilności ze starszymi urządzeniami/softem, no i łączy się z większą ilością keszowania, czyli i wzrasta ryzyko utraty danych. W każdym razie gdyby to było takie hop siup to już na pewno by to ktoś zrobił.

 

Tak czy inaczej nie ja pierwszy uważam, że NTFS to archaizm i już dawno powinno być coś nowego.

To poszukaj testów pod linuxowskim reiserem czy ext3 i wrzuć tutaj, z chęcią sam się przekonam czy będą o wiele lepsze.

 

http://www.linux-mag.com/id/7345/2/ - to wygląda ciekawie.

[12 0]

Ty chyba nie bardzo wiesz o czym piszesz. NCQ nie ma nic wspólnego z systemem plików.

Chyba nie bardzo wiem.... Może objaśnisz jak działa NCQ? I jeszcze wyjaśnij czym się różni NCQ od technologii, w której zamiast 8 zapisów po 512 bajtów (8 plików po 0-512) bajtów do sąsiednich sektorów, system plików dokona scalenia i puści jeden zapis 4096 bajtów, a sobie zaznaczy, że to było 8 plików osadzonych w kolejnych sektorach (filesystem widzi dysk sektorowo i z góry wie w które sektory trafią dane, bo w końcu to właśnie on ustala)?

 

Po pierwsze: jest to jak najbardziej zadanie dla keszu w dysku twardym i układu który go kontroluje

Właśnie nie. Po co kontroler ma tracić czas i moc swojego procesora na rozpracowywanie danych do zapisu (śledzenie do jakich idą sektorów i czy są to sektory kolejne i w jakiej ilości), skoro filesystem wie to jeszcze przed operacją i nic nie stoi na przeszkodzie aby on sam scalił odpowiednie pliki w bloki?

Dla kontrolera będzie to przewidywanie, filesystem to po prostu wie (bo sam przed chwilą ustalił jakie dane idą do jakich sektorów).

 

bo może on zoptymalizować sposób w jaki zapisywane są dane. Dyski SSD intela są w tym obecnie najlepsze, tj najszybciej zapisują małe pliki, tylko mają stosunkowo niewielką ciągłą prędkość zapisu dla dużych plików.

Nie wiem jak mam to rozumieć, bo w moich testach wyszło coś zupełnie odwrotnego. Zapis małych plików jest powolny i męczy (czy jak to nazwać) komórki. Porównywałeś screeny pierwszy i ostatni jakie wkleiłem. W obu przypadkach jest wgrana do napędu ta sama zawartość, ale:

- za pierwszym razem - za pośrednictwem systemu plików czyli kopiuj katalog

- za drugim razem poprzez zrzut sektorów HDD do pliku i restore na napędzie SSD

Jak na razie ta optymalizacja Intela skutkuje tym, że musieli w pośpiechu zjemować firmware ze strony internetowej.

 

A po drugie takie grzebanie w systemie plików może prowadzić do niekompatybilności ze starszymi urządzeniami/softem, no i łączy się z większą ilością keszowania, czyli i wzrasta ryzyko utraty danych. W każdym razie gdyby to było takie hop siup to już na pewno by to ktoś zrobił.

No jasne, że żadna modyfikacja - czas na całkiem nowy system plików. Keszowania nie trzeba aż tak dużo. Niech czas "przewidywania" będzie ustalony na 100-200ms - to wystarczy aby złapać kilka małych plików i je puścić jako jeden blok, jednocześnie nie będzie to uciążliwe opóżnienie dla dużych plików. Jednak ostatecznie wystarczy kontrola "na żywca" - moc obecnych procesorów jest wystarczająca na takie sztuczki.

Nie wiem czy hop czy siup, ale nie takie rzeczy ludzie robili, a ponieważ wdrożenie systemu plików zależy od producenta systemów operacyjnych to w zasadzie wszyscy jesteśmy skazani na producenta, a temu jak zwykle się nie śpieszy. Microsoft już od kilku lat bąka o nowym systemie plików, ale oni ledwo znajdują czas na łatanie dziur w zabezpieczeniach.

 

To poszukaj testów pod linuxowskim reiserem czy ext3 i wrzuć tutaj, z chęcią sam się przekonam czy będą o wiele lepsze.

Szczerze powiem, szkoda mi na to czasu. Są ludzie, którzy za taką pracę biorą wynagrodzenie i to ich broszka, żeby zrobić lepiej.

Te 15 minut, które straciłem na odpowiedź lepiej bym przeznaczył na szybsze ukończenie pracy i wyjście z dzieciakami na spacer (w dzień).

 

Co mnie interesowało już sprawdziłem i odpowiednio zaplanowałem upgrade maszyny na następny rok prac. A po sygnaturce widać, że na STORAGE kładę szczególny nacisk. Jeden tylko mi się nasuwa wniosek, niektórzy ludzie(firmy) dają ciała na tym polu.

[=-Mav-= 2]

Chyba nie bardzo wiem.... Może objaśnisz jak działa NCQ? I jeszcze wyjaśnij czym się różni NCQ od technologii, w której zamiast 8 zapisów po 512 bajtów (8 plików po 0-512) bajtów do sąsiednich sektorów, system plików dokona scalenia i puści jeden zapis 4096 bajtów, a sobie zaznaczy, że to było 8 plików osadzonych w kolejnych sektorach (filesystem widzi dysk sektorowo i z góry wie w które sektory trafią dane, bo w końcu to właśnie on ustala)?

NCQ nie zajmuej się "scalaniem i puszczaniem", ono tylko porządkuje odwołania do dysku aby osiągnąć jak najmniejsze czasy opóźnień. To technologia opracowana z myślą o dyskach talerzowych, i w ssd nie ma większego sensu z uwagi na niewielkie opóźnienia.

 

Problem w tym, że te układy mają za małą moc obliczeniową na takie zabawy.

Tego raczej nikt nie zmierzy. A jednak intelowi się udało. Dobry kontroler, dobry soft, sporo kanałów i efekty są ok. Tylko trzeba było nie kupować kastrata.

 

Nie wiem jak mam to rozumieć, bo w moich testach wyszło coś zupełnie odwrotnego. Zapis małych plików jest powolny i męczy (czy jak to nazwać) komórki. Porównywałeś screeny pierwszy i ostatni jakie wkleiłem. W obu przypadkach jest wgrana do napędu ta sama zawartość, ale:

- za pierwszym razem - za pośrednictwem systemu plików czyli kopiuj katalog

- za drugim razem poprzez zrzut sektorów HDD do pliku i restore na napędzie SSD

To oczywiste że "zapis małych plików męczy". Dlatego o wiele szybciej wypakowujr i pakuje się pliki do/z archiwum typu "solid" gdzie są one łączone w większe bloki. To dlatego programy do tworzenia obrazu dysku typu Acronis True Image sczytujące dysk po ścieżkach są o niebo szybsze od nortonowskiego Ghosta, który dziubie plik po pliczku. Nie dziw się więc że odczyt dużej partii danych zapisanej jednym ciągiem jest szybszy niż takiej samej partii zapisanej w plikach po 1 kb.

 

No jasne, że żadna modyfikacja - czas na całkiem nowy system plików. Keszowania nie trzeba aż tak dużo. Niech czas "przewidywania" będzie ustalony na 100-200ms - to wystarczy aby złapać kilka małych plików i je puścić jako jeden blok, jednocześnie nie będzie to uciążliwe opóżnienie dla dużych plików. Ostatecznie wystarczy kontrola "na żywca" - moc obecnych procesorów jest wystarczająca na takie sztuczki.

Obawiam się że coś takiego już dawno jest w użyciu. Temu w końcu służy kesz dysku i kesz systemowy, aby nie babrać się z każdym plikiem z osobna - już naście lat temu praca pod dosem bez bufora typu smartdrv była nieznośna. A że ciągle za wolno? Co poradzić. Lepszy system plików może i poprawiłby sytuację, ale na rewolucję bym nie liczył.

 

Microsoft już od kilku lat bąka o nowym systemie plików, ale oni ledwo znajdują czas na łatanie dziur w zabezpieczeniach.

Racja.

 

Co mnie interesowało już sprawdziłem i odpowiednio zaplanowałem upgrade maszyny na następny rok prac. A po sygnaturce widać, że na STORAGE kładę szczególny nacisk. Jeden tylko mi się nasuwa wniosek, niektórzy ludzie(firmy) dają ciała na tym polu.

Ogólnie to te Twoje jęki wydają mi się trochę nie na miejscu. Mówisz że kładziesz taki nacisk na "storage", a kupujesz pod poważny projekt budżetowy dysk ssd? I gdzie tu ten nacisk? Kupiłeś budżetowe rozwiązanie, dostałeś budżetową wydajność. Chcesz żeby dysk ssd za kilkaset zł bił Ci rekordy prędkości osiągane prze sasy w raidzie? Chyba niepoważny jesteś. Jak już Ci się zachciało do poważnej pracy ssd, i to mlc na dodatek, to trzeba było przynajmniej kupić pełnego intela x25-m zamiast tego kastrata od kingstona. We wszystkich testach jakie widziałem na plikach rzędu 4kb te dyski osiągają transfer po 60mb/sek i więcej. Jeśli i to byłoby Ci mało to trzeba było kupić takich dysków więcej niż jeden i je zraidować. A najlepiej kupić intela (jednego albo więcej) na slc i miałbyś spokój. W końcu na podsystem dyskowy kładziesz nacisk, prawda? A jeśli uważasz że to zbyt droga zabawa to możesz raidować zwykłe dyski, Twój wybór, ale nie jęcz, że budżetowy ssd z nimi przegrywa, bo to niepoważne.

[12 0]

Nie dziw się więc że odczyt dużej partii danych zapisanej jednym ciągiem jest szybszy niż takiej samej partii zapisanej w plikach po 1 kb.

Technicznie rzecz biorąc zawartość dysku jest w obu przypadkach taka sama i dla dysku HDD nie ma żadnej różnicy w odczycie, a dla SSD Kingstona jest i to spora. Chodzi o to, że co ten cache właściwie robi i czemu taka lipna ta optymalizacja? Stare Transcendy (bez cache) działają w zasadzie tak samo, jak nie lepiej.

 

Obawiam się że coś takiego już dawno jest w użyciu. Temu w końcu służy kesz dysku i kesz systemowy, aby nie babrać się z każdym plikiem z osobna - już naście lat temu praca pod dosem bez bufora typu smartdrv była nieznośna. A że ciągle za wolno? Co poradzić. Lepszy system plików może i poprawiłby sytuację, ale na rewolucję bym nie liczył.

Ależ wykazałem wyżej co by to dało i jest to warte zachodu.

 

Ogólnie to te Twoje jęki wydają mi się trochę nie na miejscu. Mówisz że kładziesz taki nacisk na "storage", a kupujesz pod poważny projekt budżetowy dysk ssd? I gdzie tu ten nacisk?

Miałem już kilka drogich wtop, więc trochę inaczej podchodzę do pewnych spraw. Skoro kastrat tak słabo chodzi to i w pełnym rewolucji nie będzie.

 

Kupiłeś budżetowe rozwiązanie, dostałeś budżetową wydajność. Chcesz żeby dysk ssd za kilkaset zł bił Ci rekordy prędkości osiągane prze sasy w raidzie? Chyba niepoważny jesteś.

Akurat ten SSD miał zastąpić pojedynczego SASa, którego na allegro można kupić za 100zł.

 

Jak już Ci się zachciało do poważnej pracy ssd, i to mlc na dodatek, to trzeba było przynajmniej kupić pełnego intela x25-m zamiast tego kastrata od kingstona.

Ale czym on się może różnić - ma dwa razy więcej w transferach (bo jest dwa razy więcej kostek) - procesorek, pamięć i soft jest dokładnie ten sam.

 

We wszystkich testach jakie widziałem na plikach rzędu 4kb te dyski osiągają transfer po 60mb/sek i więcej. Jeśli i to byłoby Ci mało to trzeba było kupić takich dysków więcej niż jeden i je zraidować. A najlepiej kupić intela (jednego albo więcej) na slc i miałbyś spokój.

SLC jest dla mnie za drogie. A budżetowa cena Kingstona (Intela) MLC nie usprawiedliwia tak tragicznej wydajności zapisów (i pózniejszych odczytów z tych miejsc)

[kresek 0]

sprawdzałeś może wariant z ramdyskiem, o którym wspominałeś?

[Firekage 1]

SLC jest dla mnie za drogie. A budżetowa cena Kingstona (Intela) MLC nie usprawiedliwia tak tragicznej wydajności zapisów (i pózniejszych odczytów z tych miejsc)

Usprawiedliwia bo to dysk low endowy przeznaczony na trzymanie oesu z uwzglednieniem slabego zapisu. Osoba majaca SSD na oes + hdd na instalki i dane nie bedzie miala problemow takich, ktore tutaj opisujesz. To nie jest dysk przeznaczony do profesjonalnej pracy, od tego jest SLC.

[12 0]

sprawdzałeś może wariant z ramdyskiem, o którym wspominałeś?

Na razie zdążyłem wykonać test zapisów w HDTune.

Wygląda...

 

Usprawiedliwia bo to dysk low endowy przeznaczony na trzymanie oesu z uwzglednieniem slabego zapisu. Osoba majaca SSD na oes + hdd na instalki i dane nie bedzie miala problemow takich, ktore tutaj opisujesz. To nie jest dysk przeznaczony do profesjonalnej pracy, od tego jest SLC.

Co masz na myśli pisząc "słaby zapis"?

[Bono[UG] 1916]

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.

Z tego co wiem, to nie służy żywotności, a wydajności. Historycznie sięga dysków talerzowych i Win2000 (o ile dobrze pamiętam). Chodzi o pokrywanie się bloków logicznych partycji z fizycznymi dysku. W HDD chodzi o ścieżki (cylindry), a w SSD o bloki pamięci.

To tak skrótowo i pewnie jakieś niuanse przeoczyłem.

[12 0]

Dobrze mówisz, a wnioski wyciągasz złe. Jeżeli nie ma pokrycia bloków logicznych z fizycznymi to aby zapisać blok, tak naprawdę napęd musi zapisać (modyfikować) dwa bloki - stąd skrócenie żywotności. Na wydajność wpływ też pewnie jakiś będzie...

[12 0]

sprawdzałeś może wariant z ramdyskiem, o którym wspominałeś?

No więc sprawdziłem ten wariant. Wciąż szukam szczęki......

Nie widać efektu wczytywania. Z HDD widać jak się wczytują ścieżki (trwa to ze 3 sekundy), potem kilkanaście sekund i wskakują elementy na ścieżkach. Z ramdysku nie widać jak się wczytują ściezki (po prostu od razu się pojawiają), a elementy na ścieżkach pojawiają się w ciągu 2 sekund.

Taki mały szok......

 

Update... Czyszczenie "Projektu" na HDD trwa dobrą godzinę. Na ramdysku ta sama operacja wykonała się w czasie pisania tej odpowiedzi (kilka minut). Odczyt katalogu trwa sekundę (450tyś. plików), podczas gdy z dysku kilkanaście sekund.

[kresek 0]

no cóż, to teraz zostaje RAM wiadrami dorzucać...

[Firekage 1]

Co masz na myśli pisząc "słaby zapis"?

Wolny wzgledem pelnego Intela, przy czym wiem, ze u Ciebie nie jest to wazne, ale ten Kingston to budzetowe rozwiazanie MLC, a nie sprzet SLC do tak zlozonych prac jakie Ty robisz.

 

PS - ten Ramdisk to jaka nosi nazwe? Jaki program uzyty zostal?

[=-Mav-= 2]

Ja pod windą xp używam ramdysku SuperSpeed-a żeby wykorzystać zalegające 700mb ramu. Nie ma to jak błyskawiczny temp i szybsze wczytywanie się opery/winampa itp.

[Firekage 1]

Ja pod windą xp używam ramdysku SuperSpeed-a żeby wykorzystać zalegające 700mb ramu. Nie ma to jak błyskawiczny temp i szybsze wczytywanie się opery/winampa itp.

 

Sam uzywalem Gevotte'a, ale przyznam sie szczerze, ze roznicy nie widzialem zadnej, za to przeniesienie tempa na ramdisk powodowal tylko to, ze nie moglem instalowac obszernych gier, a cache FF jakos mnie nie spowalnial

 

Ps - Winampa nie uzywam przez jego "zapychanie sie", foobar zawsze startuje tak samo. Nie zwalnia po czasie, gdy Windows jest juz zasmiecony. Nie mowie nawet o tym jak foobar szybko odpala sie

 

Edit - podziekowal za progs w cenie 40$

[Bono[UG] 1916]

Dobrze mówisz, a wnioski wyciągasz złe. Jeżeli nie ma pokrycia bloków logicznych z fizycznymi to aby zapisać blok, tak naprawdę napęd musi zapisać (modyfikować) dwa bloki - stąd skrócenie żywotności. Na wydajność wpływ też pewnie jakiś będzie...

A sector is the smallest accessible unit on a physical disk, with multiple sectors comprising a track. A partition that is track misaligned will occasionally cause 2 I/O operations instead of one depending on the actual drive geometry.

http://www.messagingtalk.org/content/69.html

 

A mniejsze zużycie, to może być jedynie "efekt uboczny" dla SSD. Od kontroli zużycia są odpowiednie algorytmy.

 

Taki jeszcze pomysł mi wpadł do głowy. A jakby skompresować partycję? Powinien być wtedy utworzony jeden wielki plik i tylko zmieniana jego zawartość.

Inny, to nie wykorzystać całej pojemności na partycję, zostawić trochę nieprzydzielonego miejsca. Z tego co pamiętam jest ono i tak wykorzystywane w celu zmniejszenia zużycia komórek pamięci. Pośrednio wydłuża czas szybkiego działania bez użycia trima.

 

Jakby co to są luźne pomysły (te 2), a ja już trochę przymulony jestem

[=-Mav-= 2]

Kompresja partycji? O matko, tego to już się nie praktykuje chyba od czasów windy 98 i końca systemu fat16. No chyba że mówisz o kompresji w ntfsie? Czasami się ona przydaje, tyle że przy większych plikach powoduje koszmarną wręcz fragmentację.

[12 0]

Wolny wzgledem pelnego Intela, przy czym wiem, ze u Ciebie nie jest to wazne, ale ten Kingston to budzetowe rozwiazanie MLC, a nie sprzet SLC do tak zlozonych prac jakie Ty robisz.

 

PS - ten Ramdisk to jaka nosi nazwe? Jaki program uzyty zostal?

Jest to oprogramowanie RamDiskPlus firmy SuperSpeed.

 

A mniejsze zużycie, to może być jedynie "efekt uboczny" dla SSD. Od kontroli zużycia są odpowiednie algorytmy.

Nie chodzi o kontrolę tylko stopień zużycia. Wielkość sektora dysku HDD to 512 bajtów, ale napędu SSD to już 4096 bajtów czyli 8 razy więcej i to komplikuje sprawę. Tradycyjnie początek partycji zaczyna się na sektorze 63 (w wymiarze 512bajtowym), odpowiada to 7,875 bloku dysku SSD (w wymiarze 4096 bajtowym). Jest to końcówka bloku siudmego, a konkretnie ostatnie 512 bajtów. To powoduje problem, że zapis pliku większego niż 512 bajtów wymaga modyfikacji dwóch bloków NAND we flashu. Gdyby sektor startowy przesunąć o jeden czyli do sektora 64(512) to odpowiadałoby to blokowi 8(4096) Flasha. Teraz zapis plików o wielkości jednego bloku NAND powoduje modyfikację tylko jednego bloku NAND, a nie dwóch jak w poprzednim przypadku.

 

Taki jeszcze pomysł mi wpadł do głowy. A jakby skompresować partycję? Powinien być wtedy utworzony jeden wielki plik i tylko zmieniana jego zawartość.

Inny, to nie wykorzystać całej pojemności na partycję, zostawić trochę nieprzydzielonego miejsca. Z tego co pamiętam jest ono i tak wykorzystywane w celu zmniejszenia zużycia komórek pamięci. Pośrednio wydłuża czas szybkiego działania bez użycia trima.

 

Jakby co to są luźne pomysły (te 2), a ja już trochę przymulony jestem

Nie warte zachodu.