Autor Thema: Sektoren lesen dauert so lange  (Gelesen 8552 mal)

Cheebi

  • Beiträge: 91
    • Profil anzeigen
    • Cheebis Webseite
Gespeichert
« am: 20. June 2007, 23:18 »
Hi leute,

ich habe meinen Disketten-Treiber umgeschrieben in Assembler (vorher C) weil ich dachte, ich könnte dadurch die Performance verbessern. Nun muss ich feststellen, dass auch in Assembler zu lange gebraucht wird, einen Sektor zu laden. Woran kann das liegen?
Mein Loader (Stage 2) lädt die Kerneldatei, die immerhin 49KB groß is, innheralb von vielleicht 4 Sekunden. Im Loader (16Bit-Code) benutze ich den BIOS-Int, der Sektoren liest (also keine Tracks!); meine eigengeshriebene Routine für das Lesen von Sektoren ist aber zu langsam (49KB -> 33 Sec). Woran liegt das? Wie genau lädt das BIOS die Sektoren? Wie lange brauchen eure Disketten-Treiber 98 Sektoren zu lesen?

Danke,

Cheebi
0100 1001 0100 1100 0100 0001 0010 0000 0011 1010 0010 1101 0010 1010
http://www.cheebi.de

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 21. June 2007, 10:44 »
Gratuliere zur Erkenntnis, daß Assembler keinen wesentlichen Unterschied in der Geschwindigkeit macht - oder wenn, dann in die falsche Richtung. ;)
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Korona

  • Beiträge: 94
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 21. June 2007, 10:56 »
Wie ließt du denn die Sektoren? DMA, direkter Portzugriff? Direkte Portzugriffe sind schneller als der DMA allerdings werden dadurch sehr viele IRQs aufgerufen (für jedes Byte iirc), was die Performance von Multitasking Systemen schlecht beeinflusst. (In heutigen Systemen mit 3+ ghz wird das aber wsl. fast keinen Unterschied machen)

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #3 am: 21. June 2007, 11:21 »
@taljeth: Den Geschwindigkeitsvorteil beim Lesen von Sektoren merkt man da natürlich nicht. Ein gut geschriebenes ASM Programm ist aber schneller als eines in einer Hochsprache. Nur sind die Geschwindigkeitsvorteile so gering, das man es erst bei recht großen Programmen merkt (die dann jedoch oft sehr kompliziert werden und man ASM nicht mehr verwenden möchte). Was meinst du mit falscher Richtung?

@Korona: Bist du dir sicher das direkte Portzugriffe schneller als DMA sind? Bei Festplatten und CD/DVD Laufwerke ist das andersherum.

@Cheebi: Dir wünsche ich noch viel spaß mit dem FDC. ^^

bitmaster
In the Future everyone will need OS-64!!!

stultus

  • Beiträge: 486
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 21. June 2007, 15:29 »
@bitmaster: Floppys mit CD/DVD vergleichen ist glaub ich ne Schlechte idee, da liegen sowieso Welten zwischen (allein vonner Laufwerksgeschwindigkeit und Datenmenge her).

Zum Thema, es wär evtl. gut zu wissen worauf das so lang dauert, und wie du aktuell drauf zugreifst (also Ports, oder DMA, ... - am besten immer mit Code). "Hilfe es ist langsam woran liegts?" geht auch hier nicht. Oder hat jemand meine Kristallkugel gesehn? ^^
MSN: planetconquestdm@hotmail.de
ICQ: 190-084-185

... Wayne?

Korona

  • Beiträge: 94
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 21. June 2007, 17:56 »
ATA/ATAPI benutzt nicht den 8237 DMA Chip wie der FDC sondern andere Chips. (Ultra DMA etc.)

Cheebi

  • Beiträge: 91
    • Profil anzeigen
    • Cheebis Webseite
Gespeichert
« Antwort #6 am: 22. June 2007, 00:08 »
@korona: ich habe den DMA-Kanal gewählt, da ich mir dachte, das sei schneller als direkt über die Ports...

Wenn direkte Portzugriffe schneller sein sollen, dann wähle ich natürlich diese... aber die Frage stellt sich, wie regelt das BIOS das ganze? Weil der Unterschied 4 Sek. (über BIOS-Int) und 33 Sek. (über meine Funktion) ist schon enorm... Da hat das BIOS eindeutig eine genialere Methode...

Kann es daran liegen, dass ich mich genau wie im Datasheet beschrieben an den Ablauf des Sektoren-Lesens halte?

  • 1. Recalibrate
  • 2. Initialize DMA
  • 3. Read-Command
  • 4. Wait for IRQ
  • 5. Result ok?
  • 6. Complete

