Rondjes draaien met de Seagate Barracuda 7200.7 NCQ

The Tech Report heeft de 160GB Seagate Barracuda 7200.7 NCQ getest. Deze Serial ATA harde schijf is uitgerust met Native Command Queing dat lees- en schrijfacties op een dusdanige manier uitvoert dat de koppen een stuk efficiënter over de harde schijf bewegen. Dit zou moeten leiden tot betere prestaties. Om dit te testen werden er een flink aantal benchmarks op de harde schijf los gelaten, waarbij de prestaties werden gemeten met en zonder NCQ.

Uit de resultaten blijkt dat de prestaties in de serverbenchmark IOMeter een leuke verbetering zien als NCQ wordt ingeschakeld. Dit gaat echter wel gepaard met een hogere belasting voor de cpu. Hetzelfde doet zich ook voor met de Western Digital Raptor met TCQ (Tagged Command Queing). Uit de rest van de benchmarks, die zich vooral richten op desktopprestaties, blijkt dat NCQ juist zorgt voor slechtere prestaties. The Tech Report vermoedt dat dit ligt aan de nog jonge implementatie van NCQ in de Seagate Barracuda 7200.7.

Een andere oorzaak van de slechtere desktopprestaties is wellicht de gebruikte controller, een Promise FastTrack TX4200. Uit testen die door Tweakers.net zijn uitgevoerd, blijkt juist dat NCQ ook op de desktop een leuke prestatieverbetering laat zien. Hierbij werd echter gebruik gemaakt van een SATALink Sil 3124-controller. Hierbij moet worden opgemerkt dat NCQ op deze controller niet kon worden uitgezet, waardoor er gebruik moest worden gemaakt van een 200GB Seagate Barracuda 7200.7 zonder NCQ als vergelijkingsmateriaal. Helaas zijn er geen testen te vinden waarin beide controllers met elkaar worden vergeleken om hier een oordeel over te kunnen vellen.

Reacties (34)

[bramseltje]

Zou het niet zo kunnen zijn dat je een (iets) hogere processorbelasting krijgt doordat de ontvangen data nu eerst in de goede volgorde gezet moet worden?
De processor zal dit natuurlijk niet direct doen, maar elk programma dat data opvraagt zal er over na moeten denken welke volgorde de blocks normaal hebben.

Of misschien is het wel door een verhoogd DMA verkeer? Doordat de blocks door de HD in een andere volgorde worden gelezen zal de controller of de HD zelf deze in het geheugen in de goede volgorde moeten zetten. Dit kan natuurlijk niet (allemaal) in de cache (2-8MB) dus zal er ook behoorlijk wat verkeer naar het geheugen plaats vinden.

Of sla ik de plank nu zo gigantisch mis dat de haartjes die erop zitten wel van een Australier kunnen zijn?

[scsirob]

Inderdaad, je slaat de plank mis. Het is niet je CPU maar de schijf zelf die de commando's optimaliseert en de data op volgorde ophaalt. Da's het hele voordeel. Overigens heeft SCSI dit voordeel al... ehhhm....15 jaar. Daar heet het Tagged Command Queue. Lekker nieuw dus.

[Countess]

Tagged command queing is toch heel iets anders?
dat word gedaan door de drivers/OS dat data in een bepaalde volgorde naar de HD sturen,
maar dat is daarom ook lang niet zo effectief als NCQ (native command queing) want de HD zelf weet veel beter hoe de HD er uit ziet en waar de koppen op dat moment staan.
TCQ kan bv niet de volgorder van de queue in de HD zelf veranderen. wat NCQ dus wel kan. komt er dus een nieuw commando ergens halverwegen nog binnen kan dat meteen in de idiale positie gezet worden wat bij TCQ niet meer kan omdat de vorige opdrachten al naar de HD zijn verzonden en die volgorde dus al vast staat.

NCQ is een nieuwe techniek, geintroduceerd bij S-ata en SAS voor zover ik heb kunnen vinden op google.

[Dreamvoid]

TCQ (NCQ is gewoon de naam die Seagate geeft aan hun implementatie van TCQ) zit ook al sinds 1997 in de ATA specificatie, maar is tot nu to niet gebruikt om precies de reden die uit het artikel blijkt: het zorgt niet voor significante snelheidsverbeteringen door de hoge overhead.

