Åsikter angående Raptor & Raid0 kombo

Ledsen att göra er besvikna,men SCSIraidkortet har ju egen bios som ska detecta diskar och arrayer så uppstartstiden blir inte något som går att jämnföra med...:)

Random Access: 5.8ms
CPU Utilization:4%
Average Read:125.1MB/s
Burst Speed: 185.4MB/s

HD Tach 3.0

Mitt resultat!

Random Access: 8.2ms
CPU Utilization:5%
Average Read:78.0MB/s
Burst Speed: 131.5MB/s

HD Tach 3.0

Tänkte inte så mycket på min formel, men tar man bara hänsyn till att disken ska snurra till rätt plats så stämmer den för en disk och för oändligt många diskar (En disk: genomsnitt halvt varv. Oändligt många: finns alltid någon som tar ett helt varv på sig).
Sen hoppades jag bara att den stämmer nästan för läshuvudets rörelse. Dock så kan den röra sig åt båda hållen medan skivan bara går åt ett håll och måste då snurra ett helt varv om den precis missat sitt mål.
Egentligen ska man väl multiplicera disksnurrstiden med 2n/(n+1) (om den nu stämmer) och läsarmstiden med nåt annat. Borde gå att lösa om man antar att läsarmen rör sig med konstant hastighet och accelerar och bromsar oändligt fort.

Hittade min gamla artikel, men hade tydligen inte undersökt åtkomsttiden speciellt mycket. Nedan syns ett diagram från programmet Diskspeed. Vettekatten om de säger så mycket egentligen.

xplane_uppsala testade boot-tid. Ensam raptor 47 sekunder, raptorer i raid-0 69 sekunder. Det tog alltså 46% längre tid att boota från raptorerna i Raid-0. Det tycker jag passar utmärkt under "STOR skillnad".

Nu tror jag visserligen att hans installation inte var helt clean, men jag vet också att det rent fysikaliskt måste skilja rätt mycket i accesstid om man kör raid-0. Enligt mina tidigare uträkningar minst 1.25ms bara på variationer i rotationsposition mellan en och två 10000rpm-diskar. Lägger man på variationer i läsarmens position kommer denna tid öka ytterligare.

För att du ska kunna ha 0.8ms skillnad i snittaccesstid mot en enda disk, krävs dels att läsarmen inte behöver röra sig någonting alls, dels att dina diskar roterar med c:a 15000rpm. Inte helt omöjligt, men inte så vidare sannolikt heller.

-- detaljer
Om man ska vänta på en disk ska rotera fram rätt sektor, får man vänta i snitt ett halvt varv. I 15000rpm så är den tiden 2ms.

För två diskar så gäller det att hitta jämviktstiden där båda diskarna 'i snitt' hittat sektorn.

Chansen att disk1 och disk 2 ska göra det på en viss tid T är lika med chansen att ena ska göra det gånger chansen att andra ska göra det. Alltså P(tot<T) = P(t1<T) * P(t2<T), eller eftersom båda är samma: (P(t1<T))^2

Om vi vill ha snittaccesstiden sätter vi P(tot<T) till 0.5 och löser ekvationen. 0.5 = P(t<T)^2 -> SQRT(0.5) = P(t<T), dvs P(t<T) = 0.7071

Eftersom rotationen ger en likformig fördelning för P(t<T) är det bara att multiplicera med rotationstiden.

0.7071 * 4ms = 2.83ms... Jfrt med 2.0ms i snitt för en enda disk. Detta är alltså ett teoretiskt minimum för hur mycket det skiljer.

Samtliga siffror naturligtvis med reservation för ev. felräkningar.

Det är om läshuvudet aldrig behöver röra sig, och du har två stycken 15000rpms diskar i Raid-0.

Läshuvudet behöver röra sig, och du har inte 15000rpms diskar, så din fördröjning är mycket större.

Ursäkta om jag är trött, men vad är det du gör egentligen?
Du skriver att sannolikheten att Raid0:n accessar på sin snitt-accesstid är 50%?

Teoretiskt minimum för vad? Klart att chansen finns att diskarna hittar allt precis lika snabbt, och då blir accesstiden precis likadan för två diskar som en.

