Flash-minne harddisk på 90 GB

[Simen1]

Er meget imponert over kunnskapsnivået ditt Simen1, ikke bare i denne posten men i de aller fleste du bidrar i.

Tusen takk for skryt! Sånt liker jeg Lærer mye når man har interressen på topp. (kanskje litt nerdete av meg men..)

 

PS. Lage for morroskyld en utregning på lesehastigheten på lesehastigheten på diverse lagringsmedier som funksjon av karakteristiske data for mediene (gj.snittlig aksesstid og transfer) og gj.snittlig filstørrelse. (OK, har lite å gjøre i dag og har nerdet litt det siste kvarteret ) Her er i hverfall resultatet:

 

Jeg fikk et spørsmål på PM om en forklaring på de forskjellige feltene, så jeg legger like gjerne forklaringen her:

Gjennomsnittsfilstørrelse... Hva mener du med de feltene?

 

Vet du forresten også hvor raskt slike Flash-RAM-kort er, slike som man har i mobiltelefoner og digi-cams?

 

Blib - lykkelig over å ha funnet en finfin geek han kan stille vanskelige spørsmål til 

Med gjennomsnittlig filstørrelse mener jeg filene som skal leses fra disken. F.eks om du skal lese ørten album med mp3 gjetter jeg gjennomsnitt-størrelsen er rundt 4-5 MB per fil. (4-5000 kB på skalaen i det lilla feltet) Hvis du driver med database og trenger en disk til å lese ørten bittesmå filer raskt, slik som f.eks forumserverern her så ligger nok den gjennomsnittlige filstørrelsen på rundt noen få kB.

 

Det blå og turkise feltet viser typiske aksesstider og transfer-rates for harddisker og de andre lagringsmediene som er listet opp i det gule feltet.

 

Det hvite feltet er den resulterende hastigheten [MB/s] på de forskjellige lagringsmediene. Cellene som ligger horisontalt viser MB/s for de forskjellige typene bruk av et lagringsmedie. Med "bruk" mener jeg gjennomsnittlig filstørrelse på filene som skal leses. Cellene som ligger vertikalt viser forskjell i MB/s på de forskjellige lagringsmediene.

 

Legg merke til at dersom du bare skal lese digre filer (100000kB-kolonna) så har aksesstiden nesten ingen ting å si. Alle lagringsmediene leverer nesten 100% av hva maksimal transfer-rate er. Legg også merke til andre enden av skalaen: Dersom du bare skal lese knøttsmå filer a 1 Byte hver, så har ikke transfer noe å si siden nesten all tid brukes til "aksesstid", altså venting til lesehodet finner den byten den skal lese. Her er hastigheten helt avhengig av aksesstiden.

 

Feltet "Typ CF-kort" er Typiske hastigheter for compact-flash kort til digitalkameraer etc. Tallet 6 MB/s er hentet fra akamera.no mens 0,05ms er noe jeg antar og delvis husker fra andre websider som har testet CF-kort.

 

Feltet "Flash disk" gjelder disken som denne tråden startet med. Tallene er hentet fra nyheten.

Endret 13. mars 2004 av Simen1

[JKJK]

Simen1: OMG!

 

du har definitift mer fritid enn det jeg har!

 

....eller bare at einstein ikke er død, men holdes til fange i kjelleren din

[durabit]

0,02 ms aksesstid var ikke så veldig mye når du tenker på at en standard 7200rpm S-ATA disk ligger på 8-9 ms. Synd at man ikke har gullhår i ræva

Gjennomsnittlig tilfeldig Aksesstid for vanlige 7200rpm disker er som regel 12-13 millisekunder. Du tenker sikkert på søketiden.

 

Aksesstid = søketid + rotational latency.

 

Der søketid er tiden det tar å flytte lesehodet til det riktige sporet. "Rotational latency" er tiden det tar før plata snurrer rundt til det stedet du skal begynne å lese fra. (i snitt en halv omdreining) For 7200rpm disker er dette alltid 4,166666... millisekunder, ofte forkortet til 4,2 millisekunder.

