Witam,

Porównałem jego wydajność w realistycznych testach, z dwoma innymi dyskami. Sklonowałem identyczny system na różne dyski i pomierzyłem czasy trwania konkretnych operacji. Zakładam, że klonowanie partycji przenosi także stan jej pofragmentowania, bo jeśli nie to nie należy porównywać wyników dysku F2EG z dwoma pozostałymi, bo to z niego na nie system był klonowany.


Na wstępie jednak test syntetyczny tych 3 dysków:

HD Tune MAX speed:
1 TB Caviar Black (7200 rpm) WD1001FALS: 114 MB/s
1.5 TB Samsung F2EG (5400 rpm) HD154UI: 115 MB/s
1TB Samsung seria F3 (7200 rpm) HD103SJ: 145 MB/s

HD Tune MIN speed:
1 TB Caviar Black (7200 rpm) WD1001FALS: 54 MB/s
1.5 TB Samsung F2EG (5400 rpm) HD154UI: 51 MB/s
1TB Samsung seria F3 (7200 rpm) HD103SJ: 54 MB/s

HD Tune AVG speed:
1 TB Caviar Black (7200 rpm) WD1001FALS: 91 MB/s
1.5 TB Samsung F2EG (5400 rpm) HD154UI: 88 MB/s
1TB Samsung seria F3 (7200 rpm) HD103SJ: 119 MB/s

HD Tune - czas dostępu:
1 TB Caviar Black (7200 rpm) WD1001FALS: 12.5 ms
1.5 TB Samsung F2EG (5400 rpm) HD154UI: 14.4 ms
1TB Samsung seria F3 (7200 rpm) HD103SJ: 14.2 ms


A teraz testy real-life:


Czas wstawania Win XP
1 TB Caviar Black (7200 rpm) WD1001FALS: 47 s.
1.5 TB Samsung F2EG (5400 rpm) HD154UI: 52 s.
1TB Samsung seria F3 (7200 rpm) HD103SJ: 48 s.


Czas uruchamiania Photoshopa - antywirus włączony:
1 TB Caviar Black (7200 rpm) WD1001FALS: 9.5 s.
1.5 TB Samsung F2EG (5400 rpm) HD154UI: 12.9 s.
1TB Samsung seria F3 (7200 rpm) HD103SJ: 9.8 s.

Czas uruchamiania Photoshopa - bez antywira:
1 TB Caviar Black (7200 rpm) WD1001FALS: 8.5 s.
1.5 TB Samsung F2EG (5400 rpm) HD154UI: 9.5 s.
1TB Samsung seria F3 (7200 rpm) HD103SJ: 8.9 s.


Czas uruchamiania się Quarka 8 - antywirus włączony:
1 TB Caviar Black (7200 rpm) WD1001FALS: 19.1 s.
1.5 TB Samsung F2EG (5400 rpm) HD154UI: 25.3 s.
1TB Samsung seria F3 (7200 rpm) HD103SJ: 20 s.

Czas uruchamiania się Quarka 8 - bez antywira:
1 TB Caviar Black (7200 rpm) WD1001FALS: 18.3 s.
1.5 TB Samsung F2EG (5400 rpm) HD154UI: 21 s.
1TB Samsung seria F3 (7200 rpm) HD103SJ: 19 s.


Czas wstawania Firefoxa - antywirus włączony:
1 TB Caviar Black (7200 rpm) WD1001FALS: 6 s.
1.5 TB Samsung F2EG (5400 rpm) HD154UI: 6.5 s.
1TB Samsung seria F3 (7200 rpm) HD103SJ: 6.2 s.

Czas wstawania Firefoxa - bez antywira:
1 TB Caviar Black (7200 rpm) WD1001FALS: 5.4 s.
1.5 TB Samsung F2EG (5400 rpm) HD154UI: 6 s.
1TB Samsung seria F3 (7200 rpm) HD103SJ: 5.6 s.


