www.pegasos.org :: View topic - ide hårddiskar 7200rpm

www.pegasos.org

Aktuellt, allmänt och övrigt - ide hårddiskar 7200rpm

gurking - Sep 08, 2004 - 22:38
Post subject: ide hårddiskar 7200rpm

Enligt rykten så finns det inga snabbare ide-hårddiskar
än 7200rpm. Detta innebär ju ett allvarligt problem, kanske inte för
oss som använder Pegasos/MoprphOS eller AmigaOne/AmigaOS.

PC/Windowsfolket kommer till slut inte kunna uppleva den snabbhet
man upplevde förut då alla program var så små och startade snabbt.

Nu blir program allt större och tar längre tid att starta och då blir ju
ide-hårddiskar själva proppen till slut oavsett hur snabb processor
man har så kommer ide-hårddisken vara motstånden som
släpa efter i prestandan.

Om Windowsprogram ska fortsätta och bli större så kommer en
ide-hårddisk 7200 kännas som en gammal hårddisk rasslande
och trög.

Vad innebär det då om man vill ha en snabb hårddisk efter hårdvaran och den jättesnabba processor.

Antagligen dessa dyra SCSI-hårddiskar 68-pin på flera tusen rpm.

dholm - Sep 08, 2004 - 23:00
Post subject:

Eller S-ATA på 15.000 RPM som är billigare.
Ett större problem som existerat på x86 ett tag är väl iofs hastigheten på billiga RAM-minnen.

gurking - Sep 09, 2004 - 11:07
Post subject:

Det beror på vilka egemskaper en sådan hårddisk har?

Vad jag vet är att en SCSI-hårddisk kan läsa och skriva samtidigt
då en IDE-hårddisk bara växlar mellan läs och skriv.

Det innebär alltså att en IDE-hårddisk får dubbelt så mycket jobb.

Min begagnade SCSI-hårddisk fast den också är på 7200rpm 2mb Cache
känns snabbare på något sätt. Hur kommer det sig?

Det borde innebära alltså att dessa riktigt tunga Windowsprogram lagrar
så stora tillfälliga arbetsfiler medan man gör något. Hårddisken rasslar
jäktigt för att hinna med. Som om hårddisken på gränsen var för långsam.

Med en SCSI-hårddisk blir det inte så och tunga krävande program
startar lätt och knappt något motstånd. Att konvertera något till något annat går mycket fortare och inte så trögt och rassligt,
fast det är 7200rpm och 2mb cache.

Hur förklarar du det?

dholm - Sep 09, 2004 - 11:44
Post subject:

Kör inte windows.

Trizt - Sep 09, 2004 - 14:18
Post subject:

gurking wrote:

Min begagnade SCSI-hårddisk fast den också är på 7200rpm 2mb Cache
känns snabbare på något sätt. Hur kommer det sig?

Cache storleken gör stor skillnad och sen så brukar SCSI vara bättre eftersom den har en hel del logik på hårddisken, medans IDE har behov av CPU:n för logiken.

gurking wrote:

Det borde innebära alltså att dessa riktigt tunga Windowsprogram lagrar
så stora tillfälliga arbetsfiler medan man gör något. Hårddisken rasslar
jäktigt för att hinna med. Som om hårddisken på gränsen var för långsam.

Microsoft Windows är inget man ska använda sig av ifall man vill göra nått på riktigt. En stor bov i ms-windows är dess swap-fil, den är satt till at ha en dynamisk storlek, vilket betyder att den byter storlek helatiden när man använder datorn. Det blir en hel del extra IDE access och det tär även på CPU:n.

gurking wrote:

Med en SCSI-hårddisk blir det inte så och tunga krävande program
startar lätt och knappt något motstånd. Att konvertera något till något annat går mycket fortare och inte så trögt och rassligt,
fast det är 7200rpm och 2mb cache.

Installera MS-windows enbart på SCSI, så kommer du att märka av en nerslöing av systemet. Vad man istället kan göra är att installera en *nix istället så som linux eller qnx.

gurking - Sep 09, 2004 - 14:44
Post subject:

