AmigaOS 4 mittels Qemu auf einem emulierten Pegasos 2

[Maijestro]

@Cyborg

Danke für die detaillierte Erklärung das hilft auch um vielleicht den internen RTL8319 Treiber von Qemu verbessern zu können. Darum bat ich dich auch um diese Informationen die ich weiterleiten kann, noch wissen wir nicht ob es direkt an dein Treiber unter AmigaOs4.1 liegt/lag oder den Treiber der von Qemu emuliert und vielleicht Funktionen fehlen die ein echter Treiber mit auch echter Hardware benötigt um vernünftig arbeiten zu können.

Hab gerade 3,5 GB an Daten über SMB2 kopiert, keine Probleme. Verbesserung der Downloadraten ist wohl derzeit nicht möglich?

Fakt ist der Test Treiber funktioniert Und dafür bin ich dir sehr dankbar und möchte mich auch dafür erkenntlich zeigen. Ich bin mir nicht sicher ob du auch der Server Betreibers dieses Forums bist, aber sollte das so sein würde ich gerne eine Spende da lassen.

Die Veröffentlichung über AmiUpdate wäre sehr gut oder auch Os4Depot. Ich werde sehen wie du dich entschieden tust und muß dann natürlich auch meine geschriebene Installationsanleitung diesbezüglich anpassen, aber das ist es mir alle male wert da auch andere diesen Treiber dann nutzen können.

Noch ma vielen lieben dank.

[Cyborg]

Wie ich bereits an anderer Stelle (oder war es sogar genau in diesem Thema?) erklärte: mein Treiber holt raus, was rauszuholen ist. Die Flaschenhälse sind die AmigaOS-I/O (Dateisysteme) und insbesondere Roadshow bei allen Transfers über das lokale Netzwerk hinaus. Siehe z.B. lokale FTP Transfers reizen leicht die 100Mbit einer RTL8139 aus, ein Download aus dem Internet darf froh sein, die 10Mbit zu knacken (bei deutlich schnellerer Leitung).

Danke für Dein Angebot, aber ich bin nicht (mehr) Betreiber von os4welt. Du darfst natürlich deshalb gerne trotzdem ans Forum spenden Ansonsten paßt das für mich schon.

[Joerg]

Die Flaschenhälse sind die AmigaOS-I/O (Dateisysteme) ...

Sollte nur bei Dateisystemen der Fall sein die noch das alte AmigaOS Packet FS API benutzten, z.B. FFS, aber nicht bei RAM-Hanlder, NGFS, etc., die das neue AmigaOS 4.1 Vector FS API benutzten.
Meine OS4 SFS Versionen benutzen keines davon, sondern ein eigenes, von mir implementiertes API, was von der Geschwindigkeit her irgendwo zwischen dem alten AmigaOS <= 3.x Packet und dem AmigaOS 4.x Vector API sein sollte.

[balaton]

Dabei wird als erster Schritt ein Statusfeld des Pakets gelesen und in drei mögliche Pfade gesprungen:

1) Empfangenes Paket OK -> normale Bearbeitung, Platz wird frei, nächstes Paket.
2) Empfangenes Paket fehlerhaft -> weitere Fehlerbehandlung auf Basis des restlichen Statusfelds, Paket verwerfen, nächstes Paket oder in schweren Fällen zurücksetzen des Netzwerkchips.
3) Empfangenes Paket ist noch nicht vollständig -> überspringen, nächstes Paket behandeln oder Behandlung beenden.

Aus mir unbekannten Gründen löst die RTL8139-Emulation von Qemu einen oder beide der obigen Interrupts aus, ohne das Statusfeld wie erwartet zu setzen. Es ist schlicht leer, womit in Zusammenhang mit "Rx Buffer Overflow" nicht gerechnet wird, da ich dieses Verhalten nicht aus der Dokumentation herauslesen konnte/kann. Durch das leere Statusfeld wurde das Paket zwar als fehlerhaft erkannt, aber die weitere Fehlerbehandlung endete in einem undefinierten Zustand, woraus der Treiber nicht mehr herauskam.

Welche Statusfeld ist das un wo soll es sich befinden? Ich wollte die QEMU RTL8139 Emulation prüfen aber ich bin mir nicht sicher nach was soll ich suchen. Die Bits ins Interrupt Status Register sollten immer richtig sein und ich habe nichts gefunden in die Protokolle mit "IRQ 1 (0000" also ich denke es ist nicht das ISR.