Czas rozpakowania archiwum 18 tys. małych plików - antywir włączony:
1 TB Caviar Black (7200 rpm) WD1001FALS: 1:17 s.
1.5 TB Samsung F2EG (5400 rpm) HD154UI: 1:15 s.
1TB Samsung seria F3 (7200 rpm) HD103SJ: 0:48 s.

Czas rozpakowania archiwum 18 tys. małych plików - bez antywira:
1 TB Caviar Black (7200 rpm) WD1001FALS: 1:06 s.
1.5 TB Samsung F2EG (5400 rpm) HD154UI: 1:05 s.
1TB Samsung seria F3 (7200 rpm) HD103SJ: 0:48 s.


Wnioski dopiszcie sami pliz.

latet

Użytkownik "Latet" <latet@sdasda.pl> napisał w wiadomości news:hl88l9$el3$1inews.gazeta.pl...

A teraz testy real-life:
Czas wstawania Win XP
Czas uruchamiania Photoshopa - antywirus włączony:
Czas uruchamiania Photoshopa - bez antywira:
Czas uruchamiania się Quarka 8 - antywirus włączony:
Czas uruchamiania się Quarka 8 - bez antywira:
Czas wstawania Firefoxa - antywirus włączony:
Czas wstawania Firefoxa - bez antywira:

Wnioski dopiszcie sami pliz.

Wniosek jest taki, że zajmujesz się głównie uruchamianiem programów.

Użytkownik "MC" <m5c@go2.pl> napisał w wiadomości grup dyskusyjnych:hl8gm0$g6k$1@node2.news.atman.pl...

Wniosek jest taki, że zajmujesz się głównie uruchamianiem programów.

Wnioski są takie, że różnice są nieodczuwalne (poza wypakowywaniem archiwum).

--
Jeżeli nie potrafisz skonfigurować NOD32, aby nie wysyłał śmieci
to lepiej nic nie pisz, gdyż nie jesteś obdarzony inteligencją.

Użytkownik "qwerty" <qwerty01@poczta.fm> napisał w wiadomości news:hl8gvj$hea$1news.task.gda.pl...

Użytkownik "MC" <m5c@go2.pl> napisał w wiadomości grup dyskusyjnych:hl8gm0$g6k$1@node2.news.atman.pl...

Wniosek jest taki, że zajmujesz się głównie uruchamianiem programów.

Wnioski są takie, że różnice są nieodczuwalne (poza wypakowywaniem archiwum).

Wypakowania archiwum jest jedynym testem z zaprezentowanych, który ma jakikolwiek sens.

Wnioski są takie, że różnice są nieodczuwalne (poza wypakowywaniem archiwum).

Wypakowania archiwum jest jedynym testem z zaprezentowanych, który ma jakikolwiek sens.

Akurat dla mnie (i pewnie nie tylko) czas uruchamiania programów przekłada się na komfort psychiczny. Dlatego taki nacisk na to położyłem.

latet

Użytkownik "Latet" <latet@sdasda.pl> napisał w wiadomości news:hl91g8$7c8$1inews.gazeta.pl...

Wnioski są takie, że różnice są nieodczuwalne (poza wypakowywaniem archiwum).

Wypakowania archiwum jest jedynym testem z zaprezentowanych, który ma jakikolwiek sens.

Akurat dla mnie (i pewnie nie tylko) czas uruchamiania programów przekłada się na komfort psychiczny. Dlatego taki nacisk na to położyłem.

Ale jest to czynność jednorazowa, więc nie mająca większego wpływu na całokształt.

Jeszcze jeden teścik zrobiłem.

Czas kopiowania (w ramach tej samej partycji) folderu składającego się z 18 tys. małych plików (razem 1.2 GB).


1 TB Caviar Black (7200 rpm) WD1001FALS: 1:38"
1.5 TB Samsung F2EG (5400 rpm) HD154UI: 1:47"
1TB Samsung seria F3 (7200 rpm) HD103SJ: 1:14"

latet

Użytkownik "Latet" <latet@sdasda.pl> napisał w wiadomości news:hlc482$io2$1inews.gazeta.pl...

