Prestatiewinst TCQ en NCQ onderzocht

Storage Review heeft een artikel gepost waarin de effecten van ATA Tagged Command Queuing op de prestaties van de Western Digital Raptor WD740GD worden onderzocht. TCQ is een technologie die de volgorde van uit te voeren I/O operaties optimaliseert zodat de koppen van de harde schijf zo kort mogelijke afstanden kunnen afleggen. De technologie is al sinds 1998 onderdeel van de ATA-standaard maar werd tot dusver nauwelijks op harde schijven toegepast. Controllers met ondersteuning voor TCQ waren al helemaal dun gezaaid. Mede dankzij de lancering van de Raptor WD740GD en de hype die Western Digital rond TCQ heeft gecreeërd, zijn er nu diverse fabrikanten die Serial ATA-controllers met TCQ-ondersteuning kunnen leveren. Voorbeelden zijn HighPoint met de RocketRAID 1820A, Pacific Digital met de Talon ZL4-150, Promise met de binnenkort te verschijnen FastTrak TX4200 en Silicon Image met zijn nieuwe Sil 3124 PCI-X controller. Storage Review gebruikte voor zijn tests de Promise FastTrak TX4200. Tweakers.net is inmiddels in het bezit van kaarten van HighPoint, Pacific Digital en Silicon Image, en heeft op de laatste twee al benchmarks kunnen draaien.

Bij veel gebruikers waren de verwachtingen over de prestatievoordelen van TCQ hoog gespannen. Western Digital noemde de ondersteuning van command queuing als één van de belangrijkste features die de weg naar acceptatie van de Raptor in de servermarkt zou moeten openleggen. De gevolgen van TCQ op de prestaties zijn zeker opmerkelijk te noemen. Helaas is van prestatieverbetering echter zelden sprake. Zowel in de desktop benchmarks van Storage Review als onze eigen desktopbenches moet de Raptor WD740 door gebruikmaking van TCQ zeker 20 procent prestaties inleveren. De enige benchmark waarin TCQ wel redelijk scoort zijn de IOMeter serversimulaties, die worden uitgevoerd bij oplopende queue-groottes. Tussen een queue-diepte van 8 en 16 I/O's begint TCQ een prestatievoordeel te ontwikkelen dat uiteindelijk oploopt tot zo'n 25 procent. Omdat de Raptor met TCQ bij kleinere queues slechter presteert is de gemiddelde winst echter minimaal. In onze serverbenchmarks, die zijn gebaseerd op traces van diverse server scenario's op een Windows Server 2003-systeem, zijn de Pacific Digital Talon ZL4-150 en de Silicon Image Sil 3124 in geen enkele test sneller dan de Talon ZL4-150 en de Promise FastTrak S150 TX2plus zonder TCQ. We kunnen stellen dat Western Digital de eigenaars van een Raptor WD740GD heeft blij gemaakt met een dode mus. TCQ is nutteloos, in ieder geval wat betreft de implementatie in de Raptor WD740GD.

	Gemiddelde prestaties in Tweakers.net Business Winstone tests (IOps)
	Pacific Digital Talon ZL4-150		No TCQ		476
	Promise FastTrak S150 TX2plus		No TCQ		471
	Silicon Image Sil 3124		TCQ		384
	Pacific Digital Talon ZL4-150		TCQ		371

	Gemiddelde prestaties in Tweakers.net servertests (IOps)
	Pacific Digital Talon ZL4-150		No TCQ		511
	Promise FastTrak S150 TX2plus		No TCQ		497
	Pacific Digital Talon ZL4-150		TCQ		461
	Silicon Image Sil 3124		TCQ		343

Gelukkig wil dit niet zeggen dat command queuing per definitie resulteert in slechtere real world prestaties. De theorie achter command queuing is goed en dus moet het mogelijk zijn om in de praktijk positieve resultaten neer te zetten. De nieuwe Serial ATA II-standaard biedt ondersteuning voor het superieure Native Command Queuing. NCQ is beter geïntegreerd in de hardware en biedt geavanceerde mogelijkheden zoals first party DMA, waarmee de harde schijven op eigen initiatief een DMA transfer kan opzetten om de resultaten van een I/O operatie naar het geheugen te schrijven. De overhead van command queuing wordt daardoor veel kleiner.

