Autor: Krzysztof Halasa (khc_at_hq.pm.waw.pl)
Data: Thu 05 Oct 1995 - 14:05:38 MET
Czesc,
Andrzej Karpinski (KARPIO_at_golem.umcs.lublin.pl) wrote:
> nie wydaje mi sie, zeby zakup dodatkowego 1-2mb ram obciazyl kogos w
> znaczacy sposob. tak samo zakup kontrolera za 3 mln w
> porowananiu z cena komputera powiedzmy 40-50mln. mozemy wiec chyba
> pominac sprawy cenowe w dalszych rozwazaniach - przyznalem przeciez,
> ze cache-kontrolery naleza do drozszej grupy rozwiazan.
Watpie... Do drozszych rozwiazan naleza dyski wide fast scsi, albo np. raid 5.
Ale to nie jest istotne.
> ad1: kurcze... do obslugi cache kontroler dysku ma wlasny procesor
> (moj ma 286/20MHz, widzialem tez rozwiazania z MC68040, 186 i inne)
> oraz oprogramowanie ktore potrafi przewidziec, co bedzie w
> najblizszym czasie potrzebne, ktore czyta pewna ilosc danych na
> zapas, ktore zapewnia prawdziwy write-back.
Dokladnie tak samo (lub gorzej) jak system operacyjny maszyny.
> cache dysku to nie ram-
> dysk, ze do zapewnienia pelnej predkosci potrzeba pamieci o wielkosci
> rownej wielkosci dysku. zakladajac, ze operujemy na danych wielkosci
> 30mb, 2mb cache zapewnia ponad 95% wspolczynnik trafien przy
> odczytach, a przy zapisach pod warunkiem ze pliki nie beda wieksze
> niz wielkosc cache bedzie to dokladnie 100%.
Oczywiscie, tak samo jak w przypadku cache programowego w RAMie maszyny.
Z tym ze system operacyjny moze miec wiecej informacji nt. zawartosci dyskow,
co zwiekszy jego efektywnosc w porownaniu z cachujacym sterownikiem.
> kilka spraw jeszcze:
> 1) ze wzgledu na to, ze kontroler ma wlasny procesor przeszukiwanie i
> transfer cache nie obciazaja procesora glownego i wykonuja sie
> szybciej.
Niekoniecznie.
1. Transfer pomiedzy RAM komputera i CPU moze byc znacznie szybszy
niz pomiedzy np. RAM i CPU oraz sterownikiem.
2. Sterownik cachujacy wprowadza wlasny narzut czasowy, co m.in. powoduje ze
transfer dysk->komputer jest nizszy niz przy uzyciu prostego, nieinteligentnego
sterownika.
3. Nieobciazanie procesora glownego moze miec miejsce w systemach
wielozadaniowych, natomiast w przypadku np. DOSa czy Windosa (a dla nich sa
przeznaczone programy typu hyperdisk) caly system i tak bedzie bezczynnie
czekal na transfer z dysku - roznica bedzie tylko zwiazana z buforowaniem
zapisu (zwykle kilka % operacji to zapisy). Mozliwe, ze wewnetrzne bufory
dysku poradza sobie z zapisem lepiej niz sterownik cachujacy (zwykle jest
to mala ilosc danych).
> 2) cache kontroler jest swiadomy tego w jakim srodowisku pracuje
> (jesli mamy stosowane drivery) i potrafi np. trzymac caly czas w
> pamieci FAT (lub odpowiedniki w innych systemach) przez co nie trzeba
> jezdzic glowica po dysku - szybciej wyszukiwane sa pliki.
Naprawde? W takim razie to naprawde madry sterownik, chociaz sens trzymania
FAT caly czas w pamieci jest IMHO mocno watpliwy.
> 3) jesli np. mamy odczytac kolejno dane ze sciezki 1, potem 1024,
> potem 3, potem 555, potem 23, potem 553, potem 43 to cache kontroler
> wykona jeden ruch: najpierw 1 potem 3 potem 23, 43, 553, 555, 1024 -
> optymalizowane i minimalizowane sa ruchy glowic co daje widoczne
> przyspieszenie i wyciszenie ( :)) ) dysku.
Hmmm... W DOSie??? W/g mnie odczyt bedzie 1-1024-3 itd. Skad sterownik
bedzie wiedzial ze bedzie potrzebowal sciezek 3, 23, 43 itd??? Watpie
zeby zrobil to jako looking-ahead.
Cos takiego moze nastapic w systemie wielozadaniowym, gdzie (prawie)
jednoczesnie jest wiele requestow dostepu, i mozna je poustawiac w bardziej
logicznej kolejnosci (systemy operacyjne robia to od dawna).
> 4) zauwazmy co sie dzieje, jesli np. bawimy sie baza danych.
> przyjmijmy, ze potrzebujemy dostepu do jakiejs jej czesci - powiedzmy
> o wielkosci 1.6mb. plik siedzi W CALOSCI w cache kontrolera i nawet
> bardzo czeste operacje na nim, nie beda powodowaly koniecznosci
> dostepu do dysku. przykladowe wyniki testow: reindexowanie i
> sprawdzanie porpawnosci bazy danych o userach, plikach itd w moim bbs:
> 1) bez zadnego cache : 14.34
> 2) z hyperdiskiem 4.31 (direct transfer, 386) : 3.02
> 3) z cache kontrolerem (tekram, 286/20, 1mb) : 2.31
> 4) z 2 i 3 jednoczesnie : 1.42
Wniosek - duzo zapisow, maly cache programowy, kiepski cache programowy.
Szczerze mowiac mysle, ze ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^.
> inny przyklad: programik emstest - zaklada na dysku plik o
> niewielkim rozmiarze i nastepnie kolejno zapisuje i wczytuje z niego
> kolejne strony ems. w przypadku korzystania z cache kontrolera
> podczas calego testu nie nastapil ani jeden dostep do dysku. operacja
> wykonywala sie 8s. po wylaczeniu cache to samo zajelo poltorej minuty.
emstest? Czy to przypadkiem nie jest test pamieci EMS, nie majacej wiele
wspolnego z dostepami do dysku? Poza tym EMS w roku 1995... Pamietam to
z IBM-PC (byly to takie dlugie karty zapelnione malymi DRAMami).
> 5) najwiecej zyskuje sie na zapisach i dostepach do tych samych
> danych - a takie sytuacje zdarzaja sie najczesciej
Podobnie jak w softwarowych cachach.
> podobnych rzeczy jest sporo - najogolniej, jesli chodzi o wydajnosc,
> to najlepsze efekty daje polaczenie stosunkowo malego i prostego
> buforka programowego ze sprzetowym kontrolerem. prosze zapytac o
> rezultaty np. Grzeska Staniaka czy Krzysia Mlynarskiego, albo np.
> Piotrka Kucharskiego - bawili sie moim sprzetem. Roznica jest
> naprawde o rzad wielkosci i w rzeczywistej pracy nie podlego dyskusji.
No coz... Ja stosuje dosc duzy cache programowy (tzn. caly RAM - uzyty RAM
- maly margines na male malloc()'e) i nie narzekam na czeste swiecenie dysku
ani na maly transfer.
> otoz przy zapisach zysk ze stosowania kontrolera jest najwiekszy -
> zobacz co sie dzieje jak masz cache programowy - w przypadku
> przepelnienia wszystko jest zatrzymywane. w przypadku cache
> sprzetowego wrecz przeciwnie - cache jest zapisywany a procesor w tym
> czasie moze liczyc - a zastanow sie ile czasu potrzeba na zapis 4mb
> cache... 4s!!! 4s podczas ktorych procesor musi cierpliwie czekac...
Owszem, pod DOSem, i w przypadku zapisywania 4MB danych. Normalnie jednak
zapis 4MB danych wiaze sie z odczytem >40MB danych, co moze skutecznie
wyflushowac cache. I tak system bedzie wisial na dyskach, a transfer z dysku
bedzie mniejszy niz bez semi-hardwarowego write-backu.
Pod normalnym system operacyjnym CPU nie bedzie czekal na zapis - zreszta
w DOSie tez powinno dac sie to zrobic - moze jakas DOS-kasza to potrafi?
> 4) zalezy nam na naprawe duzej wydajnosci :)
:((( To nie kupujemy niczego z napisem IDE.
PS. Co sie dzieje jesli ktos uzywa pamieci wirtualnej - czy tez jest
cachowana w sterowniku ?
Greetings,
KHC
--------------------------------------------------------------------
Krzysztof Halasa
Network Administrator of The Palace of Youth in Warsaw
Palac Mlodziezy Internet: khc_at_pm.waw.pl
ul. Swietokrzyska Fidonet: KHC, 2:480/40
00-901 Warsaw, Poland
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 12:25:33 MET DST