Maxtor start levering 300GB SATA-schijven met 16MB cache

Maxtor heeft via een persbericht laten weten dat de uitlevering van de nieuwe harde schijven met de naam Maxtor DiamondMax 10 begonnen is. Dat betekent dat in eerste instantie de OEM's en andere grote partners voorzien zullen worden van een voorraad. Het gaat om SATA-schijven met native command queuing en een 16MB buffer. Sunil Kumar, Intels directeur van de chipset- en softwaremarketingafdeling was opgetogen over de nieuwe producten van Maxtor. Hij was blij dat men door samenwerking de native command queuing-technologie naar het desktopsegment kon brengen. "When our new Intel 915G/P or the 925X Express chipsets with Intel Matrix Storage Technology are combined with NCQ-enabled drives like Maxtor's DiamondMax 10, users experience faster boot times, file transfers and game level loads," zo sprak hij.

Huidige harde schijven krijgen verzoeken om data in de volgorde waarin de pc erom vraagt, waardoor de koppen voor schrijf- en leesbewerkingen over de platter vliegen om alle verspreide gegevens bij elkaar te zoeken. De NCQ-technologie zorgt ervoor dat de schijf efficiënter om kan gaan met deze verschillende commando's, door ervoor te zorgen dat de kop zo min mogelijk afstand af hoeft te leggen om zijn opdrachten uit te voeren. De grootste capaciteit waarin de nieuwe serie SATA-drives momenteel verkrijgbaar is, is 300GB. De levering van de DiamondMax 10 parallel ATA-133 schijven staat gepland voor het einde van het derde kwartaal van dit jaar. Van de nu beschikbare SATA-versies zijn alleen de modellen met een capaciteit van meer dan 250GB voorzien van een 16MB buffer.

Reacties (72)

[maxdek2121]

Dit staat op een franse site:

Garantie 3 ans, cette gamme est proposée dans les magasins aux meilleurs prix suivants :

- Maxtor DiamondMax 10 - 300Go Serial ATA - au prix de 272,54 euros
- Maxtor DiamondMax 10 - 250Go Serial ATA - au prix de 242,40 euros
- Maxtor DiamondMax 10 - 300Go IDE - au prix de 278,94 euros
- Maxtor DiamondMax 10 - 250Go IDE - au prix de 225,34 euros

A l'instar des versions SATA, notez que les versions IDE de la gamme MaXLine III, également dotée de 16 Mo de mémoire cache, sont désormais commercialisées aux meilleurs prix suivants :

- Maxtor MaXLine III 250Go IDE - au prix de 237,53 euros
- Maxtor MaXLine III 300Go IDE - au prix de 291,12 euros

[bennovb]

Benchies op gamepc http://www.gamepc.com/labs/view_content.asp?id=diamondmax10&page=1
Maxtor DM10 vs. WD Raptor is verrassend.
'k Denk dat het persbericht wel klopt, gecombineerd met Intel Matrix RAID technologie zijn hier leuke configuraties te maken.
RAID0 en! RAID1 gecombineerd op 2! schijven.
En 4 van deze Maxtors in een SB81P http://eu.shuttle.com/sb81p.htm#sb81p van Shuttle maakt toch een leuke HTPC/Media Opslagserver.

[Verwijderd]

Ik ben wel ontzettend nieuwschierig op welke wijze mensen nu een backup maken van zoveel GB's. CD's, DVD's en tapes (toch?) vallen al af. Dat is toch praktisch onmogelijk Of je moet een 2de schijf ernaast plaatsen als mirror.

[paella]

Leuk als 1 schijf kapot gaat, maar een brandje lost je probleem dan nog niet op natuurlijk...

[sn0x0r]

Paella heeft genoeg geld om een persoonlijke glasvezel verbinding aan te leggen naar een hutje in de middle of nowhere waar hij z'n data naar backupped

[Verwijderd]

Een tape backup helpt ook niet bij een brand als je tapes in hetzelfde pand liggen. (tenzij je een kluis hebt die tegen het vuur kan natuurlijk )

[hardwareaddict]

Harde schijf is per GB erg goedkoop.

