Beim Durchstöbern einer Materialsammlung zum DMV (das mir freundlicherweise fritzeflink zukommen ließ), lese ich in einer Datei "NCR.ASC" (bzw. NCR.DOC), in der ein findiger Programmierer die Mühen und Probleme beim Erstellen einer "neuen" io.sys für den DMV erklärt, daß der DMV über eine lausige Speicherperformance verfügt. Wie er meint, kommt diese dadurch zustande, daß der Controllerbaustein (8203), zuständig für den Speicherrefresh des DRAM, ein gutes Drittel der Buszyklen für den normalen Betrieb lahmlegt, um den refresh durchzuführen.
Das hindert natürlich die CPU am schnellen Zugriff auf den Speicher.
Dazu hat er in einer Schleife 500.000 Mal den int 80h aufgerufen und die Zeit gemessen (der int 80h ist am DMV mit Dos 2.11 ein nicht servicierter Interrupt. Wird er aufgerufen, wird mit IRET sofort retournier).
Die verwendete CPU war ein V20 mit 6,66667 MHz (20MHz Taktgeber / 3).
Die Laufzeit war 12,8 Sekunden.
Nun hat er durchgerechnet (mit einer falschen Zykluszahl für den loop-Befehl):
int 80h 50c
iret 39c
loop 13c (hier hatte er 1,4c eingesetzt ???)
===========
102c (hier hatter er 90,4c)
Daraus folgerte er, daß die "effektive" Geschwindigkeit der CPU nur ca 3,5 MHz beträgt: 90,4 * 500.000 = 45.200.000 cycles / 12,8 sek =3.531.250 Hz = 3,5 MHz
Rechnet man dies korrekter, also mit 102c pro loop und addiert noch 2 x 4c hinzu, um die notwendige fetch-time für das jeweils 2. opcode Byte der beiden 2-byte Befehle int und loop miteinzubeziehen die aufgrund der Leerung der prefetch-queue durch die jmp Befehle (alle 3 befehle sind jmp-Befehle, die nolens volens die prefetch queue leeren) nachzuladen sind , so sieht dies zwar etwas besser aus, aber insgesamt ist das Ergebnis erschütternd:
(102 + 2*4) * 500.000 = 55.000.000 cycles / 12,8 sek = 4.296.875 Hz = 4,3 Mhz
Das bedeutet letztlich, daß 2,4Mhz von 6,7Mhz auf der Stelle treten, wenn, wie im Beispiel, laufend auf das RAM zugegriffen wird (es werden hier im Bsp. keine internen Registerbefehle verwendet, die unabhängig vom Geschehen auf dem Bus immer mit voller Geschwindigkeit ablaufen. loop zählt zwar einen internen Zähler herunter, aber die Hauptlast ist der Sprung zu einer RAM-Adresse um von dort die nächsten opcode-Bytes einzulesen.
Am IBM PC/XT/AT beträgt der DRAM refresh ca alle 4 ms (der timer 1 des 8253 ist dort beim Systemstart so programmiert, daß er alle 72 cycles - 15,08 ysec - dem DMA controller dazu veranlaßt, eine von 256 möglichen Adressen anzusprechen, Dauer 4 cycles).
3,86 ms = 256 x 15,08ysec
D.h. für mind. 4 von 72 cycles ist der Bus für den DRAM refresh reserviert und somit 5,5% der Speeicherbandbreite für Programme verloren. Das kann sich aber je nach laufendem Programmcode noch erhöhen auf 8,3% (6 cycles von 72).
Beim DMV ist der Timer chip 8253 lt. den Handbüchern aber nicht für die STeuerung des DRAM refreshs vorgesehen.
Woher kommt die hohe Refresh-rate beim DMV? Und wurden im DMV so schlechte DRAMS verwendet, daß es notwendig ist?
Und final, kann man die DRAMS austauschen gegen "schnellere" und wo müßte man dann den entsprechenden ticker manipulieren?