De nieuwe Intel 915 en 925 chipsets zijn de eersten die ondersteuning bieden voor NCQ. De feature wordt onder andere ook ondersteund door de Silicon Image Sil 3124, de Promise FastTrak TX4200 en de SATA II-controllers van Marvell. In de i915G en i925X review van Tech Report vinden we interessante IOMeter benchmarks van de Maxtor MaXLine III. Deze schijf is samen met de Seagate Barracuda 7200.8 en de nieuwste versie van de Barracuda 7200.7 de eerste met ondersteuning voor NCQ. In tegenstelling tot TCQ op de Raptor WD740GD levert de MaXLine III geen slechtere prestaties bij lage queue levels. De performance neemt meteen toe vanaf een queue-diepte van twee uitstaande I/O's en ligt al bij 4 uitstaande I/O's op een verbetering van circa 30 procent. Dit betekent dat NCQ ook in de desktoptoepassingen, die kleinere queues hebben dan multi-user servertoepassingen, ten goede kan komen aan de prestaties. Uit de traces van onze desktopbenchmarks blijkt dat gemiddelde queues van 3 tot 8 I/O's mogelijk zijn in desktopsituaties.

NCQ-prestaties in de IOMeter database simulatie van Tech Report

Bewijs voor de goede real world prestaties van Native Command Queuing vinden we in de Maxtor MaXLine III review van AnandTech. Ondanks zijn lagere toerental van 7200rpm weet de MaXLine III in ongeveer éénderde van de tests beter te presteren dan de Raptor WD740GD. NCQ leverde in de Business Winstone 2004 en de Multimedia Content Creation Winstone 2004 traces van AnandTech een prestatieverbetering op van respectievelijk 5,44 procent en 13,0 procent. De Content Creation trace heeft een aanzienlijke hogere belasting dan de Business Winstone trace, zoals je kunt zien in de statistieken van onze eigen BSW2004 en MCCW2004 traces. Daardoor zijn er betere mogelijkheden voor command queuing om de prestaties te verhogen.

	Gemiddelde prestaties in AnandTech Business Winstone tests (IOps)
	Maxtor MaXLine III 250GB		NCQ		622
	Western Digital Raptor WD740GD 73GB				610
	Maxtor MaXLine III 250GB		No NCQ		575

In de Benchmark Database van Tweakers.net kun je in de komende weken meer testresultaten van harde schijven en controllers met ondersteuning voor TCQ of NCQ verwachten.

Reacties (28)

[_Thanatos_]

Ik dacht dat de Raptor juist wél NCQ had, maar dat het tot op heden nog in geen enkele controller geimplementeerd was

[Femme]

De Raptor WD740GD heeft TCQ en geen NCQ. Het is niet eens mogelijk omdat de Raptor geen native Serial ATA schijf is (er zit een Marvell PATA naar SATA bridge op).

[_Thanatos_]

Dat luidt de grote vraag natuurlijk wanneer iemand een 10krpm native SATA schijf met NCQ gaat maken. Want die zou dan qua prestaties weer ruim boven de Barracuda 7200.8 uit moeten komen.

[Verwijderd]

Kan d'r helaas weinig soep van koken van dit alles. Leuk al die benchmarks maar in hoeverre zou 'n fileserver hier nou van profiteren? Of 'n database server bijvoorbeeld? Laatste lijkt me niet echt 'n performance winst krijgen met zo'n harddisk tenzij het tijdens het opstarten is. Als het goed is staat alles toch in het geheugen van de machine in kwestie.
Webservers daarentegen ljikt me wel een goeie performance winst krijgen van zoiets. Als je even alle andere bottlenecks d'r tussenuit denkt.

Wie laat hier eens z'n licht op schijnen?

[Femme]

Ik ga hier niet alle resultaten van de individuele servertests noemen want dan worden mensen gek. Onder deze link heb je een vergelijking van de controllers met ergens onderaan de pagina een aantal server scenario's. In alle tests worden de hoogste scores bepaald zonder TCQ.