Dat zegt iets over hoe andere media totaal achterlopen.

[Verwijderd]

2e HD als mirror beschermt je tegen hardware-failure (maar niet als dat door blikseminslag komt, of door een brand), maar als er softwarematig dataverlies optreedt (per ongeluk de verkeerde directory deleten, een brakke uninstaller die voor het gemak maar de hele C-schijf leegmaakt, virussen...) dan wordt dat dataverlies gewoon vrolijk meegemirrord.

Nee, dan moet je toch echt met een externe backup aan de gang. Harde schijven in een bracket hangen, bijvoorbeeld, of een verplaatsbare harde schijf. Voor een eurootje of 50 koop je een mooi Firewire of USB-2 kastje waarin je een harddisk naar keuze hangt. Daar kun je wel een Ghost image van je primaire harddisk op kwijt, lijkt me.

[Verwijderd]

een vriend van me en ik "mirrorren" onze data, we hebben elk 4x200GB

[JF_]

Nutteloos - als je controller 't begeeft ben je alles kwijt. Of als de energiemaatschappij eventjes teveel spanning op de lijn zet. Of als je gewoon even niet oplet en de verkeerde partitie wist.
ONLINE MIRROR IS GEEN BACKUP!

[Verwijderd]

Uhm volgens mij bedoeld hij dat niet. Hij kopieert zijn data naar de schijven van die vriend en die vriend kopieert dan weer de data naar hem toe. Als er dan een raid adapter uitvalt heb je altijd nog de data op de schijven van de ander.

Veilig dus

[Titusvh]

Als het vriendje waarmee wordt 'gemirrort' niet al te dichtbij woont valt dat wel mee. Lijkt me alleen niet praktisch om vele gigs over iets anders dan een LAN te mirrorren...

[lvh]

Je kan mirroren (RAID level 1 OF gewoon twee identieke drives met identieke data) of een backup kopieren.

Makkelijkste als je niet met RAID will gaan knoeien is je harde schijf (aangenomen dat ze identiek zijn) aansluiten op de PC, Knoppix of een andere Linux Live-CD starten (aangenomen dat je niet Linux als normaal OS gebruikt zoals ik), en intikken:

dd if=/dev/sda of=/dev/sdb

Aangenomen dat /dev/sda de source en /dev/sdb de destination drive is.

Dan heb je een 100% kopie en image. Als je, in tegenstelling tot veel andere "image" tools, een 20GB HD met 10GB aan data image't, krijg je een image van 20GB, niet 10. (tenzij je erin slaagt het ding 50% te comprimeren natuurlijk ;-))

[Countess]

hoeveel van dit soort data is nou echt onvervangbaar?
ik weet niet hoe het met andere mensen zit (voor privee gebruik wel te verstaan) maar op de mijn documenten map en wat andere mappen met persoonlijk werk na kan ik alles wel weer van internet downloaden, ik hoef echt niet al mijn 2x120GB's ergens te backupen. aan 1 cd heb ik meer als genoeg, en ik denk dat ik niet de enige ben.

[sl1200]

Goed opgemerkt
Ik gebruik op 1 van mijn PC's nog steeds een 20GB hdd en een 4GB hdd als back-up, terwijl ik per maand gemiddeld 50GB aan films en muziek via internet binnenhaal. Ik kijk ernaar en delete het, en de goede muzieknummers brand ik op een CDtje. Voor de rest: office-files, fotos, configurateiinstellingen en dat soort bestanden maak ik een back-up op die 4GB hdd.

Geef de mens nu een 10TB hdd en hij zal hem al over paar maanden te klein vinden. Met een grotere hdd heeft men gewoonweg de neiging om meer "troep" op zijn hdd te laten staan. Een soort digitale hamstering zou je kunnen zeggen.
Het is net als met je kastruimte thuis. Koop na 10 jaar een nieuwe kast en je hebt hem binnen no time vol. Met minder GBs ben je genoodzaakt om efficienter met je hdd-opslag om te gaan en behoud je naar mijn inziens ook een betere overzicht van je bestandsindeling.

[Verwijderd]

