Re: Ist der SATAII Standard zu SATA abwärtskompatibel?

Am Tue, 3 Jan 2006 23:49:40 +0100 schrieb Martin Schoenbeck:

>>> Aber nach meiner
>>> Erinnerung konnten auch die Controller vor ATA bereits mehrere Sektoren
>>> nacheinander lesen. Gepuffert wurde, zumindest aus Protokollsicht, nur ein
>>> Sektor, danach mußte erstmal abgeholt werden. Der Controller _konnte_ also
>>> ohne Probleme auch mehrere Sektoren puffern, der Host mußte nicht wissen,
>>> wieviele das sind. Der IRQ kam in jedem Fall pro Sektor.
[...]
> Und ansonsten lief das Ganze eben nicht mit einem Read-Ahead Cache, sondern
> mit Sektor-Skewing. Die Platte wurde so formatiert, daß der Host genügend
> Zeit hatte, nach dem Lesen des ersten Sektors diesen abzuholen bevor der
> nächste eingelesen wurde. Schaffte der Host das nicht, dauerte es eine
> Plattenumdrehung bis zur nächsten Chance. Weil der Controller nicht
> pufferte. Aber _gekonnt_ hätte er es vom Interface her.

Das verstehe ich überhaupt nicht. Das Konzept des Interleaving ist mir
bekannt, nur verstehe ich nicht, wie es dadurch _möglich_ ist, Sektoren
spekulativ zu lesen - dass es sinnvoll erscheint steht außer Frage.

Ich denke, das Interleaving kann man erst dadurch nutzen, dass entweder
tatsächlich mehrere Sektoren bereits vom Host angefordert werden, oder
dass die Lücken so großzügig bemessen sind, dass die Übertragung der
Sektoren vom Sektorpuffer in den Haupt-RAM auch noch stattfinden kann,
bevor der nächste Sektor kommt. Allerdings habe ich mich nie mit dem
Timing von Interleaving beschäftigt und weiß daher überhaupt nichts
darüber.

>> Allerdings muss ich dazu sagen, dass ich mit 28,5 Jahren das meiste
>> davon nur aus Geschichtsbüchern kenne. ;-)
>
> Ich weiß gar nicht mehr auswendig, wann der PC-AT rauskam. Aber da gingst
> Du wohl noch auf die Grundschule. Wenn überhaupt.

Muss ja nichts bedeuten. Der erste PC, an dem ich saß (war latürnich
nicht meiner, hatten meine Eltern auf meinen persönlichen Wunsch
angeschafft), war kein AT, den gab es damals IIRC noch nicht. Das war
dann erst der zweite Rechner. Zu dieser Zeit wiederum gab es schon 386,
die waren aber quasi unbezahlbar, und von 386SX hielt mein Vater nichts
(O-Ton: "Ein 386SX ist ein 286er, der so tut, als wäre er ein 386er").

Zu den XT-Zeiten habe ich mich aber zugegebenermaßen noch wenig mit den
Internas beschäftigt.

>> Aber genau dies halte ich für höchst relevant für die Diskussion. Denn
>> auch ein UDMA-Host tut nichts anderes als der DMA-Kontroller von damals,
>> schon aus Gründen der allseits geliebten Abwärtskompatibilität haben
>> sich die beiden Enden der IDE Schnittstelle unabhängig voneinander
>> weiterentwickelt. Wenn also der UDMA Host heute damit rechnen muss, dass
>> er noch nicht verifizierte Daten in einer beliebig niedrigen
>> Geschwindigkeit bekommt, dann muss das auch schon das alte System
>> gekonnt haben, bis zurück zum PIO nach IRQ - es sei denn, man hätte den
>> Befehlssatz entsprechend erweitert, was mir vollkommen neu wäre.
>
> Das verstehe ich jetzt nicht. Im PIO-Mode bekommt der Host gesagt, wann der
> Sektor fertig ist. Danach holt er ihn sich ab. Danach gibt es vom Protokoll
> her keine Möglichkeit, dem Host mitzuteilen, daß das, was er abgeholt hat,
> Bockmist ist. Also _muß_ hier der Sektor zunächst gepuffert werden.