Webservers hebben over het algemeen geen zware disk I/O. De meeste I/O komt van het schrijven naar logfiles wat grotendeels sequentieel is. De hitrate van de file cache zal zeer hoog zijn, tenzij je enorme hoeveelheden data vanaf één doos serveert. Bij grote databases zal dit anders zijn. Als de data niet meer in het geheugen past en de spreiding van opgevraagde gegeven is groot, dan zal er erg veel disk I/O uitgevoerd worden. Past het wel (grotendeels) in geheugen, dan zal er inderdaad weinig disk I/O uitgevoerd worden, tenzij er erg veel mutaties plaatsvinden.

Dit is voor het TCQ verhaal niet zo relevant van TCQ presteert gewoon niet. NCQ zal in de servertoepassingen zeker goed kunnen presteren. Onder zware omstandigheden zit je al snel op queue levels van 10 tot 40 uitstaande I/O's.

[Verwijderd]

Databases met alles in het geheugen???????
Geheugen is bij 32 bits beperkt tot 4 Gb, laten we positief zijn en ervan uitgaan dat er een Opteron met 8 Gb gebruikt wordt.

Een beetje DB is al snel 50-100 GB groot.
Dit past dus niet in het geheugen. Vandaar dat harde schijf perfomance erg belangrijk is voor een database.
Tuurlijk, bij een wat groter bedrijf kun je meer geheugen in je machine stoppen maar dan heb je waarschijnlijk ook een DB van een paar TB

[mjtdevries]

Er zijn in de praktijk juist heel veel databases die erg klein zijn.

Toen ik bij onze database admin aankwam met een database van 10GB keek ie me zeer verschrikt aan.
Hij had een hele lading databases van honderden MBs, ipv tientallen GB.

Maar dat neemt niet weg dat database servers zo ongeveer de enige servers zijn weer harddisks snel een bottleneck vormen.

Fileservers, webservers, mailservers etc hebben i.h.a. anders bottlenecks.

[SirBlade]

Command Queueing zal niet direct leiden tot acceptatie van ATA-hd's in de servermarkt. Het zal hoogstens een argument zijn om er eens mee te gaan testen.

Ik zou persoonlijk heel erg huiverig zijn om systemen zoals file-, mail-,en db-servers uit te rusten met een nieuw opslag-systeem. Misschien op een test-server, of een relatief onbelangrijk systeem zoals een intranet-server of systemen waar de data niet belangrijk is en die je redelijk snel opnieuw kan installeren zoals een firewall/IDS/DNS/DHCP-server. Maar het risico lopen dat er iets mis gaat met dat CQ-ing en dat daarom de administratie-database langzamerhand corrupt is geraakt en dat we daarom de back van vorige maand moeten terugzetten is IMHO het prijsverschil met een SCSI-(RAID-)controller en schijven niet waard.

[Verwijderd]

Ik zou persoonlijk heel erg huiverig zijn om systemen zoals file-, mail-,en db-servers uit te rusten met een nieuw opslag-systeem. Misschien op een test-server, of een relatief onbelangrijk systeem zoals een intranet-server of systemen waar de data niet belangrijk is en die je redelijk snel opnieuw kan installeren zoals een firewall/IDS/DNS/DHCP-server.

Ten eerste mag je er vanuit gaan dat NCQ en TCQ tot in den treure zijn getest voordat ze de wereld in werden gestuurd. En ten tweede zal een groot bedrijf óf zijn hardware incrementeel (eerst de niet essentiële systemen) vervangen, óf eerst een uitgebreide testopstelling maken die hun infrastructuur zo goed mogelijk nabootst.

Daarbij is het natuurlijk zo dat je niet bang hoeft te zijn voor dataverlies, daarvoor heb je immers backups. Dataverlies zou dan alleen nog kunnen als NCQ/TCQ corrupte data wegschrijft, maar dat is 1; makkelijk te controleren en 2; valt direct op.

Ik moet zeggen dat ik nog steeds geen spectaculaire verbeteringen zie in het (S)ATA protocol, en in opslag media in het algemeen. Volgens mij word het toch echt tijd voor een nieuw medium, of een doorbraak op het gebied van opslag... (Misschien is dit wat?)

[majic]

NCQ achtige technieken zitten al jaren in SCSI - je hebt dus zonder dat je het wist jarenlang met een techniek gewerkt die je nu zelf als riscant beschrijft. Hiep hiep hoera...