Zelf gebruik ik een NAS met 1TB geheigen als Disk to Disk Backup. Dus dit soort schijven worden bij mij niet gebackuped maar zijn zelf de backup Van deze D2D Backup wordt dan eens in de zoveel tijd weer een tape backup gemaakt die in een ander pand wordt opgeslagen.

[Verwijderd]

Waaorm zou je, als je toch al 300 GB vol sleurt met meuk, dat backuppen? Ik backup alleen m'n zinvolle gegevens, bedrijfsdata en gegevens voro de belasting, verzekeringen, een popfestival wat ik organiseer en zo nog wat spul. Die andere 350 GB schijfruimte wordt bevolkt door m'n mp3 collectie (die ik mirror naar een mapje vol DVD+Rs, nu 18 stuks) en wat films, spellen, een kleinigheidje voor de xbox hier en daar, en zo nog wat prut die als ik het kwijt aak gewoon opnieuw gedownload wordt mocht ik het weer willen hebben. De meeste spellen en films heb je toch origineel op DVD en CD_ROM ook, dus je bent alleen je savegames kwijt...

[Verwijderd]

Ik zou eerst wel eens benchmarks willen zien....

Toen S-ata eerst uitkwam ging het ook "prachtig" zijn, spijtig genoeg was er niet veel verschil met IDE....

[the_stickie]

S-ata is op zich sneller en stabieler dan ATA. Ook kunnen we langere kabels gebruiken, met minder storingen.
Het is idd zo dat de performancewinst van s-ata tov ata zeer klein is/was. Ook al omdat ata (133) op dat ogenblik helemaal niet de grote bottleneck was, maar de snelheid van de drives.
Daarbovenop komt nog het feit dat de eerste volledig native s-ata harde schijven nog niet eens zo lang beschikbaar zijn, waardoor performance evrloren ging in de adapters.
s-ata is gewoon een door ontwikkeling noodzakelijk om verdere generaties van (snellere) schijven betrouwbaar ana de pc te kunnen koppelen.
al zijn er natuurlijk wat features toegevoegd; oa command queing, wat nu pas door de eerste schijven (zie boven) ondersteund wordt, die de performance van de schijf zlf verbeteren, waardoor de transferrates wel duidelijk zullen stijgen

[berend_engelbrecht]

Het snellere heb ik nooit erg gemerkt met de huidige generatie (non-native) SATA schijven, volgens mij blijkt ook uit de benchmarks dat dit erg tegenvalt (Femme heeft hier misschien nog wel wat zinnigs over op te merken).

Stabieler en niet te vergeten gemakkelijker in te bouwen vind ik wel duidelijke voordelen van SATA. Met UDMA had ik constant last van corrupte data, dat is helemaal over nu ik alleen nog SATA schijven in m'n PC heb.

[Nelissuh]

Ik heb zelf nooit last van corrupte data als gevolg van PATA schijven. Wel heeft mijn raidkaartje gezeurd dat een kabel niet oké was en dat hij daarom van UDMA5 (ATA133) terug schakelde naar UDMA3 (ATA66). Het vervangen van de kabel loste dat op.

Als jij je corrupte data voorkomt door alleen maar SATA apparaten te plaatsen neem ik aan dat je ook SATA DVD-rom, brander enz hebt?

[Olaf van der Spek]

Met UDMA had ik constant last van corrupte data, dat is helemaal over nu ik alleen nog SATA schijven in m'n PC heb.

Wat voor schijven heeft de halve wereld de laatste tien jaar dan gebruikt als PATA data corruptie oplevert?

[CARman]

Alleen de interface is theoretisch sneller ........

Je schijf wordt echt niet sneller van SATA. Pas als je er genoeg in RAID-0 ( striping ) gebruikt, kun je de oude ATA133 vol trekken, daar waar er met SATA nog een theoretisch 17MB/s meer bandbreedte voor handen is.


Sja, van het verschil in stabiliteit hoor ik hier voor het eerst eerlijk gezegd. Dus enige onderbouwing en/of een link naar een betrouwbaar bericht hierover is altijd welkom.