gurking skrev:
Med en SCSI-hårddisk blir det inte så och tunga krävande program
startar lätt och knappt något motstånd. Att konvertera något till något annat går mycket fortare och inte så trögt och rassligt,
fast det är 7200rpm och 2mb cache.

Trizt skrev

Quote:

Installera MS-windows enbart på SCSI, så kommer du att märka av en nerslöing av systemet. Vad man istället kan göra är att installera en *nix istället så som linux eller qnx.

Men hallå! Har du inte missuppfatttat? Jag skrev ju att program
startade snabbare. Här verkar du säga tvärtom, eller vad då installera
enbart på SCSI?

I början sa du SCSI-hårddiskar arbetar jobbar snabbare på grund av
och slutar med motsatsen. Vart vill du komma?

Windows är installerad på SCSI-hårddisken

Trizt - Sep 09, 2004 - 16:37
Post subject:

gurking wrote:

Om du har MS-windows installerad på IDE och sen har en massa program på SCSI, så kommer du inte märka av swap-fils ändringarna på SCSI enheten eftersom den ligger på IDE hårddisken, men ifall du BARA hars SCSI, så kommer swap-filen ligga på SCSI:n och eftersom SCSI:n behöver jobba med att ändra storleken, så kommer den att ah mer saker att göra, vilket leder till att även den kommer att minska i prestanda. Stor del av felet ligger i det dåliga operativsystemet.

Detta är bara en omformulering av vad jag skrev innan.

gurking - Sep 10, 2004 - 12:19
Post subject:

Trizt wrote:

gurking wrote:

Har du cencurerade ögon?

Jag skrev ju att Windows är på SCSI-hårddisken. Tror du att jag sitter
här och påstår något utan att ha Windows på SCSI-hårddisken?
Då är man ju självklart bakom flötet, men så ligger det ju inte till.

Jag skrev ju att det gick mycket snabbare program startade snabbare
och känns snabbare bla bla bla såvidare.

Jag tycker att jag har varit tillräcklig konsekvent. Varför ska andra då
ändra på det som är sagt och påstå något som jag varken sagt.

Vad är svårigheten att svara efter det som är sagt

gunne - Sep 10, 2004 - 12:42
Post subject:

Hejsan !

Ni pratar nog lite om varandra ? Cool

Ni verkar vara överrens om att scsi-tekniken alltid presterar bättre än IDE.

Ni verkar också vara överrens om att t.ex Linux som operativsystem hanterar disk-aktiviteter bättre än vad t.ex Windows gör.

Liksom MorphOS & AmigaOS också gör det, betydligt responsivare och kvickare Very Happy

gurking - Sep 10, 2004 - 17:02
Post subject:

Ja haa.

Så kommer gunne in och kommenterar då det blir strul.

Har du råkat sett på Idol på tv4? Tyvärr är jag inte sådan som lipar
för själva sanningen.

Du får gärna peka ut någon här. Du verkar hellre låta bli det.

Varsågod och kör med hård kritik, säg något som
- Skulle jag sitta i samma möte som du och diskutera detta så skulle
ambulansen fått hämta mig.

gunne - Sep 10, 2004 - 17:52
Post subject:

He he... men gurking Wink

Idol på TV 4 Question

Hur det nu än är kommer inte IDE bli bättre än Scsi..., inte en chans... Wink

Och du får komma på något möte någon gång.

gurking - Sep 10, 2004 - 19:29
Post subject:

Då går vi över till hållbarhet.

Enligt vad nån sagt är att scsi-hårddiskar lätt blir överhettade då
hårddisken arbetar nästan oavbrutet och då fungerar inte den
så bra längre

Dom blir ganska så rassliga efter flera års användning. Men än har jag
inte upptäckt någon förändring med tröghet.

Det vore ju praktisk om man kunde välja vilken hastighet man vill
ha på en defekt hårddisk att ställa från 7200rpm till 4000rpm
så kanske defektheten inte blir av.

gunne - Sep 12, 2004 - 08:15
Post subject:

Hej

Jo, det finns ju alltid en risk att hårddiskar kan bli överhettade, varför kylning kan behövas, speciellt om hårddisken konstant arbetar intensivt.

Själv har jag alltid haft goda erfarenheter av scsi-hårddiskar, har alltid fungerat väldigt bra, och framförallt snabbt. Kommer fortfarande ihåg två boxar jag hade för flera år sedan med två stora 5.25" scsi-hd i varje på 2GB vardera. De var mycket snabba, och stabila och bra, men lät ordentligt, och tog också någon minut innan de snurrat upp i full speed när de varit avstängda Smile

Om vi går tillbaka till operativsystem, och då för persondatoranvändande, så borde det vara en fröjd för en hårddisk att sitta med t.ex AmigaOS eller MorphOS, jämfört då med Windows. Som alla vet, så kan det t.ex räcka att man får för sig lägga på ett filter eller en blur i målningsprogrammet i Windows för att hårddisken skall spinna igång och börja arbeta oavbrutet. Det är skillnad i systembyggnaden.

Att kunna välja hastighet hårddisk snurrar i kanske vore något, har inte reflekterat över det.

Trizt - Sep 12, 2004 - 10:52
Post subject:

gunne wrote:

Varken AmigaOS eller MorphOS har en swap-fil (inte heller linux) och swapfilen är automatiskt dynamisk i ms-windows, så när du använder mer ram, så förstoras swap-filens storlek och när man har mer fritt ram, så misnaks swap-filens storlek, eftersom detta sker så gott som konstant, så är det mycket mer disk aktivitet på en ms-windows burk än på MorphOS. Tar man bort swap-filen eller setter en fix storlek på den, så kommer disk aktiviteten att drastiskt minska och maskinen kommer att kännas mycket snabbare.
Om MorphOS binärerna hade varit lika ooptimerade som i ms-windows, så hade man sett att disk hastigheten hade varit gnaska så lika.

dholm - Sep 12, 2004 - 11:08
Post subject:

Ett stort problem med att ha en swap-fil som windows har är ju att när den växer så har du ingen garanti öht att du får konsekutiva sektorer lediga. Om det inte gör det så blir filen snabbt fragmenterad och prestandan sjunker snabbt. I Linux så har du ju en swap-partition som alltid garanterar att du slipper fragmenteringen, det som dock kan hända där är att du får en fragmentering av minnessidorna när de lagras i swappen. Sannolikheten för det är ju dock mycket lägre eftersom man oftast swappar/läser in samma block av minnessidor.

gurking - Sep 12, 2004 - 14:16
Post subject:

Quote:

Varken AmigaOS eller MorphOS har en swap-fil (inte heller linux)

Vilka Linux versioner menar du då?

Vad jag har sett så har RedHat och Mandrake swap-fil
Det ser man då den partitionerat hårddisken under installationer
så finns det ett utrymme som är swap-filen

gurking - Sep 12, 2004 - 14:20
Post subject:

Quote:

dholm: Ett stort problem med att ha en swap-fil som windows har är ju att när den växer

I min Windows kan det inte hända. Har förbestämt storleken Smile

dholm - Sep 12, 2004 - 14:23
Post subject:

Quote:

Vad jag har sett så har RedHat och Mandrake swap-fil
Det ser man då den partitionerat hårddisken under installationer
så finns det ett utrymme som är swap-filen

Nej. Du har en swap-partition, inte en swap-fil. En partition garanterar ju att du slipper extern fragmentering.

Quote:

I min Windows kan det inte hända. Har förbestämt storleken

Filen kan fortfarande ha blivit fragmenterad när den skapades.

Trizt - Sep 12, 2004 - 14:31
Post subject:

gurking wrote:

I min Windows kan det inte hända. Har förbestämt storleken

När man installerar MS-Windows så är swapfilen automatisk dynamisk, sen när du ändrar till statisk och rebootar, så behöver inte filen längre vara en sammanhängande fil.

gurking - Sep 12, 2004 - 14:40
Post subject:

[b]dholmFilen kan fortfarande ha blivit fragmenterad när den skapades.[/b]

Än så länge har Microsoft valt att ha ett så dåligt filsystem oavsett fat eller ntfs då det redan är fragmenterat innan man ens hunnit göra något.

gurking - Sep 12, 2004 - 19:14
Post subject:

Hur skulle universum se ut om den var av ett filsystem som kan fragmenteras?

Plötsligt så delas sig alla stjärnor i flera tusen bitar och hamnar på flera tusen olika ställen bara för att dom har förflyttat sig i sin bana. Det blir svårt att resa då det kan ta flera timmar från Arlanda och till Karlstad på grund av att fragmentet hamnat flera ljusår bort i rymden.

Det kan ju framkomma vissa problem att man känner sig dålig då kroppen utsätter sig för snabb tidsresa då målet befinner sig flera ljusår bort. Det gäller att se upp då man stiger av, tiden kanske inte hunnit läsa av verkligheten då samtliga mål tar tid att rita upp.

Stjänstorna lyser ju och fragmentet kommet att göra så att hela universum bli kritvitt och alla planeter bräns upp till koll och aska.

gunne - Sep 12, 2004 - 19:53
Post subject:

Hej

Först lite ang fragmentering. Det uppstår pga att filer skrivs och raderas om vart annat, och uppstår i alla system. Vissa filsystem har inbyggt funktion, som skall motverka fragmentering, dvs filsystemet har i sig själv inbyggt att kunna flytta data, i mål att bygga ihop filer som blivit fragmenterade, dvs block som filen består av och som blivit placerade på olika ställen (ej i följd) på diskens yta. Inget kan dock vara absolut, eftersom alla filsystem byggs upp av statiska fasta block och storlek definierad.

PFS har t.ex en sådan funktion inbyggd. Men även här kan en fragmentering vara märkbar efter en längre tid, och gör man då en kopiering av data + omformattering + återskrivning av datan, kan man notera en ganska rejäl speedup.

PFS har förövrigt en del andra bra funktioner också.

Är blocken t.ex 1024KB i storlek, och filen endast 512KB tar filen ändå upp 1024KB av diskens yta.

Ovan förenklat beskrivit, och en djupare analys är möjlig Smile

För att försöka tillföra ytterligare till debatten om jag kan... Wink

, tänkte jag nämna att t.ex programmet ArtEffect använder Swapfil. Rent praktiskt innebär det att du inte är begränsad till hur mycket primärminne du har i maskinen i hur stora bildfiler du kan hantera t.ex. Så länge diskens storlek och swapfilen räcker till, kan du alltid ladda in filen, och jobba med den.

Till AmigaOS & MorphOS finns den utmärkta uppfinningen datatyper. Det är väldigt käckt iom att så länge någon gjort en datatyp för ett filformat, bildformat eller vad det nu kan vara, kan du alltid använda formatet i programmet om programmet kan använda datatyper,... smidigt och bra Smile

En begränsning med datatyper är dock just det att de endast kan använda primärminne, dvs du är begränsad till hur mycket ledigt minne du har i maskinen. Iofs är det kanske inte så ofta man hanterar så stora filer att ledigt minne inte räcker till, speciellt som minne är relativt billigt, och man med Pegasos t.ex använder vanligt DDR. Operativsystemet, MorphOS-systemet tar ju heller inte upp så mycket minne, och fungerar också här lite annorlunda än vad t.ex Linux gör.

Avslutar man ett program i MorphOS, så är grundregeln att använt minne återlämnas fritt till systemet att använda för annat. Inte alla program som gör korrekt iofs. I Linux återlämnas ej minnet, förräns operativet behöver använda minnet till något annat.

Tja, nu kommer jag inte på mer just nu, kommentera gärna Smile

dholm - Sep 12, 2004 - 20:47
Post subject:

I Linux frigörs minnet när ett program avslutas. Kerneln förfogar dock över allt ledigt minne för cachning och buffring för övriga processer. Det fungerar på samma sätt som när du ger en process en hög prioritet och en ytterligare process behöver mer CPU-tid.

