Kako se cache diska pozna na hitrosti?

Commodore

Fizikalc
14. jul 2008
1.977
40
48
Razmisljam, da bi si nabavil zunanji disk WD Elements 1.5 TB, vendar me je na prvi pogled zmotil podatek, da ima le 8 MB cache. Kako se to dandanasnji pozna na hitrosti (uporaba, premikanje/kopiranje podatkov...) v primerjavi z diski, ki imajo podobne lastnosti in 32 MB cache (npr. s 500 GB WD Caviar Green, ki ima 32 MB, sem zelo zadovoljen z vseh vidikov)?
 

Utisevalec

Guru
12. nov 2007
16.156
4.135
113
Več ali manj marketinška poteza, malo cacheja mora bit, več ga pa redko "uporabiš". Dejasnsko na samo hitrost diska ne vpliva, sploh če misliš disk uporabljati samo za storage (kar zunanji disk več ali manj je).
 
Nazadnje urejeno:

Commodore

Fizikalc
14. jul 2008
1.977
40
48
Ce prav razumem - ker je recimo v tem primeru vecina multimedijskih fajlov ranga velikosti par sto mega ali vec, v cache pa se posledicno lahko shrani samo nekaj milisekund takega fajla, torej razlika v takem primeru ni bistvena?
 

SouthPark

Jas da nea vem?! Ka te je...
5. sep 2007
24.570
5
38
Klobukarjev dol
Tako je, v takem primeru ni bistveno. Cache lahko vpliva recimo pri sistemskem disku, kjer piše in bere več datotek naenkrat in tako lahko recimo nekaj prebere, vmes v cache shrani za zapisovanje, torej odpravlja ozko grlo.
 

philips

Guru
Osebje foruma
Administrator
17. avg 2007
9.878
698
113
S cache se ne obremenjuj preveč, ker nima nekega velikega vpliva (glej spodaj). Rajši glej kaj drugega (cena, hitrost, odzivni čas)

Citat iz wikipedije:

Citat:
Disk buffer sizes over 8MiB do not produce any performance gains.[1] Where a buffer is large and the throughput of the disk is slow, the data becomes cached for too long, resulting in degraded performance over equivalent disks with smaller buffers. This degradation occurs because of longer latencies when flush commands are sent to a disk with a full buffer.[2]

Vir: http://en.wikipedia.org/wiki/Disk_buffer
 

Radirko

Fizikalc
18. avg 2007
6.242
0
36
Tale test, ki sluzi kot referenca citiranemu, pozabi omeniti, da je tam, kjer je za pricakovati nekaj razlike, ta skoraj 20% (pisanje, sploh ce gre za pisanje nakljucno lociranih podatkov namesto ene zelo dolge sekvence).

Za novodobni nadomestek magnetnega traku, kar ima ocitno Commodore v mislih, pa res ni za pricakovati opazne razlike.
 

Utisevalec

Guru
12. nov 2007
16.156
4.135
113
In kje dnevno uporabljaš sekvenco zelo različnih podatkov, ki so manjši od diskovnega cacheja ampak še vedno večji od park KB kar imajo diski že desetletje ali več?

Pa tudi če bi slučajno imel kje tako sekvenco moraš vedet da se 32MB podatkov zapiše na disk v "trenu oka" in ne boš opazil razlike med 8MB in 64MB cacheja. Kot rečeno če pa te sekvence ponavljaš pa takoj zasedeš tudi tistih 64MB podatkov in si na istem kot brez cacheja.

Pa koneckoncev vsi programi uporabljajo "hipni" pomnilnik (RAM) tam kjer je to smisleno in "storage" za dejansko hrambo, torej zapisov na tak način kot ti omenjaš ne bi smelo bit, vsaj ne zelo pogosto.

Skratka še 1x, stvar nima pomena, razen komercialnega!
grims-1.gif
 

Radirko

