Autor: Andrzej Karpinski (KARPIO_at_golem.umcs.lublin.pl)
Data: Tue 10 Oct 1995 - 12:36:11 MET
> Czemu? Bo widzisz, cache softwareowy jest najblizej procesora. Prawie
> pod reka. I dostep do niego niewiele kosztuje. Cache na sterowniku
> VLB jest juz ciut dalej, i zwykle dojscie do niego jest okupione
> jakims tam oczekiwaniem. Cache na dysku jest dosc daleko, po drodze sa
> elementy o predkosci nie najwiekszej. A druga uwaga - w Twoim tescie
> jesli nie testowales wylacznie zapisow o dlugosci 1.1MB, to w
> zasadzie cache w Caviarze nie dzialal. Cache sie tak trywialnie nie dodaja.
> Przy czytaniu to co jest w cache dyskowym jest tez w cache kontrolera.
> A ze ten drugi jest wiekszy, to z dyskowego juz nie skorzystasz - nie bedzie
> okazji.
widzisz, porownajmy dysk do ramu - taka mala analogia.
w procesorze siedzi cache l1, na plycie wolniejszy cache l2 i w
samych ramach (jesli np. sa edo) siedzi jeszcze jeden poziom cacheu i
wreszcie jest sam ram. z dyskami jest podobnie - siedzi cache
programowy, ktory zwykle jest najszybszy, siedzi cache l2, czyli
cache na kontrolerze - ktory takze powoduje widoczny wzrost
wydajnosci, i wreszcie siedzi cache (nazwijmy go l3) w samym dysku.
zasada jest prosta - im mniej dostepow do samego dysku - tym lepiej.
z drugiej strony wiemy, ze zwiekszanie wielkosci ktoregokolwiek z
poziomow cache powyzej pewnej wielkosci nie powoduje juz wlasciwie
dalszego wzrostu wydajnosci. dla normalnej pracy i dyskow wydaje mi
sie, ze taka granica jest mniej wiecej 4mb-6mb. dalsze zwiekszanie
wielkosci niewiele daje. w takim przypadku oplaca sie wiec bardziej
zainwestowac pieniazki w cache l2 (czyli cache-kontroler).
wspolczynnik trafien cache programowego wynosic wiec bedzie ponad
95%, a reszta zapisow bedzie bezposrednio do kontrolera. i tu
sytuacja analogiczna - wspolczynnik trafien wynosi ponad 95% a reszta
idzie do dysku, gdzie z kolei niewielka czesc danych siedzi "na
zapas" w buforze. daje to naprawde widoczne przyspieszenie w
porowanaiu ze stosowaniem samego cache progrmowego i nawet 0.5mb
cache na kontrolerze bedzie widac. oczywiscie nie mozemy porownywac
rozwiazan przy niewielkiej ilosci pamieci - takze ze wzgledu na
koszty. jednak przy podanych przeze mnie wilkosciach (powiedzmy juz
przy 4mb cache programowego) rozwiazanie zaczyna miec sens. nalezy
takze zwrocic uwage, na sposob obslugi cache - przy duzych dyskach
cluster ma 4, czesem wiecej kb... nie ma wiec sensu ustawianie cache
line size na 512b (standardowe ustawienie wiekszosci kontrolerow), bo
bedziemy bez potrzeby przegladac 16x wiecej linii niz w przypadku
ustawienia np. 8k, nie uzyskujac ani troche wiekszego wspolczynnika
trafien. przyklad: tekram przy blokach 512k osiaga cos kolo 7mb/s, a
przy 8k ponad 19... mysle, ze czesc osob moze miec nienajlepsze
zdanie nt. cache kontrolerow takze poprzez niewlasciwie ustawnienie
tego parametru.
> : podalem wyniki takiego testu i wyraznie bylo widac przewage punktu 2.
> : jesli chcesz to jeszcze raz ci przytocze wyniki. najwieksze korzysci
> : ze stosowania cache kontrolera widac bylo wlasnie przy rownoczesnym
> : stosowaniu cache programowego.
>
> Naprawde? Wierzyc mi sie nie chce. Rozumialbym wyniki przy zwyklej
> ISA, ale tak jak wyzej? Chyba wpisze NCR810 na swoja prywatna czarna liste.
dokladnie byly takie jak mowie, i dziwic sie nie nalezy - ram bedzie
zawsze szybszy od dysku i chyba nic na to nie poradzimy. jesli
kontroler zapewni chocby 50% trafien to przyspieszenie bedzie
widoczne (a jak mowilem - w normalnej pracy zapewnia ponad 90%).
nawaisem mowiac istenieja cache kontrolery scsi - lacza zlety
sprzetowego cache i scsi - niestety takze pieniazki sie dodaje (a
wlasciwie to chyba nawet mnozy, choc nie wiem czemu :)) ).
> : widzisz, nawet jakbys stanal na glowie to z isowego kontrolera
> : wycisniesz najwyzej 1.5mb/s (jesli nawet wiecej to niewiele).
> : mysle, ze to wyjasnia wszystko, bo jak zestawisz to z 20mb/s przy vlb
> : to roznica jest dosc oczywista.
>
> Smiem twierdzic, ze byla niewielka. Bardzo malo modeli dyskow jeszcze
> nie tak dawno przekraczalo 1.5MB/s rzeczywistego transferu.
> (Obecnie wiekszosc popularnych jest ponizej 3MB/s). Pisze o transferze
> z nosnika, a nie z cache dysku. Tak wiec swoimi 20MB/s (wlasnie, bajty czy
> bity?) mozesz sie jedynie pochwalic przed znajomymi, a nie powachac
> w normalnej pracy.
sorry - wiekszosc plikow na ktorych pracujemy ma wielkosc do 5mb.
czyli mieszcza sie w 100% w cache podczas operacji na nich. zwlaszcza
jesli wiele razy siegamy do tego samego pliku przyspieszenie bedzie
wyrazne (np. przy bazowaniu danych). i to widac w normalnej pracy -
nie tylko na testach przy znajomych :)
> Ciekaw jestem, jak by wygladaly te testy z:
> 3) komputer z 9.5MB (10, 0.5 zjedzone przez cokolwiek),
> cache kontorler z 0.5MB, 4MB cache programowego.
> 4) zestaw jak 1, ale cache kontrolera zmniejszony do 0.5MB.
wlasciwie to wczesniej na to odpwowiedzialem
> Aha - jeszcze pytanie jakie testy?
ja mierzylem czas wykonywania clean-up'u w swoim bbs, bo jest sporo
operacji dyskowych i sumarycznie rozmiar plikow znacznie przekracza
wielkosc cache. przy okazji procesor jest tez troszke obciazony -
wydawalo mi sie, ze to bedzie bardziej miarodajne niz jakis checkit.
> Wystarczajaca ilosc cache, to taka na dwie sciezki. Co by dysk mogl
> cala przeczytac, i ewentualnie zaczac nastepna. W dzisiejszych czasach
> to tak chyba z 64-128KB. Wiecej nie potrzeba, bo:
> 1. z uwagi na niezbedny wolny transfer po kablach i tak trzeba
> dawac cache blizej procesora,
> 2. zgodnie z (moja?) teoria, ten drugi cache i tak przykryje ten dyskowy.
cache kontroler potrafi rozpoznac rodzaj cache w NIEKTORYCH dyskach -
zreszta jest to wyraznie odnotowane w setupie kontrolera (u mnie
podaje dokladnie organizacje i sposob pracy cache w caviarze).
wnioskuje wiec z tego, ze skoro producent zadal sobie trud
sprawdzenia i wyswietlenia informacji o cache dysku to ja jakos
wykorzystuje potem w pracy i np. nie trzyma tych samych danych w
cacheu kontrolera i w cache dysku (to takze moja teoria, ale chyba
sluszna).
> Hm, w dzisiejszych czasach? Ile kosztuje karta z FIFO? A ile 386DX.
heh - a w ktorym miejscu ja pisalem o predkosci karty? cache
kontroler nie przesyla danych z dysku (bezposrednio) z niewiadomo
jaka predkoscia - on je jedynie buforuje w sposob powiedzmy
inteligentny, fifo robi to samo - buforuje (tu akurat inteligencja
jakby w zaniku, ale.. nawiasem mowiac widzialem karte i/o z wlasnym
procesorem i 1k buforka, choc szczerze mowiac nie wiem po jaka
cholere - na razie fifo mi w zupelnosci wystarcza... nawet przy
jednoczesnej pracy kilku(nastu) modemow).
[to mialo byc wyzej, ale zapomnialem jak sie kopiowalo bloki w tym
edytorze ;)) ]
> Ona wcale nie jest szybsza. Ona tylko mniej procesorowi przeszkadza.
> Nawiasem mowiac, to nie jest wina karty czy procesora, ale raczej
> dennego softwaru, ktory nie moze sobie poradzic z glupimi 4kHz przerwan.
> A propos, dysk z buforem (FIFO?) na 8 sektorow, przy powiedzmy 5MB/s,
> generuje 1200 przerwan/s. Tyle co modem 9600.
> : 2) wyobrazmy sobie teraz komputer, z modemem 14400 z programowa
> : kompresja. i drugi ze sprzetowa. ktory przypadek wybierasz? w
> : pierwszym mamy powiedzmy trzykrotnie wydajniejszy procesor, a
> : komputer bedzie uzywany do prowadzenia bbs.
> Hm, komputer dedykowany do bbs. Czy ja dobrze rozumiem, ze w tym momencie
> nie interesuje mnie ile % CPU sie marnuje, pod warunkiem ze modemy
> zdazy obsluzyc? To przy dzisiejszych cenach moze sie okazac, ze taniej
> kupic szybszy komputer niz modemy z V.42...
hehe - powiedz to dowolnemu sysopowi ktory umie wiecej niz tylko
powiedziec "lame", "rulez" i wykonac delete-account (ew.
przekopiowac od innego sysopa skonfigurowana ramote - znam takie
przypadki... ;) ).
> Jesli masz 8900 na ISA, to pewnie zysk bedzie. Ale przy VLB..
> Ogromne ilosci odcinkow - to znaczy ze one sa krotkie. A to znaczy,
> ze bardziej oplacalne moze byc narysowanie ich procesorem glownym,
> niz pchanie wspolrzednych do akceleratora. Nie musi, ale MOZE.
widzisz, akurat przy cadach akcelerator jest zawsze skuteczniejszy niz
szybki dostep do pamieci - to jeden z nielicznych przypadkow.
nawiasem mowiac caly czas podczas naszej dyskusji o kartach z
gregoriem ubezpieczalem sie, piszac o typowych zastosowaniach, do
ktorych moim zdaniem katowanie komputera skomplikowanymi cadami nie
nalezy ;)
> : 4) chyba nie musze mowic, ze dokladnie tak samo wyglada sprawa z
> : dyskami - podobnie jak poprzednio chodzi o zwiekszenie predkosci i
> : odciazenie procesora, co cache kontroler robi i to z niezlym wynikiem.
> Hm, bez dokladniejszej arytmetyki, to ja bym sie nie odwazyl tak stwierdzic.
> Bo moze sie okazac, ze odciazasz 1% procesora..
z 1% to przesadziles... napewno nie jest to powiedzmy 70 ale
takze nie 1... wiesz, statystycznie rzecz biorac, cache l2 na plycie
glownej takze odciaza procesor w podobnym stopniu. w dodatku kosztuje
kupe pieniedzy (taniej wychodzi naprawde zdrowy upgrade procesora), a
mimo wszystko sie ja stosuje... bo w normalnej pracy okazuje sie, ze
sam procesor to nie wszystko.
pozdrawiam i mam nadzieje ze choc troche was przekonalem :) a jak nie
to powywalajcie cache z plyt glownych i sprawcie sobie upgrade
procesora...
karpio
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 12:25:44 MET DST