Er meget imponert over kunnskapsnivået ditt Simen1, ikke bare i denne posten men i de aller fleste du bidrar i.

Enhver med litt hardware kjennskap, basic matematikkunnskaper og en brukbar hjerne vet da dette

[Petteram]

Det må nok være ironisk ment av Petteram  Kan ikke tenke meg annet.

 

Jepp, veldig ironisk. Ingen tvil om at dette blir en av fremtidens standarder.

[snorreh]

Simen1: Meget bra!

[Xvani]

0,02 ms aksesstid var ikke så veldig mye når du tenker på at en standard 7200rpm S-ATA disk ligger på 8-9 ms. Synd at man ikke har gullhår i ræva

Gjennomsnittlig tilfeldig Aksesstid for vanlige 7200rpm disker er som regel 12-13 millisekunder. Du tenker sikkert på søketiden.

 

Aksesstid = søketid + rotational latency.

 

Der søketid er tiden det tar å flytte lesehodet til det riktige sporet. "Rotational latency" er tiden det tar før plata snurrer rundt til det stedet du skal begynne å lese fra. (i snitt en halv omdreining) For 7200rpm disker er dette alltid 4,166666... millisekunder, ofte forkortet til 4,2 millisekunder.

Er meget imponert over kunnskapsnivået ditt Simen1, ikke bare i denne posten men i de aller fleste du bidrar i.

Hmmm, stussa litt p& dette jeg oxo, dette var jeg ikke klar over.

 

Kan dette vaere grunnen til at HDtach/sisoft sandra og winbench 99 viser s& forskjellige tider?

 

http://hardware.no/art.php?artikkelid=5993burde vaert nevnt i samtlige tester.......

 

Burde vaert nevnt i samtlige tester og artikler....

 

Trekker man fra 4.2 fra HDtach ser man at den stemmer s&nn ca med WinBench99s s0ketid.

 

n&r jeg ser n0yere etter ser jeg at HDtach m&ler aksesstid, ikke s0ketid!

 

Noen b0r gj0re Magnus Johansen oppmerksom p& dette? (har skrevet i tilbakemeldinger alt)

[skarsnut]

Alt er drit neste innlegg 2010!

[genesis]

nå har utviklingen ihvertfall begynnt.... dette skal bli raskt.

 

snakkes i 2010 ja

[Simen1]

Simen1: OMG! du har definitift mer fritid enn det jeg har!

 

....eller bare at einstein ikke er død, men holdes til fange i kjelleren din

Hehe.. Som durabit sier: Det er ikke så vanskelig når man kan litt matte og har interresse for slikt.

 

Ang. fritid, så tok det meg vel 5 minutter å sette opp en formel som fungerer (den første funket ikke ), 5 minutter å sette opp layuoyen, med farger og tekst, og 5 minutter med google å finne ut det jeg trengte av søketider og transfer. Så det er ikke så galt?

 

Ang. kjelleren, så bor jeg selv i kjelleren

 

Kan dette vaere grunnen til at HDtach/sisoft sandra og winbench 99 viser s& forskjellige tider?

 

http://hardware.no/art.php?artikkelid=5993

 

Burde vaert nevnt i samtlige tester og artikler....

 

Trekker man fra 4.2 fra HDtach ser man at den stemmer s&nn ca med WinBench99s s0ketid.

Sisoft runder for mye av ja. Samtidig viser de tydelig for lave verdier (ingen 7200rpm har 6-7 ms søketid, den bruker å ligge på 8,5 - 9ms) De siste to viser nok bedre verdier (den ene: søketid, og den andre aksesstid), men jeg aner ikke hvilken jeg skal stole mest på. Tenker jeg vurdrer disse likt inntil jeg vet bedre.

[Anders Leipsland]

Angående avrunding. Det er ikke nødvendigvis så ille, heller tvert om. Det er større feil å angi tall med for mange desimaler enn for få. Det heller kommer an på hvor store feilmargin du har.

 

f.eks to harddisker hvor en får 8.6 og en får 9.2 hvor en feilmarin er på kanskje +/-0.5 så vil det være riktig å oppgi begge som 9.

[Simen1]