Jeszcze jeden teścik zrobiłem.

Czas kopiowania (w ramach tej samej partycji) folderu składającego się z 18 tys. małych plików (razem 1.2 GB).


1 TB Caviar Black (7200 rpm) WD1001FALS: 1:38"
1.5 TB Samsung F2EG (5400 rpm) HD154UI: 1:47"
1TB Samsung seria F3 (7200 rpm) HD103SJ: 1:14"

  Tylko kto i po co wykonuje takie dziwaczne operacje???
  Idź do sklepu i wymień dysk na taki, który Ci odpowiada a nie trać czas głupoty :)

--
marfi

W dniu 2010-02-15 19:36, Latet pisze:

Czas kopiowania (w ramach tej samej partycji) folderu składającego się z
18 tys. małych plików (razem 1.2 GB).

Zadanie, którego należy unikać. Kopiowania plików w ramach
jednego napędu fizycznego w ogóle należy unikać, jeżeli się
da, a kopiowania małych plików -- jak ognia :) Więc nie wiem,
jaki sens ma taki benchmark, bo jest nieco oderwany od rze-
czywistości ;)

--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\................... Microsoft MVP ......................../

Użytkownik "Radosław Sokół" <Radoslaw.Sokol@grush.one.pl> napisał w wiadomości news:2010021520045700grush.one.pl...

W dniu 2010-02-15 19:36, Latet pisze:

Czas kopiowania (w ramach tej samej partycji) folderu składającego się z
18 tys. małych plików (razem 1.2 GB).

Zadanie, którego należy unikać. Kopiowania plików w ramach
jednego napędu fizycznego w ogóle należy unikać, jeżeli się
da, a kopiowania małych plików -- jak ognia :) Więc nie wiem,
jaki sens ma taki benchmark, bo jest nieco oderwany od rze-
czywistości ;)

  Zgadzam się. Ogólnie rzecz biorąc to do wszelakich testów dysków należy podchodzić ostrożnie bo zazwyczaj pierwsza próba jest istotnie wolniejsza niż następna niby identyczna ale już wykonana z użyciem cache.
  Być może testy były przeprowadzane zawsze po restarcie komputera ale testujący nic o tym nie pisze...

--
marfi

 Być może testy były przeprowadzane zawsze po restarcie komputera ale testujący nic o tym nie pisze...

Oczywiście że tak!

A sens... no cóż, chciałem przetestować operację, która będzie w jak największym stopniu zależna od czasu dostępu. Poza tym - wszystkie 3 modele mają tyle samo cache.

latet

Użytkownik "Latet" <latet@latet.pl> napisał w wiadomości news:hlcgf1$9oq$1inews.gazeta.pl...

 Być może testy były przeprowadzane zawsze po restarcie komputera ale testujący nic o tym nie pisze...

Oczywiście że tak!

A sens... no cóż, chciałem przetestować operację, która będzie w jak największym stopniu zależna od czasu dostępu. Poza tym - wszystkie 3 modele mają tyle samo cache.

  Więc skoro dysponujesz taki zestawem dysków do testów to po co rozpętałeś dyskusję o wyższości świąt Bożego Narodzenia nad świętami Wielkanocy?
  Jaja sobie robisz czy reklamujesz jakąś markę kosztem sprzedawców starszych modeli WD?

--
marfi

W dniu 2010-02-15 23:04, Latet pisze:

A sens... no cóż, chciałem przetestować operację, która będzie w jak
największym stopniu zależna od czasu dostępu. [...]

Owszem, i to Ci się udało. Jednak w codziennej pracy należy
jak najbardziej unikać operacji zależnych od czasu dostępu.