Fizikalc
18. avg 2007
6.242
0
36
Baze oz. nasplosno aplikacije, ki obdelujejo mnozico transakcij. Prostor je vecinoma ves zaseden, serje pa naokoli cisto kakor ji pase. Tukaj pride zelo prav, da ni treba vseh podatkov zapisovati takoj, ampak jih lahko out-of-order kakor kontroler oceni, da je najboljse, in tukaj se cache (razumljivo) najvec pozna. Vec kot ga je, vec out-of-order stvari se lahko zgodi. Ne pozna se pa pri dolgih sekvencnih zadevah (npr. kopiranje pornica iz CDja na disk), ker gre zapis prakticno na eno lokacijo za drugo in medtem ni nobenih dodatnih dostopov (za branje istih podatkov).

V tem je smisel predpomnilnika in ce so ze objavili "preizkus", bi lahko vsaj testirali stvari, kjer se pozna (no, eno so ... od skupaj zelo mnogo razlicnih testov). Ce so samo zeleli "dokazati", da ni razlike, potem so pa svoj namen dosegli ... enako kot lahko jaz "dokazem", da obstaja neposredna in zelo mocna pozitivna povezava med jedenjem kruha in smrtnostjo 30-letnikov, - popolnoma pravilno in popolnoma nesmiselno.
 

Utisevalec

Guru
12. nov 2007
16.156
4.135
113
Ja ampak za te namene se uporablja cache čisto na drugem nivoju; unix based, linux in novejši win sistemi uporabljajo za cache/buffer sistemski pomnilnik (RAM), ki ga je precej več kot pa tistih par MB cacheja na disku.

Recimo na spletnih serverjih (apache, php, mysql) se večina querijev izvede prej kot se sploh premakne glava diska za mm, če ni tako imaš velike probleme.

Sicer pa pustimo serverje, za domačo uporabo, sploh za zunanji disk je cache nepomemben!
 

Radirko

Fizikalc
18. avg 2007
6.242
0
36
Heh, kar rines po svoje
smile-1.gif
Sistemi ne pocnejo tega, o cemer govorim jaz in o cemer je spraseval mozakar zgoraj, ker enostavno ne morejo. Ne morejo pa zato, ker ne vedo kje se v resnici nahaja blok, kamor zelijo nekaj zapisati. Sistemi se lahko grejo buffering, ki se dogaja en ali dva nivoja visje, ampak to nima nobene zveze z omejenim in tukaj je onboard cache nezamenljiv.

To je tako, kot ce bi trdil, da je L1 i-cache v CPUju (npr. 64 KB/core) povsem nekoristen, ker je tako ali tako na voljo [na cisto drugem nivoju] bistveno vecji L2 oziroma L3. Ne gre tako
wink-1.gif


Sem pa napisal moj komentar zato, ker me moti citirani "test" oziroma zakljucek, ki ga clanek na Wikipediji poskusa potegniti iz njega.
 

Dr_Strangelove

Fizikalc
1. nov 2007
3.073
2
36
www.pentagon.gov
8 ali 32 MB disk cache-a je na zadnje imelo pomen kakih 10 let nazaj. Dan današnji govorimo o potrebi v rangu 1 GB za desktop mašine, 4 GB za strežnike, 8 GB za strežnike baz podatkov.
Vse drugo je mišji drekec in se v praksi bolje obnese cache-ing na višjem nivoju, torej sam operacijski sistem, sam softver strežnika baze podatkov ...
Seveda, če se cache uporablja tudi za write operacije, mora obvezno imeti še baterijski backup or you can kiss your data good bye, ko gre kaj narobe s štromom.
 

Radirko

Fizikalc
18. avg 2007
6.242
0
36
Citat:
Uporabnik Dr_Strangelove pravi:
Vse drugo je mišji drekec in se v praksi bolje obnese cache-ing na višjem nivoju, torej sam operacijski sistem, sam softver strežnika baze podatkov ...

No, to je nesmisel. Lepo sem napisal zakaj je to primerjava jabolk in hrusk ze v prejsnjem sporocilu. Enih stvari se ne da nadomestiti na tak nacin.

Citat:
Seveda, če se cache uporablja tudi za write operacije ...

Prav malce neprijetno mi je, da te bom napotil na zgoraj omenjeni clanek z wikipedije, katerega vir (in sklep) me motita, a se mi ne ljubi iskati drugega. Predlagam tretji odstavek in podpoglavje 1.3, ceprav so v bistvu v vseh (1.1-1.4) povzeli uporabo.

