Autor: Gregorio Kus (Grego_at_RMnet.IT)
Data: Tue 03 Oct 1995 - 20:21:37 MET
On Tue, 3 Oct 1995 13:45:56 +0100 Andrzej Karpinski wrote:
>> Cached controller oplaca sie wylacznie wtedy gdy mamy w zapasie
>> jakies stare SIMM'y do ktorych nie mamy zastosowania (np. 30pinowe,
>> a motherboard mamy na 72). A i wtedy jedynie w przypadku jesli
>> sterownik kupimy naprawde tanio. We wszystkich innych przypadkach
>> bardziej oplaca sie wlozyc ta sama pamiec do slotow na plycie-matce
>> niz marnowac ja w controller'ze. >
>zupelnie sie nie zgadzam z tym co piszesz o cache controlerach.
To nie ja pisalem, ja tylko cytowalem PC Professionale.
>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.
Nie "mniej wiecej" ale dokladnie z tego samego cylindra.
A to zdarza sie wystarczajaco rzadko by pominac to w rozwazaniach.
>czysty transfer (cache function disabled) z mojego caviara (wdac
>2420, 128k int-cache flow2) z tym kontrolerem to 1.5-2mb/s (zalezy
>jaki program testujacy), transfer miedzy dyskiem a kontrolerem - pio3
>z mozliwoscia transmisji blokowych (caviarki to potrafia).
[potrafi to i moj "inexpensive" IBM]
>dodatkowo
>czesto masz rozne inne funkcje (mirror, sprawdzanie dyskow,
>linking, kompresja hardwareowa). najlepiej to widac przy zapisie
>niewielkich plikow (tak do 0.bmb) - roznica jest o rzad wielkosci.
>zwroc tez uwage na to, ze przy programowym cache procesor jest
>zupelnie niezle obciazony jego obsluga (glowny procesor), poza tym
Przy pio procesor jest i tak obciazony
jedynie dma modes ATA2 go odciazaja
>wydajnosc powinna byc jeszcze lepsza. poza tym sprawdzalem - i nikt
>mi sie powie, ze wstaiwnie 1mb dla smartdrive da porownywalna
>predkosc co wstawienie 1mb cache do tekrama :) a najlepszy dowod:
Napisalem wyraznie:
>>Oczywiscie byla mowa o "prawdziwych"
>> cache-controlerach, z 4MB np,
oraz:
>>Uwaga: ich rozwazania dotyczyly systemow z inteligentna
>> obsluga calego file system (Netware, OS/2, Unix) a nie czegos
>> w rodzaju windoze.
wiec co ma do rzeczy 1MB smartdrive.
Najistotniejsze jest wlasnie to: inteligentna obsluga file systemu.
Mnie tam transfer rate "nie rusza", bo ogromna wiekszosc czasu
traconego na obsluge dysku tracimy czekajac na to, az glowica znajdzie
sie nad danymi. Dobry system operacyjny WIE jakie (i skad ) dane beda
mu
potrzebne, wie kiedy jest mniej obciazony i moze sobie pozwolic na
oproznienie cache'a, wie ktore sektory lepiej pozostawic w cache'u
mimo, iz nie byly ostatnio uzywane. Ten ostatni czynnik jest bardzo
wazny - jesli zostawisz cache systemu operacyjnego po to by mu
pozwolic przechowywac dane (sektory) organizacyjne - to marnujesz
pamiec (podwojne cache'owanie), jesli mu nie zostawisz, to obojetnie
jakiz-to-procesor-nie-bedzie-zainstalowany na "inteligentnym
sterowniku" nie przewidzi on, ktore sektory sa "organizacyjne", a
ktore z wlasciwymi danymi. Dodatkowy zysk z WIEDZY o tym co jest w
danym sektorze, wystepuje przy swappingu. Znow jedynie s.o. wie, ktore
sektory zawieraja pamiec wirtualna - i jest to wiedza, ktora potrafi
wykorzystac. [Oczywiscie S.O., nie windoze czy dos]
Mozna by tak jeszcze dlugo. Najlepiej byloby gdybym przepisal tutaj
caly artykul. Wybaczcie... troche mi sie nie chce. Reasumujac:
argumenty w nim umieszczone (a byla to polemika wlasnie z tymi
argumentami jakie podal Andrzej) MNIE osobiscie przekonaly.
Nikt z nas (albo NAPRAWDE nieliczni) nie ma nieograniczonych zasobow
finansowych. Moze, gdybym mogl sobie pozwolic na WSZYSTKO co najlepsze
dla mojego "elaboratore" - kupil bym mu jakiegos tekrama. Majac jednak
do wyboru inteligentny kontroler z 4MB ram albo 8MB pamieci glownej,
(koszt porownywalny) wybiore zdecydowanie 8MB i obejde sie bez
tekrama.
Grego
P.S.
>zupelnie sie nie zgadzam z tym co piszesz o cache controlerach.
Twoje stwierdzenia sa zawsze porazajaco kategoryczne. Ja zaledwie
niezupelnie sie zgadzam z tym co Ty napisales.
:-)
/-------------------------------------------------
Gregorio Kus Grego_at_RMnet.it G.Kus_at_agora.stm.it
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 12:25:27 MET DST