Wat dus de grote vraag is: waarom heeft TCQ bij SCSI wel voordelen en bij ATA niet? Er wordt namelijk al jaren door SCSI adepten geroepen dat TCQ de reden is dat SCSI sneller zou zijn dan ATA (en niet de snellere & duurdere lees/schrijfkoppen die in SCSI drives gezet worden).

[n4m3l355]

@ dreamvoid
de reden waarom scsi effecienter werkt dan sata is dat scsi controllers dit normaal gesproken op de controller afwerken eer het de processor bereikt. dit scheelt dus nogal wat. maar dat merk je dan ook wel in de prijs. een beetje scsi controller is zo 500 euro terwijl een sil/promise 25 a 50 euro doet. aan de andere kant als je het optimaal benut en terug rekent naar het aantal aansluitingen is het eigenlijk nog niet zo'n verschil aangezien je met 500 euro 27 apparaten kan aansluiten. voor het gemak is het dan nog maar 20 euro per device terwijl een sil/promise maar meestal 2 a 4 aansluitingen benut wat dan ook 20 euro ongeveer per device is.
verder denkelijk liggen de verschillen tussen promise/sil niet zover uit elkaar aangezien het beide software matige raid kaartjes zijn maar voor wel een leuke prijs. een bijkomt van een sil is dat deze door de 2.4 & 2.5 kernel ondersteunt worden dus het gebruik onder linux is erg makkelijk in tegenstelling tot promise.
tevens is eigenlijk heden ten dage de overhead naar mijn idee steeds minder interessant aangezien processors steeds krachtiger worden. bij een beetje ftp zul je niet snel de processor eruit trekken eerder je geheugen

[Verwijderd]

Als ik naar het plaatje kijkt, blijft de volgorde van data gewoon hetzelfde.

Het enige wat veranderd is de snelheid waarmee de koppen van track veranderd.

Vergelijk het maar met een auto op de snelweg, die meerdere banen tegelijkertijd kan wisselen.

Moet je niet op het examen flikken natuurlijk, want dan ben je gezakt, weet ik uit ervaring

Ik denk dat een harddisk zonder dit snufje maximaal maar 1 track per cycle opschuift.

[Croga]

Dan moet je toch nog maar eens een keer goed naar het plaatje kijken.....

Op het linker plaatje pakt de kop de data op volgorder (1-2-3-4) Op het tweede plaatje pakt het data stukje nummer 3 eerder dan 2 omdat de schijf daar eerder langs komt (1-3-2-4 dus).....

[Thy King]

ik wil niet al te lullig zijn.. maarre, 1-3-2-4?? Laatste keer dat ik les kreeg in tellen, was het toch echt 1-2-3-4. Dus het zal zeker eerst in een andere volgorde gezet moeten worden voordat de computer er iets mee kan.

Dit is ook 1 reden waarom je de schrijf defragmenteerd. Dit om de juiste 'blokjes' een beetje bij elkaar te gooien, zodat de lees/zoek tijd korter wordt. Naar mijn idee zal dit zeker een snelheidsverhoging geven, maar misschien ook een positieve bijdrage in de vermindering van slijtage? Zodat je schijf van als vanouds weer eens meer dan 2 jaar meekan?

Ik ben benieuwd waar dit naartoe gaat..

[Verwijderd]

Dat zegt hij toch ook niet?

mariusjr zei dat hij geen verschil zag in de volgorde van data als hij naar de plaatjes keek. Croga wees hem op het feit dat op het rechter plaatje de volgorde van data anders is (n.l. 1-3-2-4).

Overigens is defragmenteren van Windows vaak het bij elkaar zetten van 1 bestand wat gefragmenteerd is, niet het bij elkaar zetten van complete programmatuur. Je HDD is niet zo ingedeeld als je in Windows Verkenner ziet... Dus zal je seek time per file korter worden door defragmentatie, maar de seek time voor een serie files (bijv als je een programma start) zal weinig verschillen als je defragmenteerd. Daar is dit systeem voor ontworpen.

[martijnvanegdom]

Ik denk zelf, dat de data gewoon ik het geheugen wordt gezet..

Dus maakt de volgorde niet uit.. Volgens mij hoeft de NCQ niet rekening te houden met wanneer die welke data verstuurd..

