Autor: Andrzej Karpinski (KARPIO_at_golem.umcs.lublin.pl)
Data: Thu 05 Oct 1995 - 12:41:31 MET
Hi!
> A ja sie zgodze. Wtryniac simy w kontroler (poza specyficznymi
> przypadkami) jest sens tylko wtedy, jesli nie mozemy ich sprzedac
> lub wymienic na pasujace do naszej plyty glownej.
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. jesli
uzytkownikowi zalezy jednak na wydajnosci to nie zawsze cena jest
jedynym kryterium wyboru, a zysk ze stosowania takich kontrolerow
zaraz przedstawie...
> : przede wszystkim wydajnosc - dla malych plikow, jesli sa czytane
> : mniej wiecej z tego samego obszaru dysku (powiedzmy z 20-30mb) i masz
> : dobry kontroler to zapewni ci on transfer na poziomie 15-20mb/s.
>
> A owszem - zapewni. Pod warunkiem, ze:
> 1. masz w kontrolerze te 20-30MB ram (ale wtedy nadal lepiej je wtrynic
> w plyte glowna, bo wtedy masz transfer ze 40MB/s jesli nie wiecej)lub:
> 2. dysponujesz dyskiem z wewnetrznym transferem rzedu 15-20MB.
> Takich chyba jeszcze nie wyprodukowano.
ad2: nie bylbym pewnien, choc faktycznie nie korzxystalem jeszcze z
tak szybkich dyskow. max. transfer ciagly jaki widzialem to bylo cos
kolo 5mb/s (bez cacheowania i innych wynalazkow).
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. 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%.
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.
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.
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.
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
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.
5) najwiecej zyskuje sie na zapisach i dostepach do tych samych
danych - a takie sytuacje zdarzaja sie najczesciej
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.
> A moj koronny argument to fakt, ze w typowym systemie (nawet w
> przeczytane dane trafiaja do softwarowego cache'u, i do cache
> system nie siegnie, dopoki ma wystarczajaco pamieci. A jak mamy dolozyc
> RAM, to chyba lepiej na plyte glowna, bo to i transfer wiekszy, i nie tylko
> na cache mozna wykorzystac. A przy zapisie, to na poczatek pomoze
> maly cache w dysku..
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...
> Kontroler z cachem jest przydatny jesli:
> 1). zalezy nam na mocy obliczeniowej i uzywamy kontrolera jako
> 'ko-procesora' do obslugi dyskow. Obsluga cache, podejrzewam,
> potrafi pochlonac troche mocy obliczeniowej. Pare %, ale jesli
> wlasnie o te pare % chodzi? W praktyce lepiej oczywiscie
> dokonac upgrade procesora na szybszy.
>
> 2). Nie da sie wsadzic wiecej pamieci w plyte....
>
> 3). Uzywamy kontrolera jako szybkiego 'bufora' na tych pare sektorow.
> No coz - tu zysk solidniejszy. Podstawowa strata przy
> obsludze dyskow, to cykle oczekiwania. Najpierw przy ISA
> transfer z dysku pochlanial praktycznie caly procesor z uwagi
> na wolna magistrale. Potem przy VLB szybkosc ograniczal dysk,
> bo szybkosc dostepu do jego cache byla mala (szybki nie musial byc
> bo przeciez magistrala wolna...). Wiec jest sens uzyc kontrolera,
> ktory zbuforuje sektor (lepiej kilka) i blyskawicznie podesle
> procesorowi. Ewentualnie uzyje DMA. Zauwacie, ze ten kontroler
> wcale nie musi miec funkcji cachujacych.
> Ta potrzeba znika, jesli mamy dysk z szybkim 'burst mode' lub PCI..
4) zalezy nam na naprawe duzej wydajnosci :)
karpio
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 12:25:32 MET DST