Gathering of Tweakers

Ik heb een MTron 16Gb aan een DP35DP mobo van Intel gehangen. Als je in de BIOS IDE selecteert ipv AHCI, dan blaast hij erdoor. Snelle initialisatie en snelle boot van Vista.

Nou Femme, ik heb weer met mn volle aandacht gekeken, en ik kan ook alleen maar zeggen dat het een geweldige benchmovie is Ik bedoel, je ziet duidelijk de verschillen en het is ook duidelijk dat je moet opletten dat als je een controllercard gebruikt, dat je te maken krijgt met langere boot tijden.

Ik ben ik erg blij om te horen dat de 1200 niet het initialisatie "probleem" heeft dat de 1280 nu ontzettend vertraagt. De ARC-1200 & Mobi lijkt mij de gouden combo voor de meeste tweakers hier:
- lagere prijs dan normale cache controllers
- PCI-E interface
- betere prestaties dan onboard, vooral dankzij specifieke I/O processor en local cache
- zelfde initialisatie tijd als onboard

ik ben overtuigt Nou nog het geld.

Welk bestandssysteem is het meest geoptimaliseerd voor SSD's?

Ik neem aan dat de huidige systemen zijn geoptimaliseerd voor HDD access, en daarom minder geschikt zijn voor SSD's. De huidige bestandssystemen zijn ook in het geheel niet ontworpen met SSD in het achterhoofd.

quote:

XanderDrake schreef op woensdag 26 maart 2008 @ 15:49:
Nou Femme, ik heb weer met mn volle aandacht gekeken, en ik kan ook alleen maar zeggen dat het een geweldige benchmovie is Ik bedoel, je ziet duidelijk de verschillen en het is ook duidelijk dat je moet opletten dat als je een controllercard gebruikt, dat je te maken krijgt met langere boot tijden.

Ik ben ik erg blij om te horen dat de 1200 niet het initialisatie "probleem" heeft dat de 1280 nu ontzettend vertraagt. De ARC-1200 & Mobi lijkt mij de gouden combo voor de meeste tweakers hier:
- lagere prijs dan normale cache controllers
- PCI-E interface
- betere prestaties dan onboard, vooral dankzij specifieke I/O processor en local cache
- zelfde initialisatie tijd als onboard

ik ben overtuigt Nou nog het geld.

hoeveel zou dat zijn samen?

quote:

Ruudjah schreef op woensdag 26 maart 2008 @ 21:06:
Welk bestandssysteem is het meest geoptimaliseerd voor SSD's?

Ik neem aan dat de huidige systemen zijn geoptimaliseerd voor HDD access, en daarom minder geschikt zijn voor SSD's. De huidige bestandssystemen zijn ook in het geheel niet ontworpen met SSD in het achterhoofd.

Elk modern filesystem is gericht op het verlagen van het aantal I/O requests per file 'action', zodat het systeem zo min mogelijk op het 'trage' medium hoeft te wachten. Een SSD is vergeleken met het werkgeheugen nog steeds 'traag', vergeet niet dat de gemiddelde access time maar een factor 10 lager is geworden bij een SSD, dat is voor de gebruiker relatief veel maar voor de CPU is het nauwelijks een verschil vergeleken met zijn eigen wachttijden.

En dan komen nog de andere voor- en nadelen erbij kijken. Bij een OS als Windows zit je sowieso aan NTFS vast, FAT is weliswaar marganiaal sneller op erg kleine schijven maar ook stukken meer onbetrouwbaar waardoor het praktisch nutteloos is, zeker met RAID 0. Bij Linux kan je nog wat meer kiezen, maar als je performance wilt kies je, SSD of niet, toch voor XFS.

quote:

Lekkere Kwal schreef op donderdag 27 maart 2008 @ 00:45:
[...]
Een SSD is vergeleken met het werkgeheugen nog steeds 'traag', vergeet niet dat de gemiddelde access time maar een factor 10 lager is geworden bij een SSD, dat is voor de gebruiker relatief veel maar voor de CPU is het nauwelijks een verschil vergeleken met zijn eigen wachttijden.