Angående avrunding. Det er ikke nødvendigvis så ille, heller tvert om. Det er større feil å angi tall med for mange desimaler enn for få. Det heller kommer an på hvor store feilmargin du har.

 

f.eks to harddisker hvor en får 8.6 og en får 9.2 hvor en feilmarin er på kanskje +/-0.5 så vil det være riktig å oppgi begge som 9.

Hva om den ene disken er 8,4ms og den andre er 8,6ms. Synes du det er rettferdig om de får oppgitt hhv. 8ms og 9ms som søketider? Folk kan jo til og med tolke det til at den dårligste kan ha ned til 9,4ms og den beste 7,6ms. Altså en enorm forskjell..

 

Blir nesten som om værmeldinga på TV avrundet til nærmeste 10 °C. Hva om de melder 0 °C i Bodø og 10 °C i Trondheim? Det kan jo bety at det blir greit skiføre med -4°C i Bodø og nesten shortsvær (14°C) i Trondheim. Evt. kan det bety surt skivær med 4°C i Bodø og surt shortsvær med 6° i Trondheim. Hvis jeg var bonde, fisker, fjellvandrer, drev med snøsport, vindsurfing, grilling i hagen eller andre utendørsting ville ikke jeg stolt særlig mye på et slikt værvarsel.

 

Jeg synes for mye avrunding egentlig bare legger til en ekstra usikkerhet. Bedre med for mange desimaler og heller teste med flere programmer og se om de viser nogenlunde det samme eller om de spriker. Kan jo også legge til rotational latency på den som bare viser søketid så grafene visuelt sett blir lettere å tolke. Hvis de viser nogenlunde likt kan vi anta at det er relativt nøyaktig, mens hvis resultatene spriker så kan vi anta stor usikkerhet. Spredningen sier altså noe om nøyaktigheten i målingene. Det gjør ikke alt for avrundete resultater.

Endret 12. mars 2004 av Simen1

[GSM]

Alt er drit neste innlegg 2010!

..

 

ontopic: 40000$ for en hardisk??

Hadde ikke begynt å grine hvis jeg fikk en slik en gratis nei .

[Simen1]

Får vel vise hva jeg mener:

 

Gammel graf:

 

Ny graf, med resultatene fra Sisoft fjernet og lagt til Rotational Latency på resultatene for Winbench 99:

Nå synes jeg resultatene ser mye mer ryddige ut. (Er du ikke enig i det Anders?) Selv om Samsung-disken viser et lite avvik så ser i hvertfall de andre ut til å gi relativt like resultater med de to testprogrammene. Hvis vi ser bort i fra Samsung-disken igjen så ser usikkerheten ut til å være ca +-0,1 ms for disse testene. Seagate-disken gjør det best, mens Maxtor gjør det dårligst. Kanskje man burde testet Samsung-disken på nytt for å se om det var ett eller annet som forstyrret resultatet i den ene testen?

Endret 13. mars 2004 av Simen1

[Anders Leipsland]

Ja det bør avrundes. Akkurat slik som er vanlig i fysikkens verden 8 og 9 må da tolkes som veldig like resultater. (samtidig som man også kan påpeke at testmetoden er alt for dårlig til at resultatet er verd noe)

 

Angående værmeldinga så kan de fastslå ganske sikkert hva tempen blir (hvertfall bedre enn at de må runde av til nærmeste 10 grader).

 

edit: Må legge til at min kommentar var egentlig mest ment som en generell kommentar om avrunding ved usikre kildedata.

Endret 12. mars 2004 av Anders Leipsland

[Ravusy]

Tror nok denne disken mest rettet mot rom-programmer hvor mekansike disker vil bli et fare moment.

[sveinsel]

Tar et par og setter de i RAID da, siden aksesstid ikke er noe hinder...

[Simen1]

Heisann ja

Hmm.. Dette ble jo en lang PM. Tror jeg kopierer og limer den inn i posten min. Er jo informativt.

Sikkert en god ide

 

Utrolig tusen takk forresten, nydelig fremstilt. Hadde f. eks ingen anelse at RAM var *såpass* mye raskere enn en harddisk!

 

