Seagate wird wissen warum Sie 128 MB Cache verbaut haben.
Seagate hat dem Controller 128MB RAM verbaut, das ist aber nicht gleichzusetzen mit den 128GB Cache die immer beworben werden, da liegen auch Verwaltungsdaten und davon dürfte die Archive v2 wegen des On-Disk.Caches nicht wenige haben. HGST hatte in den Datenblätter früher sogar konkrete Angaben wie viele MB vom RAM wirklich als Cache genutzt wurden und es war damals schon immer deutlich weniger als 100%.
Und dieser Cache wird mit SATA3 natürlich schneller gefüllt und die Platte kann sie schneller verarbeiten.
Schaut man sich die Benchmarks von HD Tune zur Burst-Rate diverser SATA 6Gb/s Platten an, wäre ich mir da auch nicht so sicher. Der RAM Cache muss auch verwaltet werden und die Controller sind keine Rennpferde, die brauchen auch ihre Zeit um zu entscheiden, ob und wo noch Platz ist etc.
Die Platte ist nicht zwingend langsam, sie schafft 195 MB/s beim Schreiben.
Aber auch nur auf den äußeren Zylindern und wie praktisch jede HDD sind auf den inneren allenfalls halb so viel.
Ich wollte meine schon wieder zurückschicken, weil das Verhalten unkalkulierbar schien.
Das ist aber bei anderen HDDs im Prinzip nicht anders, auch dort hängen die reale Schreib. und Leseraten sehr von der Position der Daten und auch der Metadaten des Filesystems auf der Platte ab. Hier kommt noch das Über- und Zurückschreiben wegen SMR hinzu, sowie der On-Disk-Cache.
Habe den Test ja schonmal mit einer durch gehabt.
Das könnte es schon sein, wenn alleine das Filesystem nicht mehr jungfräulich ist, legt es die Metadaten wieder anders ab als bei einer frisch formatierten Platte und ob der Controller auch noch irgendwie weiß ob die Platte mal geschrieben war, wissen wir auch alle nicht.
S-ATA 2 hat theoretsich 375MB/Sek übertragungsrate wobei S-ATA 3 750Mb/Sek hat.
Ich weiß theoretische Werte,
Nein, diese Werte gibt es selbst theoretisch nicht, weil da die 8b10b Kodierung unterschlagen wird, aber wenn man von Bit auf Byte umrechnet, muss man die Bitkodierung berücksichtigen, also gibt es theoretisch, bzw. brutto ohne Overhead wie Befehle und Prüfsummen, dann 300MB/s bzw. 600MB/s, aber niemals 375MB/s oder 750MB/s. Der Overhead ist bei SATA relativ gering, mit 5% Verlusten kann man bei langen Transfers (pro Befehl können maximal 2^16 aufeinanderfolgende LBAs übertragen werden) auskommen.
aber wenn man von ausgeht das man 2/3 der Geschwindigkeit erreicht sind es noch immer 225MB/Sek bei S-ATA 2.
Das reicht für über 260MB/s.
Bei kleinen Dateien kannst du pauschal von 35,X MB/Sek ausgehen bei der Platte. Dieser Wert zeigt sich immer wieder in den Tests
Man kann also das Kopierverhalten schon vorraussagen
Geh einfach immer von den 35MB aus und du bist auf der sicheren Seite.
Auch das ist Unsinn, denn es hängt sehr von der Größe der kleinen Dateien ab und wie diese über die Platte verteilt sind, dann auch noch ob gelesen oder geschrieben wird und bei letzteren um welche Gesamtvolumen es geht, ob also die Caches (vor allem der On-Disk-Cache) dafür nicht reichen oder nicht mehr. Diese 35MB/s kann man mit Sicherheit auch noch deutlich unterbieten.
Ahja völlig vergessen, wie soll das mit den Resourcen Monitor gehen? Finde nix davon das der protokoliert und die Skalen sind so klein das man da eh nix drauß auswerten kann.
Die graphischen Anzeigen kann man vergessen, die Y-Skalen stimmen oft nicht. Schau einfach wie die momenate Werte der Instanzen von h2testw sind.
Die Unterschiede können übrigens viele Ursachen haben, bis runter zur Gerechtigkeit der Vertreilung der Bandbreite von DMI an die Controller und PCIe Lanes des Chipsatzes.