Het verschil in toegangstijd is bij een Mobi ongeveer een factor honderd ten opzichte van een 15.000 toeren schijf en een factor tweehonderd ten opzichte van een 7200 toeren hdd. Het verschil is dus erg fors, hoewel geheugen met een toegangstijd van 0,06ms uiteraard nog steeds traag is vergeleken met de latencies van RAM-geheugen, laat staat L1-cache op een cpu. Dit doet echter niets af aan het feit dat een ssd véél sneller te benaderen is dan een hdd. 200 keer minder traag is aanzienlijk minder traag.

quote:

Niek1616 schreef op woensdag 26 maart 2008 @ 21:19:
hoeveel zou dat zijn samen?

270€ voor de Mtron Mobi en 150€ voor de ARC-1200, dus 420€ totaal.

En Femme, enig succes met de ARC-1200 op een ander systeem?

quote:

Moogles schreef op dinsdag 04 maart 2008 @ 15:52:
[...]
Ik heb eind januari mijn bestelling geplaatst, en nadat de leverdatum voor de 4de keer was gewijzigd heb ik mijn bestelling geannuleerd. "Gewoon" leverbaar is dus voor interpretatie vatbaar.

Inmiddels zijn ze schijnbaar weer op voorraad, want ik heb afgelopen zondag een MTRON Mobi 2.5" 32GB besteld en die werd woensdag al bezorgd!

Kun je die MTRON 2,5" gewoon aan een standaard SATA kabel hangen of heb je nog verloopstekkers nodig o.i.d.? Ik vraag dit omdat ik de rest van mijn systeem nog niet bezorgd is en bij de MTRON's zit geen handleiding (wel beetje vaag natuurlijk )...

Hij heeft gewoon sata-connectors die je maar op één manier kunt aansluiten, daar heb je geen handleiding bij nodig.

quote:

XanderDrake schreef op donderdag 27 maart 2008 @ 10:16:
[...]

En Femme, enig succes met de ARC-1200 op een ander systeem?

Hij werkt gewoon om een Intel Bad Axe (975X). Het Iwill-moederbord is vrij oud (september 2004 gepresenteerd) en dat zorgt kennelijk voor problemen.

quote:

Femme schreef op donderdag 27 maart 2008 @ 13:17:
Hij werkt gewoon om een Intel Bad Axe (975X). Het Iwill-moederbord is vrij oud (september 2004 gepresenteerd) en dat zorgt kennelijk voor problemen.

Mooi
Ja, inderdaad, je Iwill Opteron werkpaardje is niet de nieuwste meer. Het zou een van de eerste mobo's moeten zijn met PCI-E nu ik bedenk.
Ik hou je blog in de sniezen

Ik gebruik het bord al sinds april 2005. In 2006 heb ik er een identiek systeem bijgebouwd. Het was destijds een van de eerste mobo's met pci-x, pci express en onboard video. De cpu performance is voor de storage tests niet van belang maar als zo'n mobo niet meer compatible is wordt het tijd om over te gaan schakelen op iets nieuws.

Hoe denken jullie dat de MTron' s op een stevige Adaptec zullen presteren, zoals: http://www.adaptec.com/en...ch/sata_drives/SAS-51645/

Ze claimen daar 1.2GB/sec en 250.000 IOps uit die controller.

Dat moet sneller zijn dan de Areca's ofniet?

quote:

Snow_King schreef op donderdag 27 maart 2008 @ 15:42:
Hoe denken jullie dat de MTron' s op een stevige Adaptec zullen presteren, zoals: http://www.adaptec.com/en...ch/sata_drives/SAS-51645/

Ze claimen daar 1.2GB/sec en 250.000 IOps uit die controller.

Dat moet sneller zijn dan de Areca's ofniet?

Dat ziet er inderdaad stevig uit. Sowieso een stuk zwaarder dan de ARC-1200.

Kwa prestaties zal die wel goed zitten, maar ik weet presoonlijk niet hoe goed de cache management is van dit soort controllers. En daar kan je de Mobi juist mee verbeteren.

quote:

Snow_King schreef op donderdag 27 maart 2008 @ 15:42:
Hoe denken jullie dat de MTron' s op een stevige Adaptec zullen presteren, zoals: http://www.adaptec.com/en...ch/sata_drives/SAS-51645/

Ze claimen daar 1.2GB/sec en 250.000 IOps uit die controller.

Dat moet sneller zijn dan de Areca's ofniet?

Areca heeft op de CeBit ook adapters met een 1,2GHz IOP348 aangekondigd. Zie reviews: Cebit 2008: Storage en servers .

