cheetah 15k.7 450gb ST3450857SS, 3 Scheiben, 6 Köpfe (475 bis 1480)
cheetah 15k.7 600gb ST3600057SS, 4 Scheiben, 8 Köpfe (363 bis 968)
die 300GB cheetah 15k.7 Modelle haben 2 Scheiben, 4 Köpfe
die durchschnittl. Latenz aller 15k.7 cheetah modelle liegt bei 2 ms, die seek time lesend/schreibend bei 3,4/3,9 ms
die anhaltende Dauer-media rate innen/aussen bei zwischen 122 bis 204 MB/s
die sonstigen Daten der Platten sind bis auf den Stromverbrauch identisch
die ST3600057SS gibts aber zudem noch FIPS-zertifiziert, die ST3450857SS nicht
auf Anhieb kann ich keine weiteren Hardware-Unterschiede entdecken, evtl. gibt das Manual dazu noch was her
die Preisunterschiede könnten einfach ein zufälligen Marktgeschehen sein oder eine Angebot-Nachfrage-Kiste
savvios gibts auch in 15k, aber als 15K.2 nur bis 147GB, die 15K.3 gibts anscheinend nicht mehr
die savvio 10K.5 ist ebenso eine Mission Critical Disk wie die Cheetahs, ansonsten aber unauffälliger (strom, lautheit)
die Latenz liegt wie bei allen 10k bei 3 ms, und die seek time lesen/schreiben bei 3,4/3,8 ms
sustained data rate aussen/innen 168 bis 93 MB/s
ob 10k oder 15k machst du wohl an den Erfordernissen fest
die Media Raten liegen auf'm Tisch
die erwartbaren IOPS (für kurze und zufällige Zugriffsmuster, wohlgemerkt) ergeben sich wie folgt (allerdings natürlich gerechnet ohne jedwede caching-leistungen, die ja noch hinzukommen)
bei einer 10k platte dauert eine Rotation 6 ms, die durchschnittliche Latenz ist daher 3 ms (eine halbe Rotation)
angenommen die Zugriffe bestehen zur Hälfte aus lesen, zur Hälfte aus Schreiben, dann bildet man das Mittel der seek times,
bei der savvio 10k.5 sind das 3,6 ms, addiert dies zur durchschnittlichen Latenz (also 6,6 ms) und erhält so die durchschnittliche zufällige IO Latenz
da die disk auf die Daten zugreifen kann mittels nur eines host commandos, ergibt der Kehrwert der durchschnittlichen zufälligen IO Latenz die erwartbaren IOPS,
das sind also rund 151 IOPS, wie gemerkt ohne jedwedes caching, nur die pure mechanische Power des Laufwerks berücksichtigt
es ist kein Problem irgendwelche lustigen Bench-Spielchen zu machen, in denen IOPS von über 100.000 resultieren, dazu muss man den IO nur etwas sequentieller machen,
so dass die Anfragen aus irgendeinem Cache geliefert werden können