Z tego zresztą powodu tak promuję pisanie małych i lekkich
aplikacji mimo, że RAM komputerów ma pojemność wystarczają-
cą do przechowywania wielkiego kodu i wielkich zbiorów da-
nych. Owszem, jak aplikacja jest w RAMie to działa szybko,
ale mało kto bierze pod uwagę, że musi się tam *skądś wziąć*.
A weźmie się w efekcie operacji stronicowania, która jest
dostępem silnie losowym -- a więc im mniejsza aplikacja, tym
mniej stronicowania i szybsze jej działanie (o całe rzędy
wielkości, a nie milisekundy), a im oszczędniej generuje
dane w bloku pamięci anonimowej, tym mniej operacji stroni-
cowania do pliku wymiany i podobny wzrost wydajności.

--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\................... Microsoft MVP ......................../

A sens... no cóż, chciałem przetestować operację, która będzie w jak
największym stopniu zależna od czasu dostępu. [...]

Owszem, i to Ci się udało. Jednak w codziennej pracy należy
jak najbardziej unikać operacji zależnych od czasu dostępu.

Jasne i własnie dlatego chciałem przetestować dysk pod tym kątem, ponieważ takie operacje, choćbym ich nie wiem jak unikał, i tak się zdarzają, wszak nie mam wpływu na sposób działania wielu aplikacji...

latet

W dniu 19.02.2010 14:41, Latet pisze:

Owszem, i to Ci się udało. Jednak w codziennej pracy należy
jak najbardziej unikać operacji zależnych od czasu dostępu.

Jasne i własnie dlatego chciałem przetestować dysk pod tym kątem,
ponieważ takie operacje, choćbym ich nie wiem jak unikał, i tak się
zdarzają, wszak nie mam wpływu na sposób działania wielu aplikacji...

Ale masz wpływ na ich wybór -- możesz bojkotować aplikacje,
które są napisane nieoszczędnie i niepotrzebnie działają
wolniej, niż by mogły :)

--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\........................................................../

epsilon$ while read LINE; do echo \>"$LINE"; done < "Radosław Sokół"

Owszem, i to Ci się udało. Jednak w codziennej pracy należy
jak najbardziej unikać operacji zależnych od czasu dostępu.

Jasne i własnie dlatego chciałem przetestować dysk pod tym kątem,
ponieważ takie operacje, choćbym ich nie wiem jak unikał, i tak się
zdarzają, wszak nie mam wpływu na sposób działania wielu aplikacji...

Ale masz wpływ na ich wybór -- możesz bojkotować aplikacje,
które są napisane nieoszczędnie i niepotrzebnie działają
wolniej, niż by mogły :)

Radek, jesteś niepoprawnym idealistą. W rzeczywistości często okazuje
się, że masz do wyboru aplikację jedną z... jednej. Bo akurat musisz
zrobić coś, do czego masz po prostu jedną aplikację na rynku. Albo masz
aplikacje trzy, ale jedna tylko daje ci możliwość wymiany danych
z innymi ze względu na stopień popularności. Albo akurat taki masz
standard korporacyjny. Albo...
W ogólności masz rację, ale w szczególności ta rada jest trochę typu
"weźmy krowę sferyczną".

--
d'`'`'`'`'`'`'`'`'`'`'`'`'Yb `b  Kruk@epsilon.eu.org   d' d' http://epsilon.eu.org/ Yb `b,-,.,-,.,-,.,-,.,-,.,-,.d'

W dniu 13.07.2010 09:38, Mariusz Kruk pisze:

Radek, jesteś niepoprawnym idealistą. W rzeczywistości często okazuje
się, że masz do wyboru aplikację jedną z... jednej. Bo akurat musisz

Nie "często" ale w "specjalizowanych zastosowaniach". Typowy
domowy użytkownik - a takich ma mnóstwo - może przebierać w
programach realizujących te same funkcje. Nie podoba się wol-
ne i wielkie Nero? Można użyć innych programów nagrywających
CD/DVD. I tak dalej...

Owszem, w pewnym momencie dochodzimy do wyborów typu "czy
wolny i toporny OpenOffice.org, czy sprawny, ale 'zły' i
komercyjny Microsoft Office". To trudne wybory i niestety
dzisiaj bardzo trudno o coś trzeciego.