Mijn ervaring is dat de cache op Areca's een groter effect op de prestaties heeft dan bij Adaptec.

Met de ARC-1200 is zo'n Adaptec 51645 natuurlijk niet te vergelijken. Areca's alternatief hiervoor is de ARC-1680ix-24. Het geheugen op deze kaart kun je trouwens upgraden naar 4GB.

Het was ook nooit de bedoeling dit tegenover de 1200 te vergelijken. Maar NextLevelHardware toonde aan dat je niet verder kwam dan 70k IOps omdat de 800Mhz dan aan het nekken was.

Nu zag ik Adaptec claimen 250.000 Iops te kunnen halen, dus vroeg ik me af hoe jullie daar tegenaan keken.

Maar met 1.2Ghz op een Areca moet je denk ik flink wat IOps kunnen halen.

quote:

Femme schreef op donderdag 27 maart 2008 @ 09:49:
[...]


Het verschil in toegangstijd is bij een Mobi ongeveer een factor honderd ten opzichte van een 15.000 toeren schijf en een factor tweehonderd ten opzichte van een 7200 toeren hdd. Het verschil is dus erg fors, hoewel geheugen met een toegangstijd van 0,06ms uiteraard nog steeds traag is vergeleken met de latencies van RAM-geheugen, laat staat L1-cache op een cpu. Dit doet echter niets af aan het feit dat een ssd véél sneller te benaderen is dan een hdd. 200 keer minder traag is aanzienlijk minder traag.

Ok ik zat er een factor tien te weinig naast, maar het ging ook om de vraag of er een ander filesystem geschikter is voor een SSD. Mijn punt is dat doordat het nog steeds relatief traag gaat je geen 'speciaal' filesystem nodig hebt.

quote:

Elk modern filesystem is gericht op het verlagen van het aantal I/O requests per file 'action', zodat het systeem zo min mogelijk op het 'trage' medium hoeft te wachten.

En dat is precies mijn punt. Bij SSD kan je veel meer lees/schrijfacties per seconde hebben, waardoor ik me voor kan stellen dat de huidige bestandssystemen, die geoptimaliseerd zijn voor een laag aantal I/O's per file actie, minder geschikt zijn.
Ook bijvoorbeeld sequentie, wat bij SSD geen rol speelt, is geoptimaliseerd voor fysieke schijven. Fragmentatie speelt bij SSD eigenlijk geen rol, terwijl dit voor fysieke schijven heel anders is.

Ik post dit van mijn Thinkpad X41 gemod met een 32GB Sandisk 1.8" UATA 5000 schijf. Duidelijk de moeite waard voor laptops want de boottime lijkt wel 5x verkleind te zijn. Zeker omdat deze laptop een 4200rpm 20-25ms schijf had. wereld van verschil.

Morgen wat benchmarks, echter eerst even sandisk mailen voor een nieuwe firmware voor de SSD. Er is een nieuwere firmware welke voor betere STR waarden.


Ik was ongeduldig, vandaar de dips in de grafiek.

P5ycho wijzigde dit bericht 04-04-2008 00:49 (35%)

Ik heb Vista inmiddels draaiende om m'n workstation met een E6700 @ 3,3GHz, 4GB RAM, Areca ARC-1280, 2GB cache, 4x Mtron Mobi 3000's 10x Hitachi Travelstar 7K200 100GB. De Mobi's draaien in raid 0 en de Travelstars in raid 5.

Draait echt lekker. Photoshop voelt een stuk lichtvoetiger aan dankzij de snelle opstarttijd. Het is bijna net zo snel als een lichte app zoals Word opstarten op een harddisk. Ik deed SP1 installeren om mijn workstation en mijn laptop (dualcore 2,4GHz met Travelstar 7K200) en de laptop deed er zeker vijf keer langer over. Alles vliegt gewoon.

quote:

Ruudjah schreef op dinsdag 01 april 2008 @ 00:32:
[...]

En dat is precies mijn punt. Bij SSD kan je veel meer lees/schrijfacties per seconde hebben, waardoor ik me voor kan stellen dat de huidige bestandssystemen, die geoptimaliseerd zijn voor een laag aantal I/O's per file actie, minder geschikt zijn.
Ook bijvoorbeeld sequentie, wat bij SSD geen rol speelt, is geoptimaliseerd voor fysieke schijven. Fragmentatie speelt bij SSD eigenlijk geen rol, terwijl dit voor fysieke schijven heel anders is.