Gelukkig kunnen we daardoor deze in en in geteste techniek nu risicoloos toepassen in SATA schijven!

Bedankt voor het spelen van proef-konijn

[Verwijderd]

NCQ achtige technieken zitten al jaren in SCSI - je hebt dus zonder dat je het wist jarenlang met een techniek gewerkt die je nu zelf als riscant beschrijft. Hiep hiep hoera...

Gelukkig kunnen we daardoor deze in en in geteste techniek nu risicoloos toepassen in SATA schijven!

Bedankt voor het spelen van proef-konijn

Het idee achter de technieken is hetzelfde, maar er zijn toch echt wel verschillen.

Laat ik het zo zeggen: als bedrijf zijnde heb je al jaren een cd-brander als backup medium. En nu stap je over op een dvd-brander omdat het principe toch hetzelfde is...

[mjtdevries]

Vertel dan eens welke verschillen jij ziet waardoor je NCQ bij SCSI geen risico vind en bij SATA wel.

Zeggen dat er verschil in zit en het daarom een risico vinden is een beetje makkelijk.

[Verwijderd]

indien je de prestaties wilt meten van een dergelijk systeem zal je vooralsnog moeten begrijpen waar de winst van het systeem ligt. Tot heden heb ik nog weinig reacties gezien die getuigen van inzicht. Het feit dat een benchmark slecht scoort kan ook getuigen dat de benchmark prestaties probeert te meten met als basis een bepaalde(andere of verkeerde) inzicht. Dit kan tevens betekenen dat een bechmark totaal de plank misslaat. Ook heb ik het gevoel dat een aantal reacties op dit artikel totaal er naast zitten omdat ze gestoeld zijn op een bepaalde (geacepteerde) manier van denken. Vooruitgang is over het algemeen gestoeld op een andere manier van denken wat dit systeem naar mijn idee ook laat zien. Standaard benchmarks vergelijken is in dit geval niet de juiste (zeker geen wetenschappelijk verantwoorde) methode om een goede vergelijking te maken met andere schema's.

Hoe het wel moet: ik zou dit een juiste vraag vinden hoe dan wel? Welnu een meer wetenschappelijke methode gebaseerd op juist onderzoek (niet hol gelul!!!!) zou hier meer van toepassing zijn. Helaas heb ik heden geen tijd om daar een artikel over te schrijven en laat dit over aan andere meer gedreven bezoekers van tweakers.net.

Met vriendelijke groeten,
Bozo.

[Hielko]

Standaard benchmarks vergelijken is in dit geval niet de juiste (zeker geen wetenschappelijk verantwoorde) methode om een goede vergelijking te maken met andere schema's.

Blablabla... voordat je dergelijke reacties gaat schrijven is het wellicht verstandig om zelf wat inzicht te krijgen in de werking van de gebruikte benchmarks. Deze zijn gewoon redelijk realistische simulaties van een server/desktop omgeving. Gezien het feit dat TCQ/NCQ is ontworpen om deze toegangspatronen te acceleren zijn de benchmarks 100% valide.

[Wim-Bart]

Waarom zijn de doorvoer prestaties van een Benchmark altijd 2 tot 3 keer beter dan in een echte omgeving.

Een simpel voorbeeld is een kopie maken van de ene naar de andere disk. Disk A geeft voor lezen de waarde A1, disk B voor schrijven B1. Je gebruikt twee losse controllers en toch liggen de uiteindelijke prestaties meer dan twee keer lager dan de traagste (B1). Natuurlijk speelt de gedeelde systeembus mee, maar in de praktijk blijkt dat een zogenaamde tragere combinatie de zelfde prestaties te bieden als een snelle combinatie.

Benchmarks zijn een moment opname van geconditioneerde omgevingen. Niet representatief voor een life omgeving. Zodra er andere onderdelen bij komen zoals netwerkkaart, processor, os etc. etc. zijn de benchmarks totaal niet meer representatief.

Daarnaast is human experience niet uit te drukken in getallen. Het is een experience, niets meer en niets minder.

WB

[Verwijderd]