Nå som jeg har deg i så godt gir her: Hva er det som bestemmer søketiden til de forskjellige harddiskene og RAM? Og transfer for harddskene? Og disse fremtidige minnebrikkene jeg vet jeg leste om en gang - 10GB og mister ikke informasjon når strømmen går - ca hvor på denne skalaen vil de ligge, hvis du vet hva jeg snakker om?

 

Takker igjen

 

Heisann ja

Nå som jeg har deg i så godt gir her: Hva er det som bestemmer søketiden til de forskjellige harddiskene og RAM? Og transfer for harddskene? Og disse fremtidige minnebrikkene jeg vet jeg leste om en gang - 10GB og mister ikke informasjon når strømmen går - ca hvor på denne skalaen vil de ligge, hvis du vet hva jeg snakker om? 

Jeg tar utfordringen :

 

* Det som bestemmer aksesstiden for harddisker er hovedsaklig rotational latency (typisk 4,17 ms ved 7200rpm), flytting av lesearmen (typisk 6-7 ms), finjustering av lesehodet når det er i nærheten av riktig spor (typisk ca 1 ms), og behanding av kommandoer i elektronikken/firmware (typisk under 1 ms).

 

* Det som bestemmer transferrate er ene og alene hvor tett dataene ligger pakket langs hvert spor. F.eks ytterste spor på platene er diameteren 3,3 tommer, altså 263 mm i omkrets. Hvis da dataene ligger i en avstand av 0,1 mikrometer per bit så blir transfer-hastigheten 2630000 bit = per omdreining = 328750 Byte/omdreining. Så vet vi at en 7200rpm disk snurrer 7200 runder per sekund, altså 120 runder per sekund. Hvert sekund kan disken altså lese 120 runder*328750 Byte = 39,5 MB. Transfer-rate er altså 39,5 MB/s ytterst på denne disken. Moderne disker har nok litt høyere tetthet enn en bit per 0,1 mikrometer så de kan lese opp mot 60MB/s. Grunnen til at lesehastigheten synker innover på platen (Se f.eks HDtach-grafer), er at omkretsen blir mindre og dermed er det plass til færre bit på hver runde av sporet. Siden disken snurrer like mange runder per sekund om lesearmen er ytterst eller innerst på platene så vil det si at den leser færre bit per sekund innerst på platene enn ytterst.

 

* Aksesstid på ram er enkelt forklart det samme som Cas Latency. Hvis Ram'en går på 200MHz (slik som PC3200) og CL er 2 så kan vi regne slik: 200MHz = 200.000.000 sykluser per sekund. Dette vil si 0,000 000 005 sekunder per syklus. Når CL er 2 så bruker ram'en 2 sykluser på å hente ut data. Altså 2x0,000 000 005 = 0,000 000 01 s. Eller skrevet på en annen måte: 0,000 01 millisekunder (ms) = 0,01 mikrosekunder (us) = 10 nanosekunder (ns). I PC'er forsinker både Northbridge og FSB-kontrolleren både i NB og CPU'en signalet en del slik at total aksesstid sett fra CPU-kjernen blir mye lengre. Normalt ligger totalen på rundt 60-120 ns. Det at Athlon64 har integrert minnekontroller gjør at den mangler mange av disse forsinkende leddene og at aksesstiden dermed reduseres kraftig. Det er faktisk hovedgrunnen til at Athlon64 3000+ med 512 KiB L2 og 2,0GHz yter rundt 10-15% bedre enn Athlon XP 2800+ også med 512 KiB L2 og 2,0GHz. (Ingen tvil om at integrert minnekontroller er fremtiden, uansett produsent)

 

