Tankeeksperiment: Ekstremt rask akesss på 7200rpm-

[Simen1]

Jeg kom på et lite tankeeksperiment:

1. Sett av f.eks 100GB på begynnelsen av en 300GB 7200rpm harddisk med NCQ. Dette vil gjøre at lesehodet i gjennomsnitt må bevege seg mye kortere avstand for hvert søk. Siden det ligger mer data ytterst på disken enn innerst (pga lengre spor ytterst) så vil det si at lesehodet får godt under 1/3 av avstanden å jobbe på. Kanskje rundt 1/5. Søketiden bør dermed reduseres en god del. Kanskje ned til halvparten av de normale ca 9ms for 7200rpm-disker.

 

På begynnelsen av slike disker oppnår man ca 60 MB/s. Med en rotasjonshastighet på 7200rpm vil det si at det ligger ca 0,5MB med data per runde av harddisken.

 

2. Programmer en spesiell driver til partisjonen som legger alle data f.eks 2 ganger etter hverandre per runde. Altså A=B=C=0,25MB Så legges dataene slik: A A B B C C osv. Kapasiteten på disken vil effektivt bli halvert, men derimot så vil man slippe veldig mye rotational latency. Rotational latency vil faktisk halveres fra 4,17ms til 2,08ms. Dette er like bra som disker på 2*7200rpm = 14400rpm.

 

Med denne metoden kan man altså "bytte" bort høy overføringshastighet og høy kapasitet mot lav aksesstid. I eksemplet over halveres kapastieten fra 100GB til 50GB, overføringshastigheten reduseres fra 60MB/s til 30MB/s og aksesstiden blir redusert fra ca 13,2ms til ca 6,6ms. Altså meget raskt.

 

Hvis man setter slike partisjoner i Raid0 så vil kapasitet og overføringshastighet øke til normalen igjen uten å gå merkbart ut over aksesstiden. Det bør også være en enkel sak å bytte bort ennå mer overføringshastighet og kapasitet mot ennå lavere aksesstid. F.eks ved å lagre alle data i ennå flere og mindre biter gjentatt etter hverandre.

 

Med ennå smartere taktikk går det sikkert an å ha dynamisk størrelse på bitene slik at hver fil deles opp i et større antall biter dersom den er liten og et mindre antall dersom den er stor. Da får man kombinert både høy kapasitet og overføringshastighet for store filer og rask aksess for små filer.

 

Edit: Jeg fikset en feilaktig/elendig formulert påstand.

Endret 2. desember 2005 av Simen1

[Mr. Y]

Men da vil jo disken måtte skrive dobbelt så mye, det er jo et lite minus, selv om lesehastigheten økes pent.

[mysjkin]

2. Programmer en spesiell driver til partisjonen som legger alle data f.eks 2 ganger etter hverandre per runde. Altså A=B=C=0,25MB Så legges dataene slik: A A B B C C osv. Kapasiteten på disken vil effektivt bli halvert, men derimot så vil man slippe veldig mye rotational latency. Rotational latency vil faktisk halveres fra 4,17ms til 2,08ms. Dette er like bra som disker på 2*7200rpm = 14400rpm.

Skulle dette fungere slik så måtte vel i så fall de to 'chunkene' legges radielt overfor hverandre (slik at det er en halv omdreining mellom dem)? Høres for meg ut som om det blir veldig mye "housekeeping", også for å holde 'chunkene' i synk.

 

(Hjelp, norsk terminologiforstoppelse i dag...)

 

M.

[Simen1]

Ja, de må ligge på hver sin side av plata for at dette skal gi noen nytte. Det gjør man enkelt ved å lese av produktnummeret på disken (Da vet man om disken er 7200rpm) og kjøre en test på overføringshastighet over hele disken. Med disse to faktorene regner man lett ut hvor mange Byte det bør være mellom hver av de to kopiene av filene.

 

Man må også lage et system som gjør at begge kopiene fjernes fra NCQ-køa når bare en av kopiene er lest.

 

Mr. Y: Det stemmer. Skriving vil gå tregere. Men til forsvar for tankeeksperimentet så leses det normalt veldig mye mer enn det skrives, så det behøver ikke å bety så mye likevel.

