Hiernach hat das sogar nur eine ICH8, aber egal. Beide unterstützen laut Intel keine AHCI, nur die RAID Versionen können das. Praktisch geht es aber doch, wenn die Option im BIOS vorgesehen ist (nennt sich dann aber oft nicht AHCI sondern anders) und man die inf Dateien der Treiber anpasst. Tante Google spuckt Dir da sicher die passenden Tipps aus.newbieHW schrieb:
Wie schon geschrieben wurde, die lila Ports hängen an dem sehr lahmen JMicron (Gigabyte verwendet den auch unter eigenem Label) Controller. Dann besser am Intel Port im IDE Modus.newbieHW schrieb:
Mit einmal 2.6Ghz und einmal 3.6GHz erzeugst Du 8 Screenshots? Ich vermute mal, Du hat den Takt stufenweise erhöht. Dabei sieht man vor allem bei den 4k_64 lesend Werten eine stetige, wenn auch geringe Verbesserung. Das ist ja auch klar, die CPU kann die Anforderungen schneller verarbeiten, von Timer starten bis Daten rausschicken und Daten empfangen bis Timer stoppen vergeht weniger Zeit. Real dürfte SSD immer noch die gleiche Transferrate liefern, aber es ging ja auch um die Messtoleranzen.Fetter Fettsack schrieb:
Hoffen wir das für ihn, denn wenn Gigabyte sich streng an Intels Vorgaben gehalten hat, wonach die ICH8/9 (ohne R) keinen AHCI Modus unterstützt, dann gibt es diese Einstellung im BIOS nicht. newbieHW, mache ggf. ein BIOS Update, denn er keine Option für den SATA Mode des Intel Controller gibt.HDScratcher schrieb:
Für HDDs stimmt das so, denn da bringt NCQ nicht wirklich viel. Bei SSD die NCQ unterstützen bringt das aber eine Menge, schau Dir mal die AS-SSD Ergebnisse von "Fetter Fettsack" an und achte auf den Unterschied zwischen den 4k und den 4k_64 Werten. Das bringt NCQ bei einer SSD die dieses auch unterstützt. Das deine 4k_64 Werte am Intel teils besser als die 4k Werte sind, liegt an den Effekten, die auch den Unterschied in der Messreihe von "Fetter Fettsack" ausmachen: Die SSD verarbeitet im IDE Modus immer nur einen Anfrage, bei parallelen Anfragen (4k_64) entsteht aber keine Lücke dazwischen, da der Treiber die Warteschlange verwaltet. Bei Queue Depth 1 (4k) müssen die Ergebnisse immer erst bis zum Programm (AS-SSD) durchgereicht werden und das erzeugt dann eine neue Anfrage die erst zum Treiber kommen muss, was eben Wartezeiten für die SSD und damit schlechtere Ergebisse erzeugt, vor allem wenn sich noch ein Virenscanner reinhängt und die Daten erst noch prüft oder die NTFS Datenkompression aktiv ist und sie erst noch packt/entpackt.newbieHW schrieb:
Die Einschränkung ist gut, denn seid es SSDs gibt sieht man, wie grottenschlecht die Performance des JMicron SATA Host Controllers wirklich ist.newbieHW schrieb:
Richtig, auf jeden Fall zurück an den Intel Port, denn selbst im IDE Mode ist der performanter als der JMicron. Schau noch mal in BIOS und versuchen den Hack mit den inf Dateien, wenn Du ihn in den AHCI Mode bekommen willst. Kann gehen, muss aber nicht. Das ist eben Intels Politik: Alles ist auf dem Chip drauf, aber nur wer die Topmodelle kauft und dafür viel bezahlt, darf auch alles nutzen. Ist bei den CPUs ja nicht anders, oder glaubt hier jemand ein 2500k könnte nicht auch HyperThreading, wenn Intel es freigeben würde?newbieHW schrieb:
Es gibt Hinweise wonach auch der MS IDE Treiner TRIM durchlässt, dann sollte "pci_ide" oben links in AS-SSD erscheinen. Wie sich der Intel IDE Treiber, den Du ja verwendest bzgl. TRIM verhält, kann ich Dir nicht sagen.newbieHW schrieb:
Die m4 64GB im Dauerschreibtest auf xtremesystems.org hat aber schon so eine gewaltige Datenmenge (über 700TiB) überlebt, dass ich mir bzgl. der Haltbarkeit weniger Sorgen machen würde. Außerdem fürchte ich, dass der JMicron Treiber auch kein TRIM unterstützt. Mach die SSD einfach niemals ganz voll, dann hast Du auch nicht so schnell Probleme mit Performance und Lebensdauer, auch ohne TRIM.