Anders heb je nog geen winst:

Stel dat de normale (none-NCQ) a-b-c-d is
Stel dat de optimale route d-c-b-a is...

Dat moet de cpu wachten totdat d-c-b in de juiste volgorde gezet zijn, en pas dan word a gestuurd.
Het lijkt mij dat gelezen data direct naar het geheugen word gestuurd..

Waar de extra belasting vandaan komt is denk ik dat de cpu meer info moet geven over wat de volgende leesactie zal zijn.. Als je dat niet weet, en weet je niet wat de vorige leesactie was, dan valt er weinig te optimaliseren....

Wat ook zou kunnen is dat er gewoon 'computing-power' nodig om de meest optimale volgorde te berekenen en dat dat voorlopig nog op het bordje van de cpu komt

Misschien sla ik ook de plank mis hoor

[bartvb]

En je hebt hier precies waarom het voor desktops niet werkt Bij een desktop is 99 van de 100x maar 1 applicatie bezig met de disk, dan moet er iid erg vaag gewacht worden op alle stukjes.

Bij servers heb je een heel ander verhaal. Daar zijn meerdere applicaties of threads of gebruikers bezig met een disk die allemaal heel andere blocks van die disk nodig hebben. In die situatie willen de applicaties afzonderlijk je a-b-c-d block hebben. Als block d het eerst binnen komt kan de applicatie waarvoor die block is al verder terwijl de overige applicaties wachten op block a, b en c.

Stond laatst trouwens ook een leuk artikel over NCQ op storagereview dacht ik.

Ah, gevonden:
http://www.storagereview.com/articles/200406/20040625TCQ_1.html

[brama]

Het verschil is dat je bij NCQ (zie plaatjes) kunt besparen op het aantal rondjes dat de HDD moet draaien om alle data te lezen. Elk rondje dat je bespaart, is tijdswinst.

Ik ga er hierbij vanuit dat de HDD een buffer heeft die groot genoeg is om (in het voorbeeld) alle 4 de op te halen datablokjes meteen op de juiste plek kan zetten, en dus niet ook nog extra tijd moet spenderen om te sorteren. Dat lijkt me een heel veilige aanname

[NBK]

lm

[Verwijderd]

Ik heb een 200GB Maxtor DiamondMax 10 die heeft ook NCQ en ik merk niet veel snelheids winst. Hij is misschien iets meer bij de les maar veel verschil is er niet (of ik heb het nog niet gemerkt). Maar ik zou wel eens een vergelijking willen zien tussen Seagate, Maxtor en andere schijven met NCQ en daarbij ook de versies zonder NCQ...

[Countess]

je controler moet wel NCQ onderstuenen om het te laten werken.

verder zijn de prestatie verschillen zelden hoger als 10% en dus niet zo heel makelijk te merken.

[InsanelyHack]

Ik denk dat een defrag (en dan wel een goede) meer prestatie opleverd. Als je kunt zorgen dat de blokjes 1 - 2 - 3 - 4 mooi achter elkaar staan maakt het helemaal niks meer uit. Dus de grootste winst zit 'm in applicaties die zoveelmogelijk zaken afhandelen in één executable en niet 500 dll's nodig hebben. Als je een defrag uitvoert op basis van meest gebruikte bestanden optimalisatie zal deze techniek nauwlijks merkbaar zijn.

[Verwijderd]

Je gaat uit van een desktop applicatie. Daar kun je veel voordeel hebben van een gedefragmenteerde schijf. Dit ligt echter iets anders bij servers. Daar lost defragmenteren het probleem niet echt op aangezien bij servers meerdere programma's tegelijkertijd de disk willen benaderen.

Dus stel dat je drie programma's hebt A,B en C kunnen de requests bv zo binnenkomen
A, B, C, A, B, A, C, B enz. Tussen de requests van A zitten dus andere requests naar blocks die totaal ergens anders op de schijf staan. Dit leidt ook op een gedefragmenteerde schijf tot veel bewegingen van de koppen. NCQ kan dit optimaliseren, een defragmentatie niet.

@Han van Vilsteren

Ik kan me niet voorstellen dat een gerenomeerd merk ide disken in servers gaat plaatsen.