So weit, so klar.

> Im
> DMA-Mode wird dem Host aber erst mitgeteilt, daß der Sektor da ist, wenn er
> eingelesen _und_ übertragen wurde.

Also, die andere Seite der IDE-Schnittstelle (von mir aus der
Host-Adapter) verhält sich im DMA-Mode recht ähnlich wie die CPU im
PIO-Mode, nur das Timing ist anders. Der DMA-Kontroller (bzw.
Hostadapter) hat also auch das selbe Problem, wie die CPU: Er will genau
eine Übertragung von der IDE-Schnittstelle in den RAM überbrücken, von
deren Länge und Anfangsadresse im RAM er übrigens von der CPU informiert
wurde. Und eben dieser kleine Chip muss im DMA-Mode sehr wohl wissen,
wenn die erste Übertragung ein Fehlschlag ist, um sie zu wiederholen
(Adress- und Längenzähler zurück auf Anfang, keinen IRQ an die CPU, und
noch mal probieren).
Daher sehe ich keinen Unterschied zwischen PIO und DMA bei diesem
Problem - nur die involvierte Komponente heißt anders.

> [...] Nur darf der Host
> sich nicht darauf verlassen, daß der Puffer unverändert ist, wenn er eine
> Fehlermeldung bekommt. _Das_ muß ordentlicherweise in der
> Protokolldefinition stehen, wenn man das erlauben will. Ad hoc gefunden
> habe ich es aber nicht. Kann aber auch am Suchbegriff liegen.

Stopp! Die Protokollspezifikation beschäftigt sich mit der Schnittstelle
zwischen einer Festplatte und einem Hostadapter. Ob hinter dem
Hostadapter irgendwo so etwas wie RAM ist, interessiert dabei nicht -
von Basisadressen, Größen und Inhalten mal ganz zu schweigen. Von der
Schnittstellenbeschreibung her könnte man auch die Daten gleich nach
/dev/null schicken - die HDD bekommt davon nichts mit.

>>>> Bei SATA kenne ich mich nicht so gut aus, aber AFAIK ist das Protokoll
>>>> auf höherer Ebene (Befehlssatz) identisch, nur der Transport ist anders.
>>>
>>> Die entscheidende Frage wäre eben, ob das Protokoll verbietet, in den
>>> Bereich, den der Host angibt, zu schreiben, bevor sicher ist, daß der
>>> Auftrag fehlerfrei erledigt werden kann.

Nachdem wir den Begriff Host geklärt haben:
Die Festplatte schreibt nicht in den RAM, das tut der Hostadapter. Die
Festplatte weiß nicht, ob so etwas wie RAM überhaupt existiert. Der RAM
hängt "günstigenfalls" am Systembus, da kommt die HDD nicht direkt dran
- zumindest nicht an die Adressleitungen.

>> Das verstehe ich nicht, insbesondere deine Verwendung des Begriffs
>> "Host".
>> Für mich ist der Host erstmal die Brücke zwischen IDE und Systembus.
>
> Das ist der Hostadapter. Der Host ist der PC.

OK, wir haben ganz klar ein Begriffsproblem. Ich hoffe, diesmal
eindeutiger geschrieben zu haben.
Die HDD gehört nicht mit zum PC (= Host)?
Ich habe mal gelesen, ein Unterschied zwischen IDE und SCSI wäre, dass
bei ersterem auch der Hostadapter(!) mit auf der HDD ist - allerdings
hat sich jene Dokumentation auf eine genaue Definition der Begriffe
nicht festgelegt. Ich möchte so eine Begriffswelt hier nicht
propagieren, sondern nur darlegen, dass das nicht so eindeutig ist.

>> Ich fürchte, ich springe zu viel hin und her zwischen Althergebrachtem
>> (PIO, etc.) und modernem (UDMA, SATA).
>
> Vergiß mal den PIO-Mode. Da geht alles schon sinnig. Deshalb hat man ja die
> DMA-Modi eingeführt, um auch noch die letzte Mikrosekunde rauszukitzeln.