[Simen1]

Et lite tankeeksperiment til:

Hadde det gått an å montere to lesehoder veldig tett sammen slik at det kan leses f.eks to nabospor samtidig? Hvis det går så kan overføringshastigheten effektivt dobles på alle filer som er så store at de dekker f.eks 2 hele spor.

[arneolav]

Tror doble hoder blir fysisk vanskelig, men flere lese skrive-armer, 2, eller 4, dvs et sett i hvert hjørne...

 

Og Os som, i ledige stunder, sørger for å "stable om" på disken(e) slik at de mest aktuelle filene ligger nær midten av platene for at fysisk bevegelse på armene blir redusert.... men det er et annet "prosjekt'.

[toregro]

Et lite tankeeksperiment til:

Hadde det gått an å montere to lesehoder veldig tett sammen slik at det kan leses f.eks to nabospor samtidig? Hvis det går så kan overføringshastigheten effektivt dobles på alle filer som er så store at de dekker f.eks 2 hele spor.

5220918[/snapback]

 

likte den ideen, hvorfor stoppe på 2 hoder? ah, selvfølgelig, vi har ikke teknologien enda.. blir bra om noen år vil jeg tro

[Simen1]

Ennå et tankeeksperiment:

Hva med å la alle lesehodene på en disk med f.eks 3 plater og 6 lesehoder lese samtidig? Sånn det er per i dag så leser jo disken bare fra ett av hodene av gangen.

[Buzz76]

Ennå et tankeeksperiment:

Hva med å la alle lesehodene på en disk med f.eks 3 plater og 6 lesehoder lese samtidig? Sånn det er per i dag så leser jo disken bare fra ett av hodene av gangen.

5222293[/snapback]

 

Om noen husker.. så hadde KenWood noen CD-ROM'er for noen år siden (på Pentium MMX/PII tiden) som hadde 7 lesehoder... tanken var å lese mere data per omdreining... det fungerte... men ble ikke noen hit tydelighvis... crappy kvalitet?

Teknologien er der iallefall.

 

Ang. å legge data dobbelt opp... det vil jo ikke fungere i praksis. Fragmentering osv?

[lqpl]

Ennå et tankeeksperiment:

Hva med å la alle lesehodene på en disk med f.eks 3 plater og 6 lesehoder lese samtidig? Sånn det er per i dag så leser jo disken bare fra ett av hodene av gangen.

5222293[/snapback]

 

Har lurt på det samme, merkelig at ingen produsenter prøver seg

på en slik intern RAID funksjon. Mulig det skaper mer varme eller

øker sjansen for feil?

[Gadgetman]

Et par kommentarer...

 

Plassere sektorer i 'gal' rekkefølge for å forbedre lesehastighet er en gammel og velprøvd teknikk. Det kalles 'interleaving' og forsvant da IDE-diskene gjorde sitt inntog. Dette fordi man ikkje lengre kunne adressere diskene direkte. IDE-grensesnittet ser likt ut som de gamle ST-506 systemene, men det som presenteres nå er virtuelle plater, hoder og sektorer, ikkje de reelle talla. (elektronikken på disken oversetter dette) Når man ikkje kan vite nøyaktig diskgeometri lengre er dette umulig, ihvertfall på vanlige disker. (Det er godt mulig at diskene faktisk bruker Interleave, det er bare ikkje synlig for oss)

 

Å lese med flere hoder samtidig krever mer avansert elektronikk på disken. Eller man kan bruke RAID...

 

Å ha flere hoder plassert rundt disken burde kutte drastisk ned på accesstiden, men... Ikkje bare krever det mer avansert elektronikk på disken, men det krever også flere motorer for posisjonering, og dersom de skal lese samtidig, så krever det også en svært nøyaktig plassering av hodene i forhold til hverandre.

 

Eg sider ikkje at disse teknikkene ikkje er mulig, bare at de vil koste veldig mye mer.

Trolig vil de også kreve spesielle kontrollere/drivere for å best kunne utnytte dem.

