Wybór dysku 500/750 GB, 16 vs 32 MB

[AleX69]

Napisany przez yahol

Ciekawe co to znaczy?

I czy nie o zwiekszenie wydajnosci dysku tu chodzi.

nie ... bo jesli tak by bylo jak mylnie wnioskujesz producenci ladowali by 128MB czy tez 512MB pamieci cache
a drowali by sobie np wdrazanie do dyskow technelogi hybrydowych (PDS)

[AleX69]

o tak - i jak czytamy - zapis prostopadly powstal by zwikszyc gestosc zapisu a nie w celu zwiekszenia bezpieczenstwa danych ... np przed 'temperatura' ?!

wiec latet@ co ma piernik do wiatraka?

[latet]

Napisany przez AleX69

o tak - i jak czytamy - zapis prostopadly powstal by zwikszyc gestosc zapisu a nie w celu zwiekszenia bezpieczenstwa danych ... np przed 'temperatura' ?!

wiec latet@ co ma piernik do wiatraka?

Przeczytaj dokładniej to co wkleiłem. Tam jest to wyjaśnione.
Zapis prostopadły ma 2 zalety: więcej danych się mieści i są bardziej odporne na zmiany temperatury.

latet

[sobrus]

Je***380;eli por***243;wnujemy podobne dyski (tzn takie kt***243;rych pr***281;dko***347;***263; samego dysku jest taka sama) to ten z wi***281;kszym cache jest zawsze szybszy. Mysle ze o to yaholowi chodzi.
To oczywiste - jest tu test cho***263; nawet nie wiem po co go robili..
Pewnie nie ma sensu por***243;wnywa***263; dysku 160GB z 16MB cache a 500MB z 8MB cache bo wiadomo ze drugi bedzie znacznie szybszy.

I to nie tylko dlatego ze nowszy, ale dlatego ze wieksze upakowanie danych to mniejsze ruchy g***322;owicy -> mniejszy czas dost***281;pu. W skrajnym przypadku, przy mieleniu pliku 160GB ma***322;y dysk b***281;dzie cz***281;sto robi***322; full-stroke a du***380;y tylko ok 1/3 (przy za***322;o***380;eniu ze s***261; zdefragmentowane). W rzeczywsto***347;ci nawet nie 1/3 je***380;eli plik bedzie na zewn***281;trzej cz***281;***347;ci talerzy.
Wi***281;c nawet je***380;eli 160GB bedzie mial taki sam transfer i czasy dost***281;pu - przegra i to znacznie.. Cyferki to nie wszystko.

[Wawelski]

Napisany przez sobrus

Jeżeli porównujemy podobne dyski (tzn takie których prędkość samego dysku jest taka sama) to ten z większym cache jest zawsze szybszy.

Po pierwsze primo - jeżeli prędkość samego dysku (cokolwiek to oznacza) jest taka sama, to prędkość będzie taka sama niezależnie od ilości kaszki.

Po drugie primo - gęstość upakowania danych, to przede wszystkim szybkość transferu. Jak przy jednym obrocie głowica czyta 2x więcej danych, to oznacza 2x szybszy dysk (przy tej samej prędkości obrotowej).

Po trzecie primo - przy zdefragmentowanym dysku ruchy głowicy przy odczycie jednego pliku są minimalne - po to defragmentacja.

Po czwarte primo - w powyższej sytuacji (sytuacja teoretyczna) ilość kaszki nie ma znaczenia - bo nie trzeba w niej nic przechowywać. Co odczytane to trzeba przesłać magistralą do pamięci kompa.
Sytuacja A. Jeżeli magistrala jest wąskim gardłem, to kaszka się zapełni i dysk musi zwolnić odczyt - i tak cały czas będzie szło maksimum przpustowości szyny. A że wewnętrznie przez chwilę szybkość do kaszki będzie szybsza - to dla użytkownika bez znaczenia.
Sytuacja B. Jeżeli to odczyt z dysku jest wąskim gardłem - to i tak będzie szło z pełną prędkością odczytu a kaszka pozostanie pusta.

Zresztą, można sobie popatrzeć na bufor nagrywając w Nero po wyłączeniu DMA - zasada ta sama. Jak nic niemieli dyskiem, to bufor albo jest cały czas pełny (przy nagrywaniu) albo pusty (przy odczycie).

Teraz do czego przydaje się cache - oczywiście dysk nie wykonuje jednej operacji na raz. Więc jak ma pamięć podręczną, to może sobie kolejkować zadania a nie zasówać głowicą od word.exe do pagefile.sys po drodze odczytując i zapisując wiele innych plików. I dopiero wtedy cache ma znaczenie - a nie przy odczycie jednego zdefragmentowanego pliku.

Czemu zatem nie rośnie cache i czym to grozi? A no, jak zapisujesz dokument i zaniknie prąd (czy to fizycznie, czy to system uzna, że można odłączyć zasilanie) zanim dysk przeniesie go z cache na nośnik magnetyczny, to dane idą uprawiać dzikie orgie w królestwie niebytu.

[sobrus]

Do pierwszego primo - nieprawda, albo sie nie rozumiemy. Te same modele dysk***243;w r***243;***380;ni***261;ce sie kaszk***261; maj***261; r***243;***380;ne wyniki. Oczywiscie nie w odczycie sekwencyjnym, ale maj***261;. By***263; mo***380;e do kaszki wpychane s***261; dane read-ahead ? Kto wie - wyniki s***261; jednak jednoznaczne.

Do drugiego primo - to oczywiste, chcialem zwrocic uwage na to co cz***281;sto jest nieoczywiste - gestosc upakowania zmniejsza faktyczny czas dostepu

Do trzeciego primo - je***380;eli plik zajmuje ca***322;y dysk to defragmentacja nic nie pomoze bo plik jest wsz***281;dzie. Nie mowie tu oczywiscie odczycie sekwencyjnym bo tu nie ma czasu dost***281;pu...

Do czwartego primo i reszty - nigdzie w moim poscie nie mowilem o odczycie sekwencyjnym tylko o "mieleniu" du***380;ego pliku. Je***380;eli 2 dyski maj***261; tak***261; sam***261; pr***281;dko***347;***263; odczytu sekwencyjnego to oczywiscie.... jest ona taka sama

Cache ro***347;nie i dane uprawiaj***261; orgie, bowiem cache'owanie zapisu mo***380;e by***263; i cz***281;sto jest na wy***380;szym poziomie - w systemie. Na szcz***281;scie mamy teraz NTFS a nie FAT. On jest na takie rzeczy bardzo odporny dzi***281;ki transakcjom. Swoj***261; drog***261; ciekaw jestem czy w te***347;cie na benchmark.pl mieli w***322;***261;czone write-cache bo domyslnie w***322;***261;czone nie jest. I czy wy***322;***261;czenie write cache w systemie wy***322;***261;cza te***380; to w dysku (a mo***380;e w dysku jest tylko cache odczytu? prawde mowiac nie zdziwilbym sie gdyby tak bylo).