* Transfer-rate til ram bestemmes av minnebussen. (f.eks 200MHz i tilfellet PC3200) 200 MHz. Bussbredden er 64 bit (64 parlelle ledninger) og DDR-teknikken dobler antall bit per syklus. Dvs. 64 bit * 2 (for DDR) * 200 millioner syklyser per sekund /8 bit per byte = 3200 Byte per sekund. Hvis man kobler opp to minnekanaler i paralell ("dual channel") så dobles båndbredden til 6400 MB/s. Grunnen til at Sisoft Sandra og andre ikke viser dette tallet i praksis er at det sender mange små aksesser til minnet og at det dermed må vente en del sykluser (aksesstid) før det får begynne å lese neste bit med data. Je lengre aksesstiden og jo mindre som leses hver gang jo mer ytelse taper man. Dvs. resultatet i Sisoft sandra synker med dårligere total minneaksess. Dette er f.eks også grunnen til at Athlon64 med sin gode minnekontroller og lave aksesstid scorer høyere i Sisoft Sandra enn f.eks Athlon XP og Pentium4. (Pentium4 har veldig gode brikkesett så det er litt bedre enn AthlonXP på Single-channel, og AthlonXP gjør det dårlig fordi FSB er alt for liten til at begge minnekanalene kan brukes paralellt.)

 

* Jeg vet ikke hvilken ny minneteknologi du prater om, kanskje M-ram? I så fall tror jeg både transfer og aksesstid er mye dårligere enn moderne ram. Sansynligvis på nivå med PC100 CL3 SDram eller rundt der... Ikke at det er dårlig, for det er faktisk fortsatt vanvittig mye raskere enn harddisker, selv om det ikke akkurat kan måles med PC3200 CL2.

 

Puh.. Dette ble jammen peronlig rekord i PM

Jeg tar utfordringen :

Wohoo!

Puh.. Dette ble jammen peronlig rekord i PM 

Heh, det er bare fint det da, for min del iallefall Du burde kanskje tatt med dette her også i tråden da, det er iallefall interresant. Vurdert å skrive artikler for HW.no kanskje? Skal ikke se bort i fra at det er en mulighet nemlig, du skriver utrolig bra, lettforklart og detaljert.

Takker! Kopierer dette inn i tråden jeg. Vurderer å skrive litt for HW ja, men har "alltid" litt for lite tid til å få gjennomført noe skikkelig. Blir snart arbeidsledig og får nok godt med tid fra ca påsken av. Om jeg ikke får en jobb i Trondheim med en gang da. (håper det) Har et par "artikler" i hodet så det kan godt hende jeg får tid nok snart. Skal selvfølgelig ta kontakt med HW.no så snart artikkelen er klar. Hvis de ikke vil ha den så gi jeg den sikekrt bare til noen andre steder (kanskje digi, ITavisen til og med betaler meg litt honorar for slikt)

Uansett, hvis du fremdeles er i form til å øse ut med litt mer informasjon i dag også tenkte jeg at jeg skulle kommentere deler av det du skrev for å prøve å hale ut enda litt mer info fra deg på de punktene

* Det som bestemmer transferrate er ene og alene hvor tett dataene ligger pakket langs hvert spor. F.eks ytterste spor på platene er diameteren 3,3 tommer, altså 263 mm i omkrets. Hvis da dataene ligger i en avstand av 0,1 mikrometer per bit så blir transfer-hastigheten 2630000 bit = per omdreining = 328750 Byte/omdreining. Så vet vi at en 7200rpm disk snurrer 7200 runder per sekund, altså 120 runder per sekund. Hvert sekund kan disken altså lese 120 runder*328750 Byte = 39,5 MB. Transfer-rate er altså 39,5 MB/s ytterst på denne disken. Moderne disker har nok litt høyere tetthet enn en bit per 0,1 mikrometer så de kan lese opp mot 60MB/s. Grunnen til at lesehastigheten synker innover på platen (Se f.eks HDtach-grafer), er at omkretsen blir mindre og dermed er det plass til færre bit på hver runde av sporet. Siden disken snurrer like mange runder per sekund om lesearmen er ytterst eller innerst på platene så vil det si at den leser færre bit per sekund innerst på platene enn ytterst.

Så en fysisk større disk gir høyere overføringshastighet? Greit. Men altså, jeg har jo da hørt at man bør plassere operativsystemet "først" på disken, altså nærmest mulig midten, for høyest ytelse. Stemmer ikke det da eller? Og hvorfor tar det forresten såpass lang tid å flytte filer mellom partisjoner på samme disk? Eller sett fra en annen side: Hvorfor tar det så kort tid (ingen?) å flytte filer mellom ulike steder på en og samme partisjon?