Og det betyr at de først vil dukke opp for servere, og senere for high-end arbeidsstasjoner.

Og det igjen forutsetter at serveransvarlige er villig til å betale såpass mye ekstra for den antatte hastighetsforbedringa.

(Som bør være ganske stor om de skal konkurrere med dagens massive RAID systemer med enorme mengder Cache... )

 

Edit:

PS: Og ja, pkt. 2 og 3 vil føre til større fare for feil...

Endret 1. desember 2005 av Gadgetman

[Simen1]

Plassere sektorer i 'gal' rekkefølge for å forbedre lesehastighet er en gammel og velprøvd teknikk. Det kalles 'interleaving' og forsvant da IDE-diskene gjorde sitt inntog. Dette fordi man ikkje lengre kunne adressere diskene direkte. IDE-grensesnittet ser likt ut som de gamle ST-506 systemene, men det som presenteres nå er virtuelle plater, hoder og sektorer, ikkje de reelle talla. (elektronikken på disken oversetter dette) Når man ikkje kan vite nøyaktig diskgeometri lengre er dette umulig, ihvertfall på vanlige disker. (Det er godt mulig at diskene faktisk bruker Interleave, det er bare ikkje synlig for oss)

5236488[/snapback]

Tenker du på den gangen da det var mulig å lavnivåformatere disken til større kapasitet enn den var merket orginalt? Omentrent som å formatere en Single Density 3,5" 720kiB diskett til Double Density 1,44MiB ?

 

Hvis det var dette du mente så er det ikke noe slikt jeg foreslår. (Les over en gang til så ser du hva jeg mener).

 

Angående den setningen jeg uthevet så mener jeg det skal være mulig å gjøre dette med moderne disker selv om de har virituell adressering. Data ligger stort sett lineært langs hvert spor likevel og så lenge man vet spinnhastigheten (rpm) og lesehastigheten (MB/s) så mener jeg det går an å finne ut hvor mye data som ligger langs hvert spor og dermed omentrentlig hvor store de gjentagende bitene bør være.

[Muffinman]

Ennå et tankeeksperiment:

Hva med å la alle lesehodene på en disk med f.eks 3 plater og 6 lesehoder lese samtidig? Sånn det er per i dag så leser jo disken bare fra ett av hodene av gangen.

5222293[/snapback]

Har lest noe om dette, husker ikke hvor. Det er ikke mulig pga at det er problematisk å få lesehodene rett over sporene på de enkelte platene samtidig. Tror kanskje det var et intervju med en eller annen fra en diskprodusent tildigere i høst.

[Mr Burns]

Plassere sektorer i 'gal' rekkefølge for å forbedre lesehastighet er en gammel og velprøvd teknikk. Det kalles 'interleaving' og forsvant da IDE-diskene gjorde sitt inntog. Dette fordi man ikkje lengre kunne adressere diskene direkte.

5236488[/snapback]

 

Grunnen til at interleaving ble brukt var at CPU ikke klarte å ta imot data fra harddisken raskt nok. Etter hvert ble CPU rask nok til å lese kontinuerlig fra disk. Derfor forsvant interleaving.

[Gadgetman]

Plassere sektorer i 'gal' rekkefølge for å forbedre lesehastighet er en gammel og velprøvd teknikk. Det kalles 'interleaving' og forsvant da IDE-diskene gjorde sitt inntog. Dette fordi man ikkje lengre kunne adressere diskene direkte. IDE-grensesnittet ser likt ut som de gamle ST-506 systemene, men det som presenteres nå er virtuelle plater, hoder og sektorer, ikkje de reelle talla. (elektronikken på disken oversetter dette) Når man ikkje kan vite nøyaktig diskgeometri lengre er dette umulig, ihvertfall på vanlige disker. (Det er godt mulig at diskene faktisk bruker Interleave, det er bare ikkje synlig for oss)

5236488[/snapback]

Tenker du på den gangen da det var mulig å lavnivåformatere disken til større kapasitet enn den var merket orginalt? Omentrent som å formatere en Single Density 3,5" 720kiB diskett til Double Density 1,44MiB ?

 