Ich gehe davon aus, dass DMA und PIO Mode nicht vollkommen anders
funktionieren (UDMA hingegen ist wirklich anders), es ging in erster
Linie darum, die CPU zu entlasten und somit die primitive Aufgabe des
Kopierens einem anderen Gerät zu überlassen. Erst im zweiten Schritt
zeigt sich, dass ein solches spezialisiertes Gerät das dann auch noch
schneller kann, als eine CPU, die zwischendurch auch noch Opcode lesen
und dekodieren muss, zwischendurch einen Sprung für die Schleife braucht
(OK, es gibt REP INS) und so weiter. (Und im dritten Schritt kann man
mit UDMA dann alles noch viel besser machen, insbesondere die Hardware
so festlegen, dass das Timing enger gemacht werden kann.)

>> Die Sache mit dem möglichen CRC Fehler ist ein weiteres Problem.
>
> Eigentlich nicht. Sondern das, worüber wir die ganze Zeit reden.

Mein erstes Argument war das Timing, dass sicher erstmal nur für PIO
gilt. Das CRC Problem fiel mir erst später ein.

> Alle
> anderen Probleme weiß der Controller schon, bevor er anfangen könnte, Daten
> zu übertragen.

Uh, stopp! Was ist jetzt wieder der Controller genau? AFAIK liegt der
auf der HDD (zumindest sein IDE, bei SCSI sowieso) und kann Motoren für
Lesearme steuern (controllieren).

>> Der Host ist das Bindeglied der Übertragung zwischen IDE Gerät und RAM
>> oder CPU. Er muss wissen, was an ihn übertragen wird und was er damit
>> anstellen soll.
>
> Der Hostadapter. Und der muß nur wissen, wo das Zeug hin soll. Ob das Müll
> ist oder nutzbare Daten, geht ihn nichts an, sondern nur den Host selbst.

Wenns Müll war, darf er nicht Interrupten und muss nochmal ran.

>>>> Selbst wenn das Problem nicht wäre, es würde die Sache um einiges
>>>> komplizierter machen.
>>>
>>> Es ist kein Problem und es macht nichts komplizierter.
>>
>> Ich dachte dabei daran, aus dem Sektorpuffer, in den zuerst geschrieben
>> und aus dem später wieder ausgelesen werden kann, einen für
>> gleichzeitigen Zugriff konzipierten FIFO zu machen.
>
> Stell Dir das nicht komplizierter vor, als den gleichzeitigen Zugriff auf
> den Hauptspeicher z.B. durch eine USB-Host-Controller oder eben einen AHCI
> und den Prozessor.

Zunächst einmal: Durch meinen Beruf (ASIC-Design) denke ich recht gut
abschätzen zu können, wie kompliziert das heute wäre. Wenn ich hingegen
auf dem Gang vorbei gehe und Bilder von Dies sehe, deren Strukturen man
womöglich noch mit einer Lupe aus dem Yps-Heft erkennen kann, bin ich
mir nicht sicher, wie das Damals[tm] war, als man mit 60k Gatter bei 8
MHz schon viel machen konnte. Und da gabe es noch keinen
USB-Host-Controller. Und da wollte man in der Tat nicht zu vielen
Geräten Zugriff auf den Bus geben, nur die CPU und der DMA-Kontroller
durften (später konnte man dann letzteren im Busmaster-Mode
missbrauchen, um die Einschränkungen zu umgehen).

> Es werden einfach nur zwei verschiedene Speicheradressen
> verwaltet. Damit keine noch nicht gelesenen Daten übertragen werden, muß
> man das natürlich synchronisieren. Das ist aber relativ primitiv über einen
> Zähler möglich.

Genau das nennt man einen FIFO. Und der ist komplizierter als ein
einfacher Sektorpuffer. Aus heutiger Sicht lächerlich, damals sah das
sicher anders aus.


Sebastian
.

Relevant Pages