Vad gäller sektorstorlek så har du det problemet på alla filsystem.

gurking - Sep 12, 2004 - 21:02
Post subject:

Vad jag menar med tridsresa till ett mål är att jobbets dator för några år sedan råkade ut för ett programfel, som fick svårt att läsa in program i rätt ordning för att hårddisken var väldig fragmenterad.

Vet inte vad det programfelet hette.

dholm - Sep 12, 2004 - 21:07
Post subject:

Det vet jag, det heter microsoft windows.

gurking - Sep 12, 2004 - 21:32
Post subject:

Jo men när hårddisken fragmenteras så hamnar ju alla filer på olika stället. Som vi som användare får skåda hårddiskens programfiler som uppställda i kuliser fast allt egentligen ligger i en bedrövlig oreda.

Brukar använda Norton Speed Disk där man kan se var programfilerna
har hamnat. Oj mp3-filen ligger där borta och den här mp3-filen där, fast dom ligger i samma mapp ehh Shocked

dholm - Sep 12, 2004 - 22:06
Post subject:

Nästa steg är ju objektorienterade filsystem. Då hamnar du ännu en abstraktionsnivå högre. GNOME Storage är ett sånt projekt, DBFS är KDEs implementation.

gunne - Sep 13, 2004 - 15:01
Post subject:

Hejsan !

Mera diskussioner. Smile

dholm:

# I Linux frigörs minnet när ett program avslutas....

Jo, det var just nyansskillnaderna jag lite var ute efter här. I MorphOS ligger inte minnet cashat för programmet när programmet avslutas, utan noteras som fritt minne. En liten nyansskillnad här tycker jag nog det känns som.

Jag är inte helt 100% inne i Linux i alla detaljer, men tycker jag ser nyanskillnader.

I MorphOS kan också minne cachas för program att existera i, vilket man kan göra via kommandot Addbuffers t.ex.

gurking:

Problemet med fragmentering är egentligen inte att filer hamnar på olika ställen, utan kanske snarare att blocken som filen består av, ej ligger i följd på diskens yta, utan utspridda på diskens yta. Vilket i sig innebär att läshuvudet får hoppa fram och tillbaka, kanske långa sträckor, när enstaka filer läses/skrivs. Skall dessutom swap-block skrivas samtidigt som filen läses får läshuvudet hoppa än mer.

Jag vet ej om det finns något program som kan se till att filer som hör till samma mapp/katalog kan skrivas i följd på diskens yta. Tror ej heller defragmenteringsprogram kan göra det, men jag kan vara dåligt informerad här. Det som kan göra detta är processen, kopiering - omformattering - återskrivning. Då alla filer då kommer att bli skrivna i turordning till diskens yta på partitionen. Redan dagen efter borde dock denna ordningen ej vara giltig längre.

dholm - Sep 13, 2004 - 16:32
Post subject:

Quote:

ag vet ej om det finns något program som kan se till att filer som hör till samma mapp/katalog kan skrivas i följd på diskens yta. Tror ej heller defragmenteringsprogram kan göra det, men jag kan vara dåligt informerad här.

Eh, det är ju just det som defragmenteringsprogram gör.

gunne - Sep 13, 2004 - 16:40
Post subject:

Vad för något ? Sorterar filer ? Smile

Edit:

Hmm, postar detta för att försöka understödja min teori. Kan bara hitta denna lite gamla texten just nu.

x--x

* directory fragmentation: In contrast to other operating systems
(e.g. MS-DOS), AmigaDOS does not store directory data in a single
consecutive block. This leads to weak performance for directory
listings, unless the new Directory-Cache-FileSystem (DOS\4,DOS\5)
is used. ReOrg tries to store directory data as closely together
as possible. This considerably speeds up commands like `dir' and
`list' and the directory display within file requesters.

x--x

Men jag låter mitt påstående stå kvar tills dess att motsatsen är bevisad Smile

Alltså, ett defragmenteringsprogram försöker bygga ihop en fil som blivit uppsplittat i olika ej varandra närliggande block.