--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\........................................................../

epsilon$ while read LINE; do echo \>"$LINE"; done < "Radosław Sokół"

Radek, jesteś niepoprawnym idealistą. W rzeczywistości często okazuje
się, że masz do wyboru aplikację jedną z... jednej. Bo akurat musisz

Nie "często" ale w "specjalizowanych zastosowaniach". Typowy
domowy użytkownik - a takich ma mnóstwo - może przebierać w
programach realizujących te same funkcje. Nie podoba się wol-
ne i wielkie Nero? Można użyć innych programów nagrywających
CD/DVD. I tak dalej...

To "i tak dalej" kończy się dość szybko, niestety. Owszem, przeglądarek
obrazków jest pierdyliard (chociaż szybko okazuje się, że sensownych
z punktu widzenia pożądanej funkcjonalności są raptem ze trzy; a jak do
tego jeszcze dodasz kryterium ceny, i tak wszyscy używają
Picasy/IrfanView)

Owszem, w pewnym momencie dochodzimy do wyborów typu "czy
wolny i toporny OpenOffice.org, czy sprawny, ale 'zły' i
komercyjny Microsoft Office". To trudne wybory i niestety
dzisiaj bardzo trudno o coś trzeciego.

Ano właśnie. Rynek oprogramowania jest mocno "dziwny".

--
/\-\/\-\/\-\/\-\/\-\/\-\/\ \  Kruk@epsilon.eu.org   / / http://epsilon.eu.org/ \ \/-/\/-/\/-/\/-/\/-/\/-/\/

W dniu 20.07.2010 10:28, Mariusz Kruk pisze:

z punktu widzenia pożądanej funkcjonalności są raptem ze trzy; a jak do
tego jeszcze dodasz kryterium ceny, i tak wszyscy używają
Picasy/IrfanView)

Ale akurat IrfanView należy do programów bardzo oszczędnie
napisanych (wręcz *zbyt* oszczędnie, bo aż wygląda czasem
ascetycznie i topornie) :) Szybkość i oszczędność również
miały według mnie wpływ na jego popularność.

--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\........................................................../

epsilon$ while read LINE; do echo \>"$LINE"; done < "Radosław Sokół"

z punktu widzenia pożądanej funkcjonalności są raptem ze trzy; a jak do
tego jeszcze dodasz kryterium ceny, i tak wszyscy używają
Picasy/IrfanView)

Ale akurat IrfanView należy do programów bardzo oszczędnie
napisanych (wręcz *zbyt* oszczędnie, bo aż wygląda czasem
ascetycznie i topornie) :) Szybkość i oszczędność również
miały według mnie wpływ na jego popularność.

Ależ ja nie przeczę. Tylko pokazuję, że z tego mrowia rzekomych
alternatyw w praktyce zostają trzy na krzyż. A w wielu zastosowaniach
nawet tylu nie ma.

--
  Kruk@ -\                   |           }-> epsilon.eu.org | http:// -/                   |                              |

Użytkownik "Radosław Sokół" <Radoslaw.Sokol@grush.one.pl> napisał w
wiadomości news:2010021520045700grush.one.pl...

W dniu 2010-02-15 19:36, Latet pisze:
> Czas kopiowania (w ramach tej samej partycji) folderu składającego się z
> 18 tys. małych plików (razem 1.2 GB).

Zadanie, którego należy unikać. Kopiowania plików w ramach
jednego napędu fizycznego w ogóle należy unikać, jeżeli się
da, a kopiowania małych plików -- jak ognia :)

w kontekście testu, czy w ogóle.

artur(m)

W dniu 2010-02-16 09:39, Artur(m) pisze:

Zadanie, którego należy unikać. Kopiowania plików w ramach
jednego napędu fizycznego w ogóle należy unikać, jeżeli się
da, a kopiowania małych plików -- jak ognia :)

w kontekście testu, czy w ogóle.