HP, IBM en Dell doen dit al enige tijd, ook zijn er tegenwoordig verschillende NAS en SAN oplossingen waarin SATA drives gebruikt worden. Ook van bekende merken als EMC en HP. Dus Sata heeft wel degelijk een plaats in servers. Het is natuurlijk wel zo dat de performance van een Sata schijf lager is dan die van een 15k scsi schijf, maar niet voor alle servertaken zijn supersnelle schijven noodzakelijk.

[InsanelyHack]

Idd daar heb je helemaal gelijk in. Ik heb hier zelf een systeem met windows 2003 en 2 sata disken. (AMD 64 3200+ 1MB cache) Ik gebruik dit systeem alleen maar voor te downloaden. Parretjes repareren ed. Dit systeem staat gewoon stil als er dan van meerdere processen disk access benodigd is. Ook al zou NCQ aktief zijn dan nog redden de ide disken het never nooit nie van de performance van scsi disken. De doelgroep van de nieuwe NCQ disken is toch eenmaal de desktop markt ? Ik kan me niet voorstellen dat een gerenomeerd merk ide disken in servers gaat plaatsen. Als ze dat wel doen dan zou ik het niet willen kenmerken als "servers". Tenzij ze een statische taak toebedeeld krijgen. B.v. ISA server of zo.

[mxcreep]

Ik weet niet wat jij geen gerenomeerd merk vind, Dell, HP, Supermicro, Intel, Sun gebruiken toch allemaal ook SATA disken in de 1U en 2U webserver oplossingen...
Ik gebruik zelf ook SATA oplossingen op druk bezochte servers (400.000 bezoekers en meer op single PIV) en heb geen last van stilstaan van systemen...
Nou kan ik er niet goed over oordelen hoe windows dergelijke taken afhandeld aangezien ik gewoon geen 1 windows server host, maar linux systemen, zeker met een goede hardwarematige RAID oplossingen gaan er toch behoorlijk stevig tegenaan met SATA disks...kan nou niet zeggen dat de SCSI systemen die ik heb draaien merkbaar sneller zijn.
Ik kan dus niet anders concluderen dat jou probleem toch een andere oorzaak heeft dan puur die SATA disks...

[mxcreep]

En je gaat per definitie ook uit van windows...terwijl juist op servergebied *nix erg veel voorkomt...
Ik wil deze diskjes met hun 10% winst wel graag hebben in mijn webservers, scheelt toch als het erg druk wordt in iowait

[Verwijderd]

leuk dat het efficienter is... maar de duurzaamheid? ik heb namelijk nogal het idee dat de oudere manier voor minder belasting zorgt voor de HDD...

[Verwijderd]

Zoals op de plaatjes te zien is leest de hardware meer data in hetzelfde aantal rondjes dat de schijf draait. Dus qua betrouwbaarheid maakt het niets uit.

[Roland684]

Maar je vergeet even de route die de kop (dwz, de arm) af moet leggen. Die is wel degelijk een stuk grilliger geworden.

[Verwijderd]

Dat maakt niet uit, hij leest de data nu met 1 rondje draaien, en anders met 3 rondjes (bv.) het enige wat misschien zou kunnen gebeuren is dat je na een tijd speling krijt omdat je die kop zo heen en weer stuurt, maar daar staat dus tegenover dat de schijf zelf minder hoeft te draaien om dezelfde data te versturen.

[_JGC_]

Mja, ik heb een keer een 286 met een oude RLL disk met glazen bovenkant zien defragmenteren onder DOS 6.2. Ooit gezien hoe die kop tekeer gaat? Steeds van binnen naar buiten bewegen, hier wat ophalen, daar wat neerpleuren...

Die kop gaat echt niet korter mee met NCQ/TCQ, eerder langer als je het goed implementeert: niet alleen het aantal rondjes wat een disk moet draaien kan geoptimaliseerd worden, maar ook het aantal keren dat je kop van binnen naar buiten beweegt is te optimaliseren.

