Autor: Jarek Lis (lis_at_cyber.ict.pwr.wroc.pl)
Data: Thu 05 Oct 1995 - 16:23:29 MET
Andrzej Karpinski (KARPIO_at_golem.umcs.lublin.pl) wrote:
> A tu chyba sam napisalem.
: > 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.
Z gory wyjasniam, ze nie neguje potrzeby cache, tylko twierdze,
ze programowy jest sumarycznie lepszy niz sprzetowy.
Powiedzmy - rownowartosc 5MB RAM glownej pamieci.
: > 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).
No coz, Barracudy HP byly do niedawna jedynymi, ktore przekroczyly 10,
i to nieznacznie.
: ad1: kurcze... do obslugi cache kontroler dysku ma wlasny procesor
: (moj ma 286/20MHz, widzialem tez rozwiazania z MC68040, 186 i inne)
No to zastanow sie ile procent mocy Twojego DX100 czy P135 ma to
286/20?
: oraz oprogramowanie ktore potrafi przewidziec, co bedzie w
: najblizszym czasie potrzebne, ktore czyta pewna ilosc danych na
: zapas,
Jasne. Smartdrive tego oczywiscie nie potrafi, o Unixach nie wspomne..
: ktore zapewnia prawdziwy write-back.
+ dla Ciebie, ale maly z uwagi na jednak dosc ograniczona uzytecznosc.
: 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%.
Tylko nie za bardzo rozumiem dlaczego powyzsze dotyczy sterownika z cache,
a nie dotyczy cache programowego. Ciekaw tez jestem skad te 95%?
: 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.
Z transferem prawda, IBM to spieprzyl i tylko dlatego takie sterowniki
znajduja nabywcow. EIDE czy PCI mam nadzieje likwiduje juz problem.
: 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.
Ciekaw jestem dlaczego tego nie moglby robic cache programowy?
: 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.
Smiem twierdzic, ze g... prawda. Program chce czytac sciezke 1, kontroler
ponownie to robi i z rozpedu czyta 2. Potem program chce przeczytac 1024,
i kontroler ma problem - skakac tam od razu, czy jeszcze poczytac 3 i 4?
Tak czy inaczej program stoi (to Ty napisales 'kolejno', a nie:
n rownoleglych procesow czyta dane z 1,1024,3,555,23,553,43,...) i czeka
na 1024. Jak je dostanie, to nastepnie byc moze z marszu dostanie sciezke 3,
ale na 23 naczeka sie solidnie, bo kontroler ma 1025 i nastepne na glowie.
Chyba, ze potrafisz podac algorytm przewidujacy, ze po odczycie 1, trzeba
przeskoczyc 2 i zaczytac 3, potem niezawodnym ruchem poleciec na 555,1024,
553,43,23 bo taka pewnie bedzie optymalna droga.
: 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
Hm, co prawda z liczbami sie nie dyskutuje, ale czy ten Twoj Hyperdisk
mial te 2MB? Cos mi sie nie chce wierzyc, zeby czytanie bazy danych
ktora sie w calosci miesci cache, byla szybsza z jakiegokolwiek
sterownika niz po prostu z RAM. Fakt - zapisy moga nieco popsuc sprawe.
: 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.
A nie lepiej zorganizowac EMS na tych 2MB przelozonych ze sterownika
do plyty glownej?
: podobnych rzeczy jest sporo - najogolniej, jesli chodzi o wydajnosc,
: to najlepsze efekty daje polaczenie stosunkowo malego i prostego
: buforka programowego ze sprzetowym kontrolerem.
A bardziej mnie ciekawia wyniki duzego RAM Smartdrive/Hyperdisk/..
+ Tekram z minimalna pamiecia. Bo faktycznie, najbardziej obciaza procesor
transfer po ISA czy nawet VLB z/do dysku. I jakies urzadzenie (PCI bridge?)
ktore te dane wymieni blyskawicznie z procesorem, a na spokojnie z HDD.
Chyba, ze wreszcie dyski zaczna przyzwoicie robic, i ich tranfer do cache
wewnetrznego bedzie np. 20MB/s - niby dlaczego nie.
: 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...
Chyba nie do konca. Zapis 4MB na dysk faktycznie pochlonie 4 s, nawet
z kontrolerem cache, w czasie ktorych, procesor:
1. Jest obciazony w ~70% - jesli korzystamy z ISA,
2. Jest obciazony w 25% - jesli mamy VLB,
3. pewnie mniej, dla jeszcze nowszych rozwiazan.
Caly czas zakladam, ze te 4MB trafily do cache programowego, a potem
sa cierpliwie i na przerwaniach wrzucane do dysku...
Jaroslaw Lis
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 12:25:33 MET DST