Det hoppas jag att jag inte skrev.

Jag menade att skriva:
Chansen för att första disken ska hitta sektorn inom tiden t multiplicerat med chansen för att andra disken ska hitta sektorn *ska* vara lika med 0.5. Genom att sätta den till 0.5 anger vi att vi letar efter snittaccesstiden. 0.5 är en sannolikhet. I detta fall betecknar den gränsen där det är lika troligt att det tar kortare tid, som att det tar längre tid, att accessa diskarna.

Alltså P(t1<T) * P(t2<T) = 0.5
Sedan vet vi att båda diskarna är identiska, så vi har (P(t<T))^2 = 0.5. (^2 är 'upphöjt till två')
Tar man roten ur det, får vi att P(t<T) = SQRT(0.5), dvs. P(t<T) = 0.7071...

Det skulle i så fall betyda att det är lika stor chans att man slår enbart ettor oavsett hur många tärningar man har. Det stämmer inte.

@Mathias: Inte min mening att vara dryg eller så. Vill bara försöka förklara varför siffrorna måste vara bogus. Det är så lätt att hänvisa till vad ett program säger. Bra om du kan återkomma med empiriska data - det väger tyngre än både teoretiska siffror och syntetiska benchmarks.

Men sannolikheten att man slår många många ettor i rad finns, den är bara liten. 6^(-n) där n är antal ettor man vill slå.

Sannolikheten finns också för att accesstiden ska vara mindre än ditt teoretiska minimum.
Accesstiderna i Raid0 sträcker sig över precis samma område som för singeldisk, bara att det är större chans att tiden blir sämre just för att flera diskar måste hitta stället.

Raid0 kan ha samma tid som den bästa tid som singeldisk kan få.
Singeldisk kan ha samma tid som den sämsta tid som Raid0 kan få.

Sant, men bara om man testar en eller ett fåtal accesser. Man brukar dock ange accesstid som snittaccesstid, och då spelar det roll att raid-0 måste vänta på den långsammaste disken.

Intressant, och litet förvånande. Vad körde du för stripe-size?

Vi kan ju omedelbart säga att de inte stämmer med mina beräkningar i alla fall... (Vilket förmodligen betyder att det finns nåt jag inte tar hänsyn till)

Jep, och jag trodde XP-starten skulle påverkas mer av accesstiden än av överföringshastighet.

Intressant hur som helst. Nu har vi två motstridiga empiriska tester - du fick kortare uppstartstid, xplane_uppsala fick längre. Undrar vad det beror på...

Ah... Fast det verkar vara nåt annat än din Raid-0.

Citerar:
"The reason the access times are so low is because he has only allocated the outer edge of the disk where the data per rotation is greatest, hence a random seek to some address doesn't have to traverse nearly as much of the disk. In fact, with such a small portion of the disk allocated it is nearly all rotational latency. The same effect would be achieved by moving all your "system" files to the front of the drive although benchmarks measuring seek time would not reflect this. Raid 0 in fact increases latency for reads because both spindles are never perfectly synced. If you created a 1 MiB raid 0 partition the seek times would be even better, especially considering the entire "drive" would fit into the cache."

Den där 'Matrix' raid-0 de talar om kan alltså inte använda hela disken, utan poängen är att den använder ett väldigt begränsat band på disken så att läshuvudet bara behöver röra sig minimalt i sidled...

Det förklarar dock inte varför du också får lägre accesstider... (Jag *antar* att du nyttjade hela diskarnas area till din Raid 0-array?)

Cool. Då har vi förklaringen...

Vid 9ms snittaccesstid varav 3ms för rotationen så är kostnaden för läshuvudet 6ms, alltså ganska stor del av totalen.

Har inte tänkt efter så mycket på det ännu, men eftersom man verkar kunna optimera accesstiden ganska kraftigt på det sättet, så skulle det kunna vara riktigt bra med OSet på en pytteliten raid-0 partition på två diskar med hög datatäthet. (Ju högre datatäthet, desto smalare blir den fysiska partitionen, och desto mindre måste läshuvudet röra sig)