[Countess]

S-ata is op zich sneller en stabieler dan ATA. Ook kunnen we langere kabels gebruiken, met minder storingen.

eigenlijk was het in de eerste plaats geloof ik om het goedkoper te maken
en dat is best aardig goed gelukt.
ipv van de 40 "draden" die nu over het moederboard moeten zijn het er met sata maar 6 ofzo (of 8?), de stekkers op het moederboard nemen een HOOP minder ruimte in beslag (en zijn goedkoeper) de kabels zijn dunnen (en goedkoper) de controler chips kunnen kleiner zijn (minder aansluitingen... en dus goedkoper... uiteindelijk) ect.

echt sneller wilden ze het pas met s-ata2 gaan maken.
in een s-ata2 schijf of controler MOET ook NCQ aanwezig zijn bij s-ata1 is het optioneel.

[Nelissuh]

Hoeze hebben ze het over schijven met een 16MB buffer waarmee snelheden vergelijkbaar met parallelle 7200rpm schijven kunnen worden gehaald ??

Wil dat zeggen dat deze schijven met lagere snelheid draaien?? 5400 rpm o.i.d.??

[JSK]

Nee, volgens het persbericht:

the new DiamondMax 10 drives feature native command queuing (NCQ), the company's proprietary dual-processor technology, and a new 16MB buffer to deliver unparalleled speeds compared to traditional 7200 RPM drives in their class.

In het nieuwsbericht is 'unparalleled" (ongeevenaard) gewoon slecht vertaald.

Het gaat hier dus gewoon om 7200rpm schijven.

[jcvw]

Huidige harde schijven krijgen verzoeken om data in de volgorde waarin de pc erom vraagt, waardoor de koppen voor schrijf- en leesbewerkingen over de platter vliegen om alle verspreide gegevens bij elkaar te zoeken. De NCQ-technologie zorgt ervoor dat de schijf efficiënter om kan gaan met deze verschillende commando's, door ervoor te zorgen dat de kop zo min mogelijk afstand af hoeft te leggen.

Sorry, maar ik vraag me af of dat bij een goede implementatie van een filesysteem driver in het OS nodig/wenselijk is. Een operating system weet precies wanneer waarom welk blok naar disk toe gaat. Als het goed is, zit er ook een goede I/O scheduler in de kernel van het OS (denk bijvoorbeeld aan de anticipatory disk scheduler van Linux. die levert een fikse verbetering op ten opzichte van de oude elevator scheduler).

Doet het OS zo hard zijn best, gaat de disk zich ermee bemoeien! Vergeet ook niet dat sommige OS-en (denk bijvoorbeeld aan FreeBSD met zijn soft meta updates) juist in een heel specifieke volgorde de blokken naar disk sturen, om ervoor te zorgen dat mocht er een stroomstoring/crash optreden tussen twee bij elkaar horende opdrachten, er geen inconsistenties in het filesysteem intstaan. Ook daar wil je niet dat de disk door reshuffelen van opdrachten roet in het eten gooit...

[ijdod]

Ik denk dat het toch wenselijk is, gezien het al jaren een feature is van SCSI.

[Countess]

dat is allemaal sotware matig.
hardware matig zou voor een nog groter verbetering moeten zorgen. zeker als er een groter wachtrij in de HD zich heeft opgehoopt, zou NCQ een uitkomst zijn.
als het al naar de hd is verstuurd kan de I/O schedualer niks meer, en stel er komt dan ineens weer een opdracht bij, uit een ander programa bv, die moet die achteraan aansluiten
maar als je NCQ hebt kan hij (als dat zo mooi uit komt) alsnog even wat naar voren worden gezet, met als resultaat dat de gemiddelde wacht tijd omlaag gaat. dus minder lange queue's en hogere gemiddelde doorvoor snelheid.

[hardwareaddict]

Toch zijn dit soort technieken heel erg handig.

[Red Griffin]

Zo ver ik weet zijn de daadwerkelijke fysieke gegevens onbekend aan het OS van de computer, dus zijn er beperkingen aan de optimalisaties die daar gedaan kunnen worden.
De rest van de optimalisering moet gebeuren via het OS van de drive zelf die nu daarvoor command queuing ondersteund.

