Autor: Jarek Lis (lis_at_cyber.ict.pwr.wroc.pl)
Data: Tue 10 Oct 1995 - 15:26:10 MET
> > 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.
2Niedokladne stwierdzenie. Idealem jest oczywiscie cache o pojemnosci
rownej wszyskim powszechnie uzywanym danym. Tak, zeby to co zdarza Ci
sie czytac dwa razy, po pierwszym czytaniu pozostawalo w cache.
Ciut nizszy stopien jest wtedy, jesli masz czesto uzywane obszary, i mniej
czesto. I chodzi o to, zeby czytanie takiego mniej popularnego
o2bszaru nie musialo wyrzucac z cache obszarow bardziej popularnych.
Zakladajac, ze tych bardziej popularnych masz np. 2MB, a te rzadziej popularne
sa czytane w paczkach po 1MB, to mozna sie zastanowic nad ~3MB cache.
To mocno zalezy od tego, co nazywasz normalna praca. Jesli np. pracuje
BC++ pod DOS, to porzeba mi jakies 2-3MB (includy, biblioteki, zrodla,
moje obj i exe). Jesli mam zwyczaj wychodzid do DOS, to trzeba dodac
ze 300KB na NC i 1MB na BC. Przy Windows to bedzie wiecej.
Zgadzam sie z Toba, ze obecnie wyglada na to, ze 4-6MB to rozsadny wybor,
choc z drugiej strony, przy ~10MB pamieci nie jestem pewny, czy cache
jest potrzebny do Windows. No moze z 1MB
> 2w 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.
Ejze. Zastanow sie, jak dziala cache, na razie tylko przy odczycie.
Dane, ktore sa z/a/dane, po przeczytaniu sa zapamietywane, i przy
nastepnym z/a/daniu leca z pamieci.
To przy 2MB cache programowego i 2MB c w sterowniku i 128kB c w dysku,
co sie stanie po przeczytaniu powiedzmy 1.5MB? Ano, rezyduje
w cp, rezyduje w ck , i ostatnie 128KB rezyduje w dysku. Chyba, ze
masz bardzo sprytne oprogramowanie, czego nie podejrzewam. I jak czytasz
jeden z poprzednich sektorow, to skad jest brany? z cp, bo jest. A jak
tam nie ma, to i w ck nie ma. Analogia do plyty procesora jest o tyle
chybiona, ze tam jest L1 8 czy 16 KB, a L2 256!. Gdybys stosowal
np. 0.5MB cp, 4MB ck i dysk (juz raczej tablica Raid) z 32MB c. to by
to bylo uzasadnione, choc nadal twierdze, ze lepiej byloby wrzucic 4MB
na plyte. Analogicznie - po co Ci L2 cache, gdyby 486 mial wbudowane nie 8,
a 256KB cache?
> daje to naprawde widoczne przyspieszenie w
> porowanaiu ze stosowaniem samego cache progrmowego i nawet 0.5mb
> cache na kontrolerze bedzie widac.
I chyba o to chodzi. To nie obsluga cache zuzywa procesor, tylko
jak juz dysk przeczyta dane, to je potem wysyla z predkoscia ~5MB/s,
choc byc moze potrafi nieco szybciej (kiedys przyspieszylem jakis dysk,
i zaczal robic bledy, wstyd, bo to byl Caviar). Dla procesora, ktory
czyta to rozkazem rep insw, ta predkosc jest sporo za wolna. Procesor
nie jest zajety obliczaniem czegos, ale czekaniem pomiedzy poszczegolnymi
slowami. Gdyby po drodze wstawic maly buforek, ktory zgromadzi dane i
z dysku (powoli) i szybko podesle procesorowi, to bedzie zysk. Nie
w transferze, tylko w % zajetosci CPU. I prawdopodobnie
ten Twoj sterownik taka role spelnia. Tylko ze:
1. Do tego to on potrzebuje 32KB, a nie 2MB
2. Jak zrobia dyski z mniejszymi oczekiwaniami ( a pewnie nie ma problemu,
tylko na wszelki wypadek takie opoznienia dali, to kontroler
niewiele juz da.
3. W PCI taki bufor jest przewidziany...
>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.
Ty nie przeceniaj transferu. Ten transfer masz z cache, a nie dyskiem.
I 7 vs 19 w zasadzie mowi, jaki jest narzut innych operacji. I to
niekoniecznie na procesorze glownym - to moze byc narzut na tym kontrolerze.
Zanim on znajdzie gdzie ma sektory, ustawi DMA, zglosi gotowosc, to troche
czasu minie.
> > 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.
No tak, ale ciagle miales 2MB cp? Ja po prostu zakladam, ze NCR spelnia
role takiego buforka. Transferu nie przyspieszy, ale procesor troche odciazy.
> > 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 :)
Pod kilkoma warunkami
1. Nie uzywasz cp, lub uzywasz za maly.
2. ck masz taki, ze Ci sie wszystkie dane pomieszcza.
> > 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
I jak to wyglada 1 vs 4? Czyli komputer ten sam, dysk ten sam, 2MB cp,
a ck raz 2MB a za drugim razem 0.5MB?
> > 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.
Test dobry, choc osobiscie wolabym np. czas kompilacji czegos sredniego
pod BC++, albo czas startu Worda i np reformatowania tekstu.
> 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).
Watpie. W kilku miejscach watpie.
1. Nie wiem czy jest sens myslec o tych 0.064-0.25 MB, jesli pod reka
mamy 2MB.
2. Nie znam zadnych komend do sterowania cachem w dyskach.
Fakt, ze nowe dyski sa dosc tajemnicze, ale prawdopodobnie jedyna
opcja do cache to jest tylko 'wylacz write cache'. Dalej, zastanow
sie, jak by takie wspoldzialanie mialo wygladac?
Dysk potrzebuje cache na cala jedna sciezke. Reszte faktycznie mozna
wykorzystac. Tylko jak?
Nie notowac nowo czytanych danych (wtedy najnowsze dane sa cd, a
ciut starsze w ck)? toz to glupota, bo dostep do nowych danych
mamy wolny.
Trzymac starsze dane w dysku? Ba, jak to zrobic? To musialbys
przeczytac troche danych, potem wyslac cos na ksztalt 'lock extra cache
buffers' (extra - bo na jedna sciezke potrzebujesz). Dalsze dane
cachujesz w kontrolerze, a w razie czego siegasz do dysku. No tak,
ale w pewnym momencie trzeba je zmienic, wiec albo twoj
kontroler sle to do cache'a, albo kaze dyskowi jeszcze raz przeczytac
potrzebne fragmenty..
Tylko cos nie slyszalem o 'lock cache' czy 'store to cache'..
> > 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).
Ja pisalem dokladnie o modemie. Przyklad dales dobry - szybszy procesor
czy FIFO na modemie? Osobiscie wybieram tani modem z FIFO,
bo pewnie jakbym mial porownywac ceny, to by wyszlo, ze karta z FIFO jest
drozsza niz wystarczajaco szybki procesor..
> > 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 ;)
A ja tam ciagle nie jestem taki pewny. Po prostu z praktyki elektronicznej
wiem, ze glupie wyslanie danych do graficznego ko-procesora kosztuje
cenny czas. I jesli mamy duzo malych linii, to ten czas moze byc dluzszy
przy wysylaniu niz przy samodzielnym rysowaniu.
> > : 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...
Miedzy 1 a 70.. Duze pole do popisu, biorac pod uwage, ze granica satysfakcji
jest pewnie w okolicach 5%. Hm, ciekawe ile instrukcji wymaga
znalezienie gdzie znajduje sie jeden z 4MB sektorow...
> pozdrawiam i mam nadzieje ze choc troche was przekonalem :) a jak nie
> to powywalajcie cache z plyt glownych i sprawcie sobie upgrade
> procesora...
> karpio
Tak a propos przekonania, to w pl.ogloszenia.sprzedam jest oferta
kogos z Lublina na Tekrama. Nie przychodzil ostatnio do Ciebie potestowac?
Pozdrowienia,
Jarek
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 12:25:45 MET DST