Juist doordat een harde schijf volume zo langzaam is, zijn FS dermate geoptimaliseerd om de overhead te beperken. Bij SSD wordt die overhead qua tijd lager maar niet nihil of 'super weinig' zoals sommige mensen denken, fragmentatie kan dus nog steeds een rol spelen (100 keer seeken á 0,1 ms = 10 ms wachten). Daarnaast is fragmentatie hoofdzakelijk een 'low-speed-FS' issue, juist bij FS die voor snelheid geoptimaliseerd zijn (zoals dus XFS) lig je van fragmentatie niet wakker.

Uhm, volgens mij is wisselen van cel binnen een SSD al seeken, dus of die cel nu dichtbij of verderweg is, dat maakt niet uit. Dat wisselen van cel kost altijd 0.1ms

quote:

Snow_King schreef op maandag 07 april 2008 @ 10:44:
Uhm, volgens mij is wisselen van cel binnen een SSD al seeken, dus of die cel nu dichtbij of verderweg is, dat maakt niet uit. Dat wisselen van cel kost altijd 0.1ms

You're point being? Ik zeg ook 100 x 0,1 ms, of die 0,1 nou gemiddeld is of constant.

_{You're point being -> You are point being -> Jij bent punt zijnde... Misschien your point being}
Zijn punt is volgens mij dat fragmentatie dus inderdaad niet uitmaakt. Als data wat opgevraagd word verspreid staat over verschillende cellen, maakt het niets uit of die cel nu aangrenzend is of niet. Hence, fragmentatie maakt prestatiewijs geen verschil tov geen fragmentatie.

Echter, het maakt dan wel uit of de opgevraagde data in 1 cell staat, of meerdere terwijl het in 1 cell kan. Dan heb je dus een extra (onnodige) seek te pakken. En dit soort dingen kan een filesystem nu juist optimaliseren .

Femme, ben je van plan hier nog testen mee te doen? NTFS, HFS, HFS+, ZFS, EXT2 etc. En ben je ook van plan testen te doen met fragmentatie zodat we in deze discussie praktische informatie hebben? Zou uber zijn !

quote:

Femme schreef op vrijdag 21 maart 2008 @ 12:20:
Ik heb hier nu ook een 64GB ssd van Memoright liggen. Deze wil niet wil werken op de sata-controller van de nForce Pro 2200 chipset en een Silicon Image Sil3124 met een bios van september 2007. Op de Areca ARC-1280ML werkt het wel. Ik heb nog een Intel-systeem met een ICH7R liggen waar ik hem op kan proberen.

Ik zal ook eens kijken of ik een filmpje kan maken van mijn twee testsystemen (single Opteron 248 2,2GHz met 2GB RAM) die Windows XP booten vanaf een Mobi en een Raptor.

Kan het zijn dat AHCI aan stond? MemoRight SSD ondersteunen nl. geen AHCI mode, wel compatible mode.

Hier nog een HD Tach RW benchmark van Mtron pro vs MemoRight GT door BenchmarkReviews.com

http://benchmarkreviews.c..._MR25.2-064S_SATA7025.png

en een benchmark t.o.v. een WD Raptor

http://benchmarkreviews.c...ch_MR25.2-064S_Raptor.png

quote:

Ruudjah schreef op maandag 07 april 2008 @ 21:41:
_{You're point being -> You are point being -> Jij bent punt zijnde... Misschien your point being}
Zijn punt is volgens mij dat fragmentatie dus inderdaad niet uitmaakt. Als data wat opgevraagd word verspreid staat over verschillende cellen, maakt het niets uit of die cel nu aangrenzend is of niet. Hence, fragmentatie maakt prestatiewijs geen verschil tov geen fragmentatie.

Echter, het maakt dan wel uit of de opgevraagde data in 1 cell staat, of meerdere terwijl het in 1 cell kan. Dan heb je dus een extra (onnodige) seek te pakken. En dit soort dingen kan een filesystem nu juist optimaliseren .

Klopt, het maakt niet uit hoe ver de cellen uit elkaar liggen, dus fragmentatie maakt niet uit.

Maar aangezien een MTron SLC gebruikt kan er maar 1 stuk data in 1 cell, dus gaat de andere theorie niet op?