* Fysisk større disk gir høyere transfer ytterst ja, og flere GB pga større areal av platene. Det gir derimot også lengre (=dårligere) søketider fordi lesearmen må bevege seg over et større område. Et eksempel på dette er de gamle Quantum-diskene som var svært rommelige for sin tid og sin pris, men ytelsen var svært dårlig pga svært lang aksesstid.

* Å flytte filer mellom partisjoner tar tid siden lesearmen må lese litt, bruke tid til å flytte seg langt (til den andre partisjonen), skrive der, flytte seg tilbkae igjen osv. Å flytte mellom to disker som ikke står på samme ATA-kabel går raskere siden den ene hele tiden kan stå på samme sted og lese, mens den andre hele tiden kan stå på samme sted og skrive. Altså to ting på en gang uten flytting av lesearmen. Å flytte filer innad på en og samme partisjon går ennå raskere. Man trenger egentlig ikke å flytte filen fysisk en gang, man bare skriver i indeksen til harddisken (=File Allocation Table, FAT) at denne filen ligger i en annen katalog enn den gjorde før. Altså ingen fysisk flytting av fila, kun endring av indeksen som forteller navnet på mappa den ligger i.

* Jeg ville hadd OS'et ytterst pga høy transfer og færre spor i bredden per GB. Dette gir litt lavere aksestid innad på partisjonen, samt at man kun har den høyeste transfer'en. For å få full utnyttelse av dette bør ikke resten av disken brukes så veldig hyppig. F.eks om den brukes til backup, video-arkiv, osv (som ikke deles ut på fildelingstjenester, siden de akesserer disken ofte)

 

* Aksesstid på ram er enkelt forklart det samme som Cas Latency. Hvis Ram'en går på 200MHz (slik som PC3200) og CL er 2 så kan vi regne slik: 200MHz = 200.000.000 sykluser per sekund. Dette vil si 0,000 000 005 sekunder per syklus. Når CL er 2 så bruker ram'en 2 sykluser på å hente ut data. Altså 2x0,000 000 005 = 0,000 000 01 s. Eller skrevet på en annen måte: 0,000 01 millisekunder (ms) = 0,01 mikrosekunder (us) = 10 nanosekunder (ns). I PC'er forsinker både Northbridge og FSB-kontrolleren både i NB og CPU'en signalet en del slik at total aksesstid sett fra CPU-kjernen blir mye lengre. Normalt ligger totalen på rundt 60-120 ns. Det at Athlon64 har integrert minnekontroller gjør at den mangler mange av disse forsinkende leddene og at aksesstiden dermed reduseres kraftig. Det er faktisk hovedgrunnen til at Athlon64 3000+ med 512 KiB L2 og 2,0GHz yter rundt 10-15% bedre enn Athlon XP 2800+ også med 512 KiB L2 og 2,0GHz. (Ingen tvil om at integrert minnekontroller er fremtiden, uansett produsent)

Hvordan fikk du forresten 200.000.000 sykluser per sekund. til å bli 0,000 000 005 sekunder per syklus?

 

Uansett tror jeg at jeg ikke helt forstår hva du snakker om når du snakker pm sykluser. Jeg vet at jeg en gang isste det sånn halvveis, at det har noe med hver gang CPU sender en request til minnet eller noe, men kan du forklare det nærmere/bedre?

 

Og såvid jeg vet er det ingenting som tyder å at Intel kommer til å bytte over til integrert minnekontroll snart. Hvorfor ikke, siden det gir en såpass stpr ytelsesforberedning?

* Tid per syklus = 1/(sykluser per tid), = 1/ (200.000.000 sykluser per sekund) = 0,000 000 005 sekunder per syklus. Det er sikkert lettere med andre tall: 2Hz = 2 sykluser per sekund. Tid per syklus blir da 1/(2 sykluser per sekund) = 0,5 sekund per syklus.

 