Ik ga er van uit dat de benchmarks valide zijn, echter vraag ik mij af of de conclusie dat TCQ niet goed werkt ook valide is. Bij intensieve server toepassingen heb je al gauw een lange queue lengte en levert TCQ een duidelijke prestatiewinst. De vraag is meer waar ligt het omslagpunt en wannéér is het interessant. Teksten als

We kunnen stellen dat Western Digital de eigenaars van een Raptor WD740GD heeft blij gemaakt met een dode mus. TCQ is nutteloos, in ieder geval wat betreft de implementatie in de Raptor WD740GD.

zijn dan ook onterecht. TCQ is nuttig in bepaalde situaties. Misschien in een (zeer) beperkt aantal situaties maar als je net in zo'n situatie zit is het wel handig te weten dat TCQ wat extra performance geeft.
Duidelijk is wel dat NCQ zoals verwacht beter werkt dan TCQ, echter als ik de twee (waarschijnlijk onvergelijkbare) grafieken vergelijk zie ik toch een flink verschil in het voordeel van de WD, met of zonder TCQ.

Mijn conclusie is dan ook simpel. De snelste IDE schijf voor je servertje is nog steeds de WD en TCQ aanzetten lijkt mij ook, op een server, aan te raden.

Dus zelfde benchmark maar toch een totaal andere conclusie, raar he?

[Femme]

Mijn conclusie is dan ook simpel. De snelste IDE schijf voor je servertje is nog steeds de WD en TCQ aanzetten lijkt mij ook, op een server, aan te raden.

Ik maak die opmerking niet omdat er geen bewijs voor is. In de servertests van Tweakers.net blijkt TCQ nergens sneller te zijn, ook niet in de tests met een grote queue zoals de MySQL Import benchmark met gemiddeld 42,6 uitstaande I/O's of de MySQL recovery benchmark met een wachtrij van gemiddeld 34,7 I/O's. Hooguit zijn de verschillen tussen TCQ en geen TCQ erg klein. In situaties met relatief kleine queues en veel sequentiële I/O verliest TCQ zoveel performance dat de uiteindelijke afgewogen prestaties er alleen maar op achteruit gaan.

[Femme]

Sorry hoor, maar volgens mij ben je nu echt in het luchtledige aan het lullen. Die benchmarks van AnandTech, Storage Review en Tweakers.net zijn allemaal gebaseerd op situaties die zich in de werkelijke wereld kunnen voordoen. AnandTech gebruikt voornamelijk applicatie benchmarks en game level loadtijden om de prestaties te meten. Storage Review en Tweakers.net gebruiken traces van disk I/O op Windows systemen in bepaalde scenario's. Dit zijn omstandigheden waarin alle facetten van het storage subsysteem aan bod komen - bussnelheid, cachestrategieën, media transfer rates en ook command queuing. Dit heeft allemaal niets met 'vooruitstrevend denken' te maken maar gewoon met het gebruik van verantwoorde testmethoden die werkelijke situaties nabootsen.

indien je de prestaties wilt meten van een dergelijk systeem zal je vooralsnog moeten begrijpen waar de winst van het systeem ligt.

Dat is duidelijk: command queuing verbetert de prestaties door de volgorde van uit te voeren I/O's te optimaliseren zodat de schijfkoppen een zo kort mogelijk afstand kunnen afleggen. Het werkt alleen als er meerdere I/O's in de wachtrij staan, anders valt er niks te optimaliseren.

Wil je werking hiervan aantonen, dan is IOMeter een goede (synthetische) benchmark omdat je daarmee tests kunt uitvoeren bij uitlopende groottes van de queue/wachtrij.

Het feit dat een benchmark slecht scoort kan ook getuigen dat de benchmark prestaties probeert te meten met als basis een bepaalde(andere of verkeerde) inzicht.

Zoals gezegd proberen AnandTech, SR en ook Tweakers.net prestaties te meten in releastische situaties die zich kunnen voordoen tijdens desktop, game- en servergebruik. Dat zijn niet per definitie de omstandigheden waarin command queuing optimaal presteert maar het is wel realistisch.

Welnu een meer wetenschappelijke methode gebaseerd op juist onderzoek (niet hol gelul!!!!)