[Verwijderd]

En hoe zit het met Linux kernel 2.6?

Die heeft software matig command queing
Kun je echt merken, stukken minder lawaai als onder
windows 2000 (als ik die gebruik, af en toe ;-) ) en
is vooral stukken sneller met veel verschillende read /writes
(in tegenstelling tot zonder, dan rattelen & traaaaag)

Heft het dan elkaar op? of verdubbeld?
of vertraagd / tegenwerken?

[Countess]

de HD krijgt altijd het laatste woord natuurlijk. hij beheerd uiteindelijk ook de wachtrij in de HD zelf.
als 2.6 ze al op een vrij effeciente manier in de HD zet zal de NCQ van de HD minder te doen hebben. het uiteindelijker resultaat zal denk ik iets beter zijn als met windows of met een oudere kernel, omdat het OS wat verder vooruit kan kijken waardoor hij nog efficienter naar de HD kan versturen, terwijl de HD de puntjes op de i zet en de wachtrij voor zichzelf optimalizeert.

[Verwijderd]

Je OS kan niet weten wat het kortste pad is om de gevraagde data in te lezen. Dan zou je OS moeten weten op welke sector een block precies staat, hoeveel platters er zijn, de indeling van de platters enz enz.
Ook krijgt het OS bij multitasking meerdere opdrachten tegelijkertijd van verschillende programma's die gescheduled moeten worden. Tot slot is er natuurlijk een verschil tussen lezen (kan het OS niet beschadigen) en schrijven (in potentie gevaarlijk voor het OS). Maar uiteindelijk zul je bij schrijfacties altijd iets moeten overschrijven en als je meerdere schrijfacties achter elkaar moet doen ben je altijd kwetsbaar als halverwege de stroom uitvalt. Er bestaat tenslotte niet zoiets als Database transacties voor harddisken.

Conclusie is dat NCQ in potentie efficienter is dan het OS ooit kan worden. Daarnaast dacht ik dat de "anticipatory disk scheduler" van Linux gewoon wat extra blocks in las om zo meerdere readacties te combineren. Bij een NCQ schijf wordt dit automatisch gedaan maar dan enkel voor blocks die ook daadwerkelijk nodig zijn en niet voor blocks die "misschien" nodig kunnen zijn. Ofwel de "anticipatory disk scheduler" zal de zaak alleen maar vertragen met een NCQ schijf.

[BounceMeister]

Als ik het goed begrijp heb je hier alleen iets aan met de i915 of i925 chipset. Een i865 of i875 met geïntegreerde ICHR5 SATA controller maken geen gebruik van 'native command queuing'?

De schijf op zich is dus niet sneller, alleen de 16MB cache en de NCQ bieden dus de snelheidswinst?
Dan zou ik nog even wachten op een WD Raptor 10krpm schijf met deze interface en 16MB cahce.

[p0p0]

tsja, dat is natuurlijk, als je van WD houd, bij mij houden die dingen t nooit langer dan n paar jaar uit, terwijl mn Maxtor het stukken langer volhoud
en die i915 of i925 chipset, tsja, logisch op zich, ze kunnen niet alles backwards compatible maken, want dan zou je nooit n nieuw moederbord hoeven kopen enzo, dan wordt er te weinig verdiend
en waarschijnlijk kun je hem anders wel gebruiken
net zoiets als de oude mobo's en hdd's boven de 137GB, die gwoon niet verder kwamen

[nAFutro]

Dan ben jij een uitzondering op de cijfers maarja,
ff een antwoord op de vraag van BounceMeister, NCQ zit inderdaad niet in de ICH5, dus je hebt er ook geen voordeel van. Natuurlijk is het wel weer zo dat elke generatie harde schijven sneller en sneller is, extra cache helpt dan natuurlijk nog meer.

[erikdeperik]

en hoe zit het dan met de amd chipsets?\
maken die gebruik van ncq

[Verwijderd]