Seveda se uporablja za write operacije
rolleyes-1.gif
Ravno tam igra najvecjo vlogo razlika v velikosti, ce so naslovi dovolj "raztreseni", torej na koncu sledi, na koncu plate, diskontinuirani zaradi realokacije ..., medtem ko pri dolgih sekvencnih zapisih, kot je snemanje pornicev, ne igra bistvene vloge, saj ga je ze tako dovolj, da je hitrost zapisovanja (odvisna od gostote zapisa in hitrosti vrtenja) omejujoci dejavnik za throughput, namesto da bi to bila latenca dostopa (odvisna od natancnosti mehanike, ki premika glave in od hitrosti vrtenja).

Citat:
... mora obvezno imeti še baterijski backup or you can kiss your data good bye, ko gre kaj narobe s štromom.

Kar je normalno (UPS) za racunalnike, kjer so shranjeni pomembni podatki.
 

stein

Fizikalc
16. sep 2007
19.575
1
36
Nekdo naj zalaufa kaki benchmark, izklopi write cache na disku, pa spet bench.

((jaz grem spat)
 

Radirko

Fizikalc
18. avg 2007
6.242
0
36
Saj je v tistem clanku na tomshardware primerjava (nekje dalec v drugi polovici, na spodnjem delu strani). Razlike je cca. 20%. Dalec od zanemarljivega, sploh glede na razliko v ceni.
 

Hoof_Arted

Pripravnik
27. avg 2009
313
0
16
Potrebno je opozoriti, da je cache pri trdih diskih pod popolnim nadzorom kontrolerja, sploh pa ne pod nadzorom operacijskega sistem, še manj pa aplikacije. Služi pa predpomnjenju prečitanih podatkov. Pri neki normalni operaciji čitanja, tako kontroler v svoj cache ne prečita samo zahtevani blok, ampak še vrsto blokov za njim, ki mu neposredno sledijo. Največkrat bo naslednja zahteva za branje zadela blok, ki je že v cache in to izjemno skrajša odziv, saj mu ni treba fizično ničesar narediti. Pri pisanju pa tudi podobno, dobitek pa verjetno ni tako velik.
Seveda močno fragmentiran disk degradira hitrost iskanja in prenosa, saj je zaporednih zadetkov veliko manj.
Bodite pa prepričani, da vsak mega cachea kar dobro pripomore k "hitrosti" diska, predvsem zato, ker zmanjšuje fizično delo diska, kar najbolj podaljša operacije.
 

Utisevalec

Guru
12. nov 2007
16.156
4.135
113
Pozabljaš da je pisanje na disk tudi na nivoju OSja v sodobnih FSjih rešeno dovolj dobro, torej vmesni layer še kako pametno deluje pri vsakodnevni uporabi PCja.

Kar se pa tiče logike, recimo pri branju se disk cache lahko zapolni tako hitro kot je to fizično zmožen disk in da bo pri branju enega bloka podatkov sledilo branje ostalih blokov na "tracku" niti ni pomembno, ker FS to že ve in bo tudi prilagodil branje. Torej kateri blok se prebere oz. kakšno bo zaporedje pove že SW (FS) in disk pri temu nima nobene veze. Verjetnost da boš pri random branju (recimo bootanje OSja) "ugotovil" prave bloke in jih zapisal na 32MB cacheja na 1TB disku je pa minimalna.

Po drugi strani se pa pri prej omenjenem dogodku veliko pozna če ima disk dostopni čas 1ms nižji.

Pa koneckoncev če bi bil cache tako pomemben bi višji rang diskov imel vsaj 3x toliko cacheja kot pa običajni diski za rajo, ampak če pogledaš imajo redko več kot 16MB (serija Raptor in pa SAS diski), po drugi strani imajo pa 64MB cacheja več ali manj počasni (zeleni & eco) diski.
 

Hoof_Arted

Pripravnik
27. avg 2009
313
0
16
FS in hardware imata prav malo zveze. FS ugotovi, kateri blok rabi, nakar kontroler ta blok poišče in odda FS. Tu se srečujeta software in hardware.
Seveda nihče ne pričakuje, da bo vse bloke, ki jih rabi, našel v cacheu. Nekaj jih bo, za nekatere bo moral spet na disk in prebrati novo skupino v cache.
Tisto o bootanju - prav gotovo se prav tu največ pozna cache, saj je OS skupina večih datotek, ki so zelo verjetno v enem kosu in je torej verjetnost zadetka v cache zelo visoka, pa še branje je v principu sekvencielno, blok za blokom.
Kar se pa tiče večjega cache je pa spet teorija, do kje se splača. Prebrati nekaj deset mega vsebine, bi se splačalo le, če bo zadosti zadetkov, drugače ne. Vsak proizvajalec ima svoje algoritme in prav ti določajo, koliko bo cache pomagal pri hitrosti "dostave" podatkov. Pri neki meji se hitrost kljub večanju cachea neha povečevati. Brez skrbi, da je to skrbno varovana skrivnost, pa še marsikaj podobnega. To je popolnoma hardware zadeva, odvisna od proizvajalca, pa je skrita pred našimi očmi. Mislim, da je tudi izklopiti ne moreš (izjema je "nabiranje" blokov za pisanje, kjer je pa problem izgube podatkov ob nesrečah).
 

Radirko

Fizikalc
18. avg 2007
6.242
0
36
Najprej: tema na zacetku ni bila o delovanju na nivoju OSa, ampak izkljucno o delovanju na diskih. Na to se je nanasalo prvotno vprasanje in odgovori (vkljucno z mojim, ki se je nanasal na tisti nesrecni clanek s tomshardware), dokler ni nekdo skrenil debate drugam, nimam volje iskati kdo je to bil, ker je ocitno ze fuzbal naprej
wink-1.gif


Drugo: ce bi bilo na nivoju OSa to zadovoljivo reseno, potem bi bil cache na disku nepotreben. Temu pac ni tako. Onborad cache ima doloceno funkcijo, katere ne more nadomestiti nic drugega, razen ce vrzes celotno tehnologijo magnetnih diskov v smeti in uporabis tip pomnilnika, ki ima resnicno nakljucen dostop s popolnoma enako latenco ne glede na lokacijo (torej ne-pipelined tip pomnilnika, kar za take kolicine podatkov seveda ne obstaja).

Tretje: res je, da od neke tocke naprej mocno pade korist od povecanja velikosti predpomnilnika na disku, a to ne pomeni, da so vrednosti izpred precej let se relevantne danes. Nasprotno, bolj verjetno je, da niso, saj gostota zapisa narasca, mehanske omejitve delovanja diska pa ostajajo prakticno enake (fizikalni zakoni se niso spremenili, tehnologija izdelave pa zadnjih nekaj let razen pri gostoti zapisa bolj ali manj caplja na mestu). Ker narasca gostota zapisa, je potrebna proporcionalno visja kolicina predpomnilnika, ce hocejo ostati znotraj okvirov istih mehanskih omejitev, s kakrsnimi so se srecevali pred povecanjem. Ce bi imel moznost na danasnjem - bistveno vecjem - disku narediti enako primerjavo (8 vs. 16 MB), sem preprican, da bi bila razlika vecja.
 

Utisevalec

Guru
12. nov 2007
16.156
4.135
113
Se ne bom prerekal ...

Tema je bila ali kupiti ZUNANJI (očitno USB 2.0) trdi disk ki ima samo 8MB cacheja in kako se to pozna pri hitrosti delovanja. Moj prvoten odgovor je bil da se za tak disk na takem vmesnik in za tak namen cache ne pozna 0 oz. da ne bomo "napačni", ne pozna se skoraj nič vsekakor pa ne toliko da bi uporabnik to opazil.

Še enkrat, gre za disk ki bo fural podatke na USB 2 vodilu ki bo verjetno večino časa ozko grlo (tako pri prenosnih hitrostih kot tudi pri "latencah") in zadnja stvar ki bi tu igrala vlogo je tisti cache. Kot vidim dobiš disk (z ohišjem) za manj kot 70EUR in če se uporablja samo za shranjevanje porničev ne vidim nobenega problema, sploh ker avtor daje za referenco "počasni" WD Green.

Avtorju pa še v razmislek da je vodilo USB 2.0 zastarelo (ozko grlo) in da če imaš opcijo glej za eSATA oz. USB 3.0 vodila.