Het is geen hol gelul. In de desktopbenchmarks van Tweakers.net, die bestaan uit meer dan 20 subtests in allerlei omstandigheden en waarin zo'n half miljoen I/O's worden uitgevoerd, is TCQ welgeteld nul keer sneller dan een adapter zonder TCQ. Je kunt daar wel aardig conclusies uit trekken.

[JSK]

Deze resultaten doen de Raptor WD470GD voor het eerst niet echt goed uit de bus komen. Ik neem aan (en hoop) dat de opvolger van de Raptor (Q3 of Q4 dit jaar) wel ondersteuning van NCQ zal hebben, en ook een betere implementatie van TCQ.

[PD2JK]

Dan zal WD dus helemaal een nieuw ontwerp moeten maken, omdat het geen Native S-ATA schijf is.

Wat Femme dus al heeft aangegeven bovenaan.

[CARman]

Alleen een nieuwe interface zal hier toch wel volstaan. Ook WD zit niet stil en zal ongetwijfeld in de nabije toekomst met een native SATA schijf komen.

De hardware in de schijf ( platters, aandrijving en koppen ) zullen hiervoor vast niet compleet opnieuw ontworpen te worden, dus met een native SATA ben je al halverwege een goede oplossing. En als TCQ beter geinplementeerd wordt en minder overhead met zich mee brengt zal de algehele performance hiervan ook wel verbeteren. Ook hier zullen meerdere wegen naar Rome leiden

[mjtdevries]

Wellicht is TCQ gewoon niet veel te verbeteren en is dat dan ook de reden dat het al lange tijd in de specificatie zat maar nooit gebruikt is.

[voodooless]

Tja, Command Queuing op SCSI is nog altijd een stapje voor op ATA. SATA II zal hier echter verandering in gaan brengen (en compatible met SA-SCSI).

Verder vind ik dat ze met deze test eerder verschillende controllers geteste hebben, dan het verschil tussen TCQ en geen TCQ...Dat sommige controller toevallig TCQ hebben en andere niet, is dan een leuke bijzaak..

[Femme]

Als een Pacific Digital Talon ZL4-150 met TCQ disabled veel beter presteert dan met TCQ enabled en een Silicon Image Sil 3124 met een Raptor WD360GD gewoon normale prestaties levert maar met een WD740GD opeens een stuk trager is dan de adapters zonder TCQ, lijkt het mij wel duidelijk dat TCQ de overtragende factor is.

[Mars Warrior]

Uit de review van Anandtech wordt regelmatig aangegeven dat het niet NCQ, maar de 16MB buffer is die de drive, zeker in vergelijking met de Raptor, zo snel maakt.

Als deze vergroting van de cache dan zoveel blijkt uit te maken, waarom wordt de cache dan niet meteen tot 64MB of nog meer vergroot??

[TGEN]

Ja, prijs is niet echt een argument, de chips die gebruikt worden hoeven toch geen hoge snelheden te behalen. Ruimte is echter wel een probleem, en marketing. Als je een schijf met 64MB cache uitbrengt voor een schappelijke prijs (het extra geheugen kost immers geen drol), druk je niet alleen de verkopen van de achterlopende concurrenten, maar ook die van je eigen schijven, tenzij je alle series in een keer upgraded. Als je geleidelijk meer cache blijft toevoegen al naar gelang de prestaties van de schijf (wat moet een 7.2k schijf met 64MB cache bijvoorbeeld?), blijf je een constante afzet behouden.

[4VAlien]

Het is goedkoper om RAM toe te voegen aan je systeem... En daarin kan je behalve cache ook extra programma's en dergelijke in zetten. Een stuk nuttiger dus.

[cc bcc]

De theorie achter command queuing is goed en dus moet het mogelijk zijn om in de praktijk positieve resultaten neer te zetten.

De vraag is of het nuttig is om extra complexiteit toe te voegen aan een design wat eigenlijk aan het einde van zn leven is. Harddisks zijn goed in het opslaan van veel data, maar de snelheid/latency is om te huilen, en een paar truken om dit marginaal omhoog te krijgen lijken me de kosten niet waard. Mij lijkt het een beter idee om een extra leeskop toe te voegen, aan de overzijde de 1ste. Zo kan je theoretisch de snelheid verdubbelen en de latency halveren (zelfde effect als van 10krpm naar 20krpm te gaan)