Ogólnie. Oczywiście, jak koniecznie trzeba skopiować pliki,
to trzeba, ale jeżeli jakiś proces obliczeniowy jest zależ-
ny od kopiowania dużej liczby plików, to należy zmienić ar-
chitekturę procesu, a nie skazywać dysku na beznadziejne
machanie głowicami.

Jest to zresztą argument przeciwko dzieleniu dysków na dużą
liczbę partycji -- w pewnym momencie okazuje się, że sporo
czasu może się tracić na przenoszenie danych między party-
cjami -- chyba, że od początku ma się bardzo dobrze określo-
ną strukturę podziału danych między partycje i idealnie do-
brane ich rozmiary :)

--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\................... Microsoft MVP ......................../

Użytkownik "Radosław Sokół" <Radoslaw.Sokol@grush.one.pl> napisał w wiadomości news:2010021520045700grush.one.pl...

W dniu 2010-02-15 19:36, Latet pisze:

Czas kopiowania (w ramach tej samej partycji) folderu składającego się z
18 tys. małych plików (razem 1.2 GB).

Zadanie, którego należy unikać. Kopiowania plików w ramach
jednego napędu fizycznego w ogóle należy unikać, jeżeli się
da, a kopiowania małych plików -- jak ognia :) Więc nie wiem,
jaki sens ma taki benchmark, bo jest nieco oderwany od rze-
czywistości ;)

Za to jedyny domowej roboty, który można od biedy nazwać obiektywnym. Jeśli mierzysz transfery z jednego dysku na drugi to nie wiadomo jaki w końcowym wyniku jest udział poszczególnych napędów i stanu łącza między nimi.

W dniu 2010-02-16 14:22, MC pisze:

Za to jedyny domowej roboty, który można od biedy nazwać obiektywnym.

Ale on mierzy jedynie:

1) w pewnym zakresie czas dostępu dysku,

2) w sporym zakresie optymalizację systemu plików pod kątem
    buforowania operacji na metadanych (które jest zazwyczaj
    słabe z racji zapobiegania awariom i tworzenia dziennika
    zmian).

To samo tyczy się zresztą codziennej pracy: oprogramowanie
powinno działać tak, by nie wykonywać operacji zależnych od
czasu dostępu i szybkości obsługi operacji na metadanych,
bo w przeciwnym przypadku będzie bardzo trudno uzyskać sen-
sowną wydajność.

Jeśli mierzysz transfery z jednego dysku na drugi to nie wiadomo jaki w
końcowym wyniku jest udział poszczególnych napędów i stanu łącza między
nimi.

Zazwyczaj wąskim gardłem są same dyski, a nie interfejsy.
Wystarczy zresztą zrobić kopiowanie do /dev/null lub z
/dev/zero, by wykluczyć większość czynników mogących wpły-
wać na pomiar. Oczywiście w takim przypadku mierzy się je-
dynie transfer sekwencyjny, bez uwzględnienia czasu dostę-
pu.

--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Politechnika Śląska                   |
\................... Microsoft MVP ......................../

Użytkownik "Radosław Sokół" <Radoslaw.Sokol@grush.one.pl> napisał w wiadomości news:2010021907560300grush.one.pl...

W dniu 2010-02-16 14:22, MC pisze:

Za to jedyny domowej roboty, który można od biedy nazwać obiektywnym.

Ale on mierzy jedynie:

1) w pewnym zakresie czas dostępu dysku,

2) w sporym zakresie optymalizację systemu plików pod kątem
   buforowania operacji na metadanych (które jest zazwyczaj
   słabe z racji zapobiegania awariom i tworzenia dziennika
   zmian).

Zgoda. Dlatego napisałem "od biedy".

Jeśli mierzysz transfery z jednego dysku na drugi to nie wiadomo jaki w
końcowym wyniku jest udział poszczególnych napędów i stanu łącza między
nimi.

Zazwyczaj wąskim gardłem są same dyski, a nie interfejsy.

I to przeszkadza zmierzyć dysk szybszy za pomocą wolniejszego.