Neem als voorbeeld de Windows 98 defragmentatietool: ding haalt van het eind van de disk 20 sectoren op, schrijft het aan het begin weg, gaat weer naar eind om weer 20 sectoren te halen, etc etc.
Je kop staat de hele tijd van het begin naar het eind te raggen. Nou bekijken we dat eens met NCQ/TCQ:
defrag geeft opdracht om 10 sectoren in te lezen, vervolgens het aan het eind neer te dumpen en vervolgens hetzelfde verhaaltje nog 10x te doen. Met een goede implementatie zou dit geoptimaliseerd kunnen worden met eerst 10x die reads en vervolgens 10x die writes. Windows merkt het niet, want die staat vrolijk op de grote 8MB of 16MB cache van die disk te werken.

[Cristan]

Hmm. De 7200.8 NCQ is alweer een tijdje uit. Het zou misschien handig zijn, als ze die ook meevergeleken. Misschien is daar de NCQ wat meer volwassen.

[Verwijderd]

ziet er wel leuk uit geen idee of dit overal goed gaat werken, stel je bent een spel aan het spelen, zou het dan ook maar alleen de informatie gaan zoeken die nodig is zonder alles door te scannen...

[jcvw]

Ik vraag me af in hoeverre dit interfereert met zaken in het OS:
1) de verschillende queueing systemen in een OS (zoals CFQ (completely fair queueing), AS (anticipatory scheduling en de deadline scheduler in Linux. Er zijn nogal wat performance verschillen in zowel totale throughput en maximale/gemiddelde latency (zie http://lwn.net/Articles/114770/ over "Which is the fairest I/O scheduler of them all?" ).
2) in verband met het behoud van consistentie op disk zal het OS er perse voor kiezen om bepaalde blokken eerst weg te schrijven, en dan pas andere. Als het andersom gaat, gaat de hele strategie van het OS de mist in. VB: Soft meta updates van FreeBSD - zie http://www.usenix.org/publications/library/proceedings/usenix2000/gene ral/seltzer.html)

Heeft iemand een idee hoe NCQ/TCQ met deze twee OS zaken interfereert?

edit: tiepvautje verbetert

[MRic3]

Ik heb dus sinds 1 dag deze schijf. Ik wist van NCQ en wat het deed dus eigenlijk deze schijf gekocht zonder verdere testen te zoeken. Mijn main point was ook dat ik een stille HD die native sata was en dat NCQ zou mooi prestatie winst geven...

Hier een mooi verkoop praatje bij seagte over NCQ.

Verder had ik de 2 drives (met en zonder NCQ) bij storage review langs elkaar gezet. Jammer genoeg staan alleen resulaten op SR geen test beschrijving. Uit die head to head komt volgens mij vrij duidelijk naar voren dat het meer een server HD is.

Verder lijkt mij het ook dat NCQ meer winst geeft naar mate je grotere files hebt, maar wat zijn grote/kleine files??? een txt'tje van 7 KB, een word doc van 70 KB, een MP3'tje van 7 MB of een iso van 700 MB ???

[Skyline GT-R]

Een andere oorzaak van de slechtere desktopprestaties is wellicht de gebruikte controller, een Promise FastTrack TX4200. Uit testen die door Tweakers.net zijn uitgevoerd, blijkt juist dat NCQ ook op de desktop een leuke prestatieverbetering laat zien. Hierbij werd echter gebruik gemaakt van een SATALink Sil 3124-controller. Hierbij moet worden opgemerkt dat NCQ op deze controller niet kon worden uitgezet, waardoor er gebruik moest worden gemaakt van een 200GB Seagate Barracuda 7200.7 zonder NCQ als vergelijkingsmateriaal. Helaas zijn er geen testen te vinden waarin beide controllers met elkaar worden vergeleken om hier een oordeel over te kunnen vellen.

Hoe zit het eigenlijk met de NCQ controller die intel in hun ICH6 heeft zitten. Het is pas sinds de introductie hiervan dat ik weet kreeg van NCQ, maar wat de zijn de prestaties daarvan

[mxcreep]

Volgens mij is de ICH6 een oplossing die vooral op software leunt en niet volledig hardware matig is (heb zelf een aantal supermicro servers met de ICH5R), op dat type controllers merk je ook dat de cpu belasting omhoog gaat...
Om die reden heb ik er ook voor gekozen om in mijn servers losse raid controllers te gebruiken, in het geval van 2 kanaals gebruik ik 3Ware en in het geval van 4 of meer gebruik ik LSI...daarmee merk je die hogere cpu belasting gewoon niet aangezien de controller alles afhandelt.