Ich bin mir nicht sicher, ob die Implementierung von Qemu hier falsch ist oder ich einfach nicht die richtige RTL8139-Dokumentation habe, in der der Fall eines komplett leeren Statusfelds beschrieben wird. Aber in keiner meiner Dokumentationsvarianten konnte ich dazu etwas finden. Fakt ist, daß dieser Fall offensichtlich bei echten RTL8139-Karten bisher nicht auftrat, ob zufällig oder nicht.

Es könnte sein QEMU emuliert nicht alles korrekt aber es sieht aus auch die Dokumentation ist nicht eindeutig über wie die Bits ins ISR gelöscht sein soll wie es hier: https://wiki.osdev.org/RTL8139 geschrieben. Wir könnten die Emulation anpassen wenn wir wussten wie echte Karte functioniert aber Ich weiss das nicht.

Diese emulation funktioniert mit viele andere Operations Systeme aber es könnte sein die Triebern waren schon nach QEMU anngepasst weil diese Emularion is sehr alt in QEMU. Das auch heisst das eine Änderung der Emulation könnte Probleme vorbringen für andere OSe also es soll wirklich die richtige Karte verfolgen und mit tests oder Dokumentation beweisen. (Und es ist nicht für QEMU 9.0 die ist shon bei RC2 also vielleicht nur in QEMU 9.1 eest im August.)

[Cyborg]

@Joerg
Richtig, viele benutzen aber eben auch noch FFS2 und das nutzt nicht die Vektor-API. Aber wie gesagt, der schlimmste Flaschenhals ist Roadshow mit seinem TCP/IP-Kern von 1994 (wie auch jeder andere AmigaOS-TCP/IP-Stack). Da wird jedes Paket vom Kabel bis zum Client zig Mal (grobe Schätzungen gehen von einer zweistelligen Zahl aus!) rumkopiert. Obendrein reden wir bei dem alten Code von einer maximalen Paketgröße von 1500 Bytes (und da ist der ganze Protokolloverhead schon inkludiert), da kann sich jeder selbst ausrechnen, wieviele Pakete es braucht, um heutige Netzwerkgeschwindigkeiten zu bedienen. Das stößt je nach Amiga bei max. 30MiB/Sekunde im Laborversuch an seine Grenzen. Und wenn der Client dann auch noch stumpf alles sofort wegschreiben will, was er von bsdsocket bekommt, ohne selbst ein wenig zu puffern, um auf größere Pakete zu kommen, dann gehen auch Dateisysteme und Massstoragetreiber mehr oder weniger schnell in die Knie.

Einziger Ausweg wäre ein neuer, moderner TCP/IP-Stack. Ich will schon seit Jahren einen neuen Stack auf lwIP-Basis bauen, bin aber bisher leider nicht über grundsätzliche Arbeiten hinausgekommen. Das würde auch ganz viele andere Vorteile mitbringen, aber ist halt auch ein relativ großer Aufwand (nicht der erste Port, sondern das Ganze dann auch SANA2 und bsdsocket kompatibel zu machen .. wobei SANA2 dann auch in Teilen erweitert werden müßte). Zeit und Motivation ...

[Joerg]

Und wenn der Client dann auch noch stumpf alles sofort wegschreiben will, was er von bsdsocket bekommt, ohne selbst ein wenig zu puffern, um auf größere Pakete zu kommen, dann gehen auch Dateisysteme und Massstoragetreiber mehr oder weniger schnell in die Knie.

Problem dabei dürfte mit FFS2 auch dessen ziemlich unbrauchbarer DiskCache sein, falls den überhaupt Jemand benutzt: Muss manuell mit "fs_plugin_cache" in einer Shell oder der S:User-Startup, für jede Partition einzeln, aktiviert werden.
Sollte mit NGFS (internes DiskCache System, genaue Implementation kenne ich aber nicht) und SFS (diskcache.library.kmod, writes sind erstmal nur memcpy() in den DiskCache) aber kein Problem sein.

Die größten Probleme von Roadshow, und allen anderen AmigaOS TCP/IP Stacks, sind wohl
- Kein Support für Jumbo Frames.
- Kein Support für IPv6.
Evtl. müsste auch noch die API für Ethernet Treiber verbessert werden, aber damit kenne ich mich überhaupt nicht aus.

[Cyborg]

Welche Statusfeld ist das un wo soll es sich befinden?