Hvis det var dette du mente så er det ikke noe slikt jeg foreslår. (Les over en gang til så ser du hva jeg mener).

 

Angående den setningen jeg uthevet så mener jeg det skal være mulig å gjøre dette med moderne disker selv om de har virituell adressering. Data ligger stort sett lineært langs hvert spor likevel og så lenge man vet spinnhastigheten (rpm) og lesehastigheten (MB/s) så mener jeg det går an å finne ut hvor mye data som ligger langs hvert spor og dermed omentrentlig hvor store de gjentagende bitene bør være.

5236676[/snapback]

 

Nei, eg mente det å bytte om på plasseringa av sektorene. Å formattere disker med større kapasitet enn de er konstruert for kalles idioti...

 

Det hjelper ikkje å vite spinnhastighet og lesehastighet fordi du ikkje er garantert noen direkte 'oversettelse' mellom virtuell og reell adressering.

Forskjellige spor kan ha forskjellig antall sektorer, og hele spor kan bli omrokket til andre deler av disken om det oppdages en feil der de var mappet til tidligere.

(En av årsakene til at disker ikkje lengre kommer med 'bad sector maps'... Feila finnes fortsatt, de bare skjules...)

 

Mulig at Interleaving ikkje lengre hadde noen nytte ettersom prosessorhastigheta økte, men den virtuelle adresseringa gjorde det umulig å bruke teknologien uansett.

[ozone]

Siden dataene ligger tettere ytterst på disken enn innerst (pga lengre spor ytterst)

5219451[/snapback]

 

 

Det er ikke tettere med data ytterst på disken, det er bare mer data per omdreining fordi, som du sier, det er lengre spor ytterst.

 

Ellers var det en artig tanke, selv om jeg tror at fragmentering vil ta knekken på systemet ditt etter kort tid...

 

Dessuten er det vel ikke lenge før det er slutt på roterende disker med bevegelige lesehoder. Moderne harddisker og CD/DVD er jo faktisk basert på 100 år gammel phonograph-teknologi

[BloodRabbit]

Denne Ideen likte Jeg, egentlig trenger du ikke å mikrokontrollere plaseringen av av de 2 filene (som er like), de trenger ikke ligge nøyaktig 180 grader fra hverandre. Tiden det tar å finne filene vil gjennomsnittlig halveres.

Endret 2. desember 2005 av BloodRabbit

[Simen1]

Siden dataene ligger tettere ytterst på disken enn innerst (pga lengre spor ytterst)

5219451[/snapback]

Det er ikke tettere med data ytterst på disken, det er bare mer data per omdreining fordi, som du sier, det er lengre spor ytterst.

Beklager. Kortslutningen er helt på min side

 

Ellers var det en artig tanke, selv om jeg tror at fragmentering vil ta knekken på systemet ditt etter kort tid...

Jeg tror ikke fragmentering vil gjøre noe særlig mer ugagn enn det gjør på vanlige disker.

 

Dessuten er det vel ikke lenge før det er slutt på roterende disker med bevegelige lesehoder. Moderne harddisker og CD/DVD er jo faktisk basert på 100 år gammel phonograph-teknologi 

5240429[/snapback]

Akkurat det betviler jeg. Jeg vet per dags dato ikke noen teknologier som er i nærheten av kostnaden per GB som roterende lagringsmedia har. Flash kan bli et godt valg for OS-partisjoner innen noen få år, men neppe som generell lagringsplass siden kostnadene per GB er i størrelseorden hundre ganger høyere enn for roterende media. Begge deler utvikler seg omentrent i samme takt så det ser ikke ut som forspranget på 100 ganger skal taes igjen i det nærmeste.

 

BloodRabbit  Postet i dag, 10:23]Denne Ideen likte Jeg, egentlig trenger du ikke å mikrokontrollere plaseringen av av de 2 filene (som er like), de trenger ikke ligge nøyaktig 180 grader fra hverandre. Tiden det tar å finne filene vil gjennomsnittlig halveres.

Jepp, dataene trenger ikke ligge nøyaktig diagonalt. Det holder fint med omtrentligheter.