* En syklus er ett eller annet som skjer med jevne mellomrom, det kan være bilder per sekund, bølgetopper per sekund (som f.eks i lyd), vekselstrøms-sykluser per sekund (sinus-kurve) eller digitale sykluser med firkantpulser per sekund.

 

* Jeg tror nok Intel også kommer til å gå over til integrert minnekontroller. Om ikke snart, så sikkert innen 2-3 år. Når det er sagt så har Intel bedre cache og prediction enn AMD så de får nok ikke like formidabel ytelseøkning som AMD fikk. Både AMD og Transmeta har gjort det, og VIA er vel ganske klar for det så snart markedet ønsker det (de har jo store interresser innen chipsett også så de vil nok ikke komme det før de må). Dette er altså ting i tiden, så Intel følger vel etter før eller senere.

* Transfer-rate til ram bestemmes av minnebussen. (f.eks 200MHz i tilfellet PC3200) 200 MHz. Bussbredden er 64 bit (64 parlelle ledninger) og DDR-teknikken dobler antall bit per syklus. Dvs. 64 bit * 2 (for DDR) * 200 millioner syklyser per sekund /8 bit per byte = 3200 Byte per sekund. Hvis man kobler opp to minnekanaler i paralell ("dual channel") så dobles båndbredden til 6400 MB/s. Grunnen til at Sisoft Sandra og andre ikke viser dette tallet i praksis er at det sender mange små aksesser til minnet og at det dermed må vente en del sykluser (aksesstid) før det får begynne å lese neste bit med data. Je lengre aksesstiden og jo mindre som leses hver gang jo mer ytelse taper man. Dvs. resultatet i Sisoft sandra synker med dårligere total minneaksess. Dette er f.eks også grunnen til at Athlon64 med sin gode minnekontroller og lave aksesstid scorer høyere i Sisoft Sandra enn f.eks Athlon XP og Pentium4. (Pentium4 har veldig gode brikkesett så det er litt bedre enn AthlonXP på Single-channel, og AthlonXP gjør det dårlig fordi FSB er alt for liten til at begge minnekanalene kan brukes paralellt.)

Hvorfor er bussbredden bare 64bit? Og hvorfor velger ikke AMD å finne på ett eller annet Quad-system de også? Men det Quad-greiene, hvordan fungerer det? (Blir noe off topic inni her jo )

* Tja, flere bit minnebredde betyr at man må ha flere minnemoduler for å utnytte alle. F.eks om man skal kjøre Quad minnekalaner så må man ha hele 4 minnebrikker. Dette koster både i plass på hovedkortet, koster i form av mer avanserte kretskort (flere lag og mer innsats for å designe de), flere pinner på CPU'en og selve minne-slot'ene. Alt i alt blir det nok bedre, men til en svært høy pris og er kanskje litt upraktisk for de fleste å ha 4 minnemoduler. (sælig om du vil ha noen plasser til så du kan oppgradere)

* Hvis du tenker på Quad FSB, så har AMD nettopp unngått dette ved å fjerne hele FSB'en og ha to typer tilkoblinger direkte til CPU'en i stedet for FSB: HyperTransport-bussen(e) og direkte minnebuss(er). (i flertall for Opteron) Dette er bedre enn en hver FSB uansett hastighet siden det både forenkler designet av hovedkort, chipsett og øker ytelsen til både minnet og resten av systemet.

* Jeg vet ikke hvilken ny minneteknologi du prater om, kanskje M-ram? I så fall tror jeg både transfer og aksesstid er mye dårligere enn moderne ram. Sansynligvis på nivå med PC100 CL3 SDram eller rundt der... Ikke at det er dårlig, for det er faktisk fortsatt vanvittig mye raskere enn harddisker, selv om det ikke akkurat kan måles med PC3200 CL2.

Hva er den største flaskehalsen i systemer i dag? Hvor mye værre ville det blitt med PC100 CL3 da?

Den største flaskehalsen.. Hmm vanskelig spørsmål siden det er så mange bruksområder og så mange ting som kunne vært bedre, men jeg skal prøve å luke ut et par værstinger:

* Internett-forbindelser (både transfer og aksesstid)

* Harddisker (aksesstid)