Ich meine die ersten 32 Bits des Rx Status Descriptors (siehe http://realtek.info/pdf/rtl8139cp.pdf, Seite 70ff), weil man anhand der dort gesetzten Bits entscheiden muß, wie man ein empfangenes Paket behandelt. Zum Beispiel: wenn ein RxBufferOverlow Interrupt ausgelöst wurde, müßte auch BOVF gesetzt sein. Oder auch, ob Frame_Length im erwarteten Bereich ist. Genau dieses Setzen passiert aber in Qemu anders, als ich es bisher auf echten Karten gesehen habe und wie ich die Dokumentation verstehe. Hier bekomme ich Pakete nach einem RxBufferOverflow-Interrupt, die kein einziges Statusbit gesetzt und dazu noch eine Frame_Length von 0 haben. Das ist/war in meinem Treiber unerwartet und führte zu einem Fehlerbehandlungs-Deadlock. Ich habe noch keine echte 8139-Karte erlebt, bei der dieser Zustand jemals erreicht worden wäre.

Ich bin mir nicht sicher, ob die Implementierung von Qemu hier falsch ist [....]

Ich auch nicht. Nach meinem Verständnis der Dokumentation dürfte der oben beschriebene Fall nicht vorkommen. Allerdings scheinen ja andere Systeme damit kein Problem zu haben und ich habe diesen Fall jetzt ja auch in meinem Treiber abgefangen. Von daher würde ich sagen, wir leben halt mit dem Fragezeichen und sind zufrieden damit, daß es jetzt läuft. Die etwas erweiterte Statusabfrage schadet ja auch nicht.

[Cyborg]

Problem dabei dürfte mit FFS2 auch dessen ziemlich unbrauchbarer DiskCache sein, falls den überhaupt Jemand benutzt: Muss manuell mit "fs_plugin_cache" in einer Shell oder der S:User-Startup, für jede Partition einzeln, aktiviert werden.

Tatsächlich nutzte ich den Cache jahrelang, als meine Bootpartitoon noch FFS2 war. Ebenso, wie die "relaxed writing strategy", was erhebliche Geschwindigkeitszuwächse bringt. Inzwischen bin ich ebenfalls seit Jahren auf NGFS, wobei hier die bisher öffentliche Version meines Wissens so alt ist, daß man von deren Gebrauch eher abraten sollte.

Die größten Probleme von Roadshow, und allen anderen AmigaOS TCP/IP Stacks, sind wohl
- Kein Support für Jumbo Frames.
- Kein Support für IPv6.
Evtl. müsste auch noch die API für Ethernet Treiber verbessert werden, aber damit kenne ich mich überhaupt nicht aus.

Wie ich schrieb, Jumboframes sind unabdingbar für alles jenseits von 100Mbit (Roadshow unterstützt nur max. eine MTU von 1500, also Pakete mit 1536 Bytes). Das allein ist aber nur die halbe Miete, denn auch, wenn Du mit 9K statt 1,5K hantierst, wirst Du die Geschwindigkeit zwar erhöhen, aber nie wirklich auch nur annähernd an deren Maximum kommen, solange Du die Pakete genauso oft durch die Gegend kopierst, wie es aktuell die Stacks machen.

IPv6 ist zwar nicht relevant für Geschwindigkeit, aber wäre natürlich ein großer Vorteil eines neuen Stacks, wofür man aber - wie ich auch schrieb - SANA2 und bsdsocket API erweitern müßte, weil das gesamte Netzwerkuniversum von AmigaOS bisher eben nur IPv4 kennt.

Ach, und Roadshow hat ja auch noch das Problem (nicht sicher, ob das Miami oder AmiTCP auch haben), daß die Transfergeschwindigkeiten über LAN-Grenzen hinaus dramatisch einbrechen. 10MiB/Sekunde im lokalen Netz sind kein Problem zu erreichen. Läd man aber aus dem Internet über eine 100Mbit-Leitung, wird man bei 1-2MiB/Sekunde hängen bleiben. Mit ein paar Tweaks in den Roadshow-Eingeweiden-Einstellungen kann man das noch etwas erhöhen, aber auch hier kommt man nie an das Maximum. Ich hatte mit Olaf deshalb schon mehrfach Kontakt, aber er konnte sich das bisher auch nicht erklären. Ich vermute, es liegt u.A. am alten/fehlerhaften/nicht vorhanden Windowing von Roadshows Kern .. mit einem neuen Stack könnte sich das Problem auch in Luft auflösen.

[ThorstenS]

Der oder die Linux TCP/IP Stack(s) haben damit wohl allesamt keine Probleme ?!?

Wieso nicht für AmigaOS4 portieren?

[Cyborg]

Ist dieses Frage ernst gemeint?