Natürlich schalte ich vorher den Motor an...

Grüße Cheebi
0100 1001 0100 1100 0100 0001 0010 0000 0011 1010 0010 1101 0010 1010
http://www.cheebi.de

Thoth

  • Beiträge: 62
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 22. June 2007, 07:46 »
Rekalibrierst du vor jedem einzelnen Sektor? Ich könnte mir denken, dass das BIOS den Motor noch ein Weilchen anlässt (zumindest rattert bei mir die Diskette noch weiter, wenn schon längst nichts mehr gelesen wird) und wenn dann ein weiterer Aufruf kommt, dann wird einfach der nächste Sektor gelesen, ohne die ganze Initialisierung. Und 98 Kalibrierungen gegen eine könnte dann schon was ausmachen.

Aber das ist nur geraten :)
Du könntest dir natürlich auch den Source vom Bochs-BIOS angucken.
Madness isn't a bug - it's a feature

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #8 am: 22. June 2007, 12:23 »
iirc ist ein recalibrate nur bei Fehlern sinnvoll. Mir fehlt aber der Seek. Der sollte zumindest kommen wenn sich der track verändert.
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

Cheebi

  • Beiträge: 91
    • Profil anzeigen
    • Cheebis Webseite
Gespeichert
« Antwort #9 am: 23. June 2007, 02:12 »
@ bluecode:
ich hab mir mal deinen fdc-treiber angesehen... prinzipiell funktioniert mein fdc-treiber genauso. ein paar Sekunden konnte ich eisparen, indem ich kleinere wartezeiten (zB für Motor an, etc) gewählt habe. ich könnte mir vorstellen, dass es am dateisystem-Modul hängt... das suchen der sektoren in der fat dauert ja auch (wenn auch nur kurz)
wie läuft dein fdc-treiber? ich konnte dein os nicht starten "failed to set scancode set 2"...

gruß

cheebi
0100 1001 0100 1100 0100 0001 0010 0000 0011 1010 0010 1101 0010 1010
http://www.cheebi.de

FreakyPenguin

  • Administrator
  • Beiträge: 301
    • Profil anzeigen
    • toni.famkaufmann.info
Gespeichert
« Antwort #10 am: 23. June 2007, 02:16 »
Schaltest du denn den Motor für jeden Sektor an und wieder aus?

Cheebi

  • Beiträge: 91
    • Profil anzeigen
    • Cheebis Webseite
Gespeichert
« Antwort #11 am: 24. June 2007, 00:59 »
@FreakyPenguin : nein...
0100 1001 0100 1100 0100 0001 0010 0000 0011 1010 0010 1101 0010 1010
http://www.cheebi.de

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #12 am: 24. June 2007, 06:35 »
wie läuft dein fdc-treiber? ich konnte dein os nicht starten "failed to set scancode set 2"...
War das die v0.1 von lightOS?
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

Cheebi

  • Beiträge: 91
    • Profil anzeigen
    • Cheebis Webseite
Gespeichert
« Antwort #13 am: 24. June 2007, 13:49 »
ja... das hab ich auf deiner HP gefunden...
0100 1001 0100 1100 0100 0001 0010 0000 0011 1010 0010 1101 0010 1010
http://www.cheebi.de

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #14 am: 08. August 2007, 10:10 »
Wenn direkte Portzugriffe schneller sein sollen, dann wähle ich natürlich diese... aber die Frage stellt sich, wie regelt das BIOS das ganze? Weil der Unterschied 4 Sek. (über BIOS-Int) und 33 Sek. (über meine Funktion) ist schon enorm... Da hat das BIOS eindeutig eine genialere Methode...
Die Frage habe ich mir auch schon oft gestellt. Interessanter fände ich aber die Implementation von DOS. Das BIOS auf meinem 286er hat große Probleme mit dem FDC, funktioniert aber.
Gut 30 Sekunden, bis "Starten von MS-DOS..." auf dem Bildschirm steht. Währenddessen rattert das Diskettenlaufwerk nicht, nur die Diskette nutzt sich ab und die Lampe leuchtet. Danach läuft der DOS-eigene Treiber und nutzt das Laufwerk aus.

Minix kommt damit ebenfalls nicht klar und braucht mehrere Minuten, bis eine Diskette gelesen ist. Gleiches gilt für DIAG (Diagnoseprogramm, im ROM enthalten).

Gruß,
Svenska

 

Einloggen