Takker iallefall på forhånd til at du tar deg tid til å lære andre. Du burde virkelig skrive opplysningsartikler for HW.no, lignende den Hvordan lages CPUer"-tingen de skrev

Takk igjen. Du skal ikke se bort i fra at det kommer en artikkel om en måneds tid... Håper noen gadd å lese alt dette. En evt artikkel kommer selvfølgelig til å være rikt illustrert og mindre tekst.

PS. Fikk erroren:

FØLGENDE FEILMELDING(ER) BLE FUNNET

Innlegget ditt inneholder flere smilies enn tillatt. Venligst reduser antall smilies i inlegget ditt

Hehe Endret 13. mars 2004 av Simen1

[AimAr]

Den var inponerende Simen1!

[OCSpro]

Angående avrunding. Det er ikke nødvendigvis så ille, heller tvert om. Det er større feil å angi tall med for mange desimaler enn for få. Det heller kommer an på hvor store feilmargin du har.

 

f.eks to harddisker hvor en får 8.6 og en får 9.2 hvor en feilmarin er på kanskje +/-0.5 så vil det være riktig å oppgi begge som 9.

Hva om den ene disken er 8,4ms og den andre er 8,6ms. Synes du det er rettferdig om de får oppgitt hhv. 8ms og 9ms som søketider? Folk kan jo til og med tolke det til at den dårligste kan ha ned til 9,4ms og den beste 7,6ms. Altså en enorm forskjell..

Hele poenget når en oppgitt feilmargin er +-0.5 er at resultatet ditt nettopp kan være 9,4ms for den dårligste og den beste 7,6ms...

 

Det å ta flere målinger fra flere hold hjelper nettopp å minske feilmarginen og få et mer nøyaktig tall.

 

Fysikken lover er fastsatt, ingen unnasluntring...

[Simen1]

Angående avrunding. Det er ikke nødvendigvis så ille, heller tvert om. Det er større feil å angi tall med for mange desimaler enn for få. Det heller kommer an på hvor store feilmargin du har.

 

f.eks to harddisker hvor en får 8.6 og en får 9.2 hvor en feilmarin er på kanskje +/-0.5 så vil det være riktig å oppgi begge som 9.

Hva om den ene disken er 8,4ms og den andre er 8,6ms. Synes du det er rettferdig om de får oppgitt hhv. 8ms og 9ms som søketider? Folk kan jo til og med tolke det til at den dårligste kan ha ned til 9,4ms og den beste 7,6ms. Altså en enorm forskjell..

Hele poenget når en oppgitt feilmargin er +-0.5 er at resultatet ditt nettopp kan være 9,4ms for den dårligste og den beste 7,6ms...

 

Det å ta flere målinger fra flere hold hjelper nettopp å minske feilmarginen og få et mer nøyaktig tall.

 

Fysikken lover er fastsatt, ingen unnasluntring...

Feilmarginen er ikke oppgitt til å være +-0,5 ms!

 

Det med feilmarginen var bare et eksempel fra AL sin side. Så vidt jeg vet har han ikke sjekket opp hva feilmarginen faktisk er. I dette tilfellet vil jeg si at avrundingen er mye større en feilmarginen, og at det dermed blir selve avrundingen som blir det største usikkerhetsmomentet.

 

Se på den nye og den gamle grafen fra testen og den nye jeg lagde i en post lengre opp her. Der ser du på Seagate, WD og Maxtor hvor nøyaktig resultatene bør bli med et slikt test-program. Hvis ikke Sisoft Sandra klarer å måle dette med større nøyaktighet enn +-0,5ms så vil jeg si at de like gjerne kunne latt være å ha med denne testen i programmet sitt. Det blir like variabelt som å måle to skjermkort opp mot hverandre i en eller annet FPS-test og avrunde bort alle tallene etter det første sifret. F.eks slik at 55-64 FPS avrundes til 60 FPS og 65-74FPS avrundes til 70FPS. Dette er også en for grov avrunding. Unøyaktigheten ligger nok på rundt 1-2FPS, men likevel oppgis ofte resultatene i tester med 1-2 siffer bak komma.