he, he gaan we weer.
This dat jij van maxtor houd, want die gaan meestal niet langer dan 1 jaar mee, terwijl mijn oudste WD hier al 14 jaar is.

Laten we proberen de discussies zuiver te houden en niet weer verzanden in welles/nietes mbt de levensduur van schijven.

Jij vind maxtor top en anderen (waaronder ikzelf) vinden WD top, maar dat is volgens mij niet relevant in deze discussie.

[The CarNagE Man]

Klinkt allemaal mooi. Ben alleen wel benieuwd hoeveel verschil is met de wat oudere schijven.
Ook hoop ik dat de prijs een beetje redelijk is zodat een normaal mens het ook kan kopen.

Dus kom op Tweakers Crew maak ff een benchmark van die schijf! Ben zeer benieuwd!

[Gregoor]

Het gaat om SATA-schijven met het zogenaamde 'native command queuing' en een 16MB buffer waarmee snelheden vergelijkbaar met parallelle 7200rpm schijven kunnen worden gehaald.

Dit klinkt een beetje vreemd natuurlijk. Maxtor gaat van 7200 rpm parallelle ATA naar 7200 rpm SATA, en de schijven kunnen misschien even snel zijn. Het is dan ook verkeerd vertaald vanuit het Maxtor marketing praatje, waarin staat dat deze nieuwe schijven "unparallelled speeds" halen ten opzichte van PATA schijven. Ofwel een stuk hogere snelheden.

[Superdeboer]

Dat klopt... ik was even misleid door dat stukje tekst. Het is inmiddels gefixt.

[Verwijderd]

En hoe zit het met S-ata2?

Die schijven van 300mb/sec? Is dat die Maxline3? Gingen normaal met kerstmis uitkomen...

[lvh]

300 MB/sec sequential read is heus nog niet mogelijk de eerste paar jaar :-)

Timed cache reads is wat anders natuurlijk, met een beetje RAID array raak ik volgens hdparm -tT al aan 1.2 GB/s!

[JF_]

1.2GB/s? * 786562 JF_ Timing buffer-cache reads: 3432 MB in 2.00 seconds = 1714.55 MB/sec
Timing buffered disk reads: 146 MB in 3.00 seconds = 48.64 MB/sec

Gewoon een single 120G WD-sata schijfje op een Intel-onboard controller. Buffer-cache reads hebben dus duidelijk geen flikker te maken met de daadwerkelijke schijf(-array), maar vooral met CPU, L1/2/3-cache en geheugensnelheid (dit is dus een 3.4GHz Prescott, 1Mb L2, dualchannel PC3200).

[lvh]

Nummertjes gooien is leuk. Alleen spijtig dat je ze niet vergelijkt:

root@quux /home/laurens # hdparm -Tt /dev/md0

/dev/md0:
Timing buffer-cache reads: 1392 MB in 2.00 seconds = 695.76 MB/sec
Timing buffered disk reads: 286 MB in 3.01 seconds = 95.06 MB/sec
root@quux /home/laurens # hdparm -Tt /dev/hda

/dev/hda:
Timing buffer-cache reads: 1276 MB in 2.01 seconds = 635.87 MB/sec
Timing buffered disk reads: 140 MB in 3.02 seconds = 46.32 MB/sec

(Zelfde model hard disk)

60MB/sec is misschien niet veel, maar wel meer dan "het heeft geen flikker ermee te maken".

[Verwijderd]

Het verschil tussen de 695 en 635 kan natuurlijk gewoon door de variantie komen. Dus om te zeggen dat 695 significant anders is dan 635 vind ik aan de hand van dit ene voorbeeld nogal gewaagd.

Zelfde geldt in principe natuurlijk ook voor de 95 en 46 MB/sec maar daar is het verschil nogal groot dus kan ik wel geloven dat er een verschil is tussen de twee diskcontrollers. Echter: Het gaat over de buffer cache reads en het verschil daarvan is bij een 5% betrouwbaarheidsinterval niet significant. En om die 5% te mogen gebruiken zul je nog flink wat testen moeten doen.

Dus conclusie. Statistisch is jou test geen bewijs dat er een verschil in performance bestaat.