Hello, Guest the thread was viewed15k times and contains 80 replies

last post from MOS6510 at the

Projekt "Etherbridge"

    Quote from zwacklmann

    hab mit meiner A2286 mal einen kleinen Speedtest gemacht.


    Super Danke! Ich werde die Speedtests mal sammeln.


    Seit heute gibt übrigens eine Version 1.2.2. Spiel mal bitte etwas mit dem Parameter "COMMODE=0" (in EtherPrefs als "A2386-Mode" bezeichnet).
    Es gibt einen Bug in der Altversion von 1999, die den Interrupt-Modus nicht verwendet. Manche User berichten, dass der Int-Modus auf den älteren Karten doch besser ist. Es kommt auf die Konfiguration an (Amiga-Prozessor, PC-Prozessor, Netzwerkkarte 8Bit, 16Bit)...


    => Etherbridge V1.2.2


    Aktuell habe ich nur die PC-Seite überarbeitet (EBSERVER.EXE). Das Amiga Device kommt jetzt als nächstes dran... ^^

    Ein kleines Statusupdate:


    Die SANA2 Release 3 Unterstützung ist drin (vorher nur R2). Damit gehen dann auch die DMA-Transferroutinen des Treibers. Mit Miami 3.2b funktioniert das ganze. Leider scheint Miami mit den Funktionen aber ein Problem zu haben. Ich musste einen Workaround ins Device einbauen, nachdem ich mir die Transferroutinen in Miami in Assembler angeschaut habe. Mit Miami DX hab ich noch nicht getestet, denn mein aktueller Entwicklungs-Amiga ist ein A2000 umbeschleunigt, da läuft MiamiDX nicht mit (ab 68020 aufwärts). Mein A4000 ist immernoch im Trockendock (Elkos müssen noch getauscht werden, Akkuschaden beseitigt). Leider läuft Roadshow aus unbekannten Gründen auf dem umbeschleunigten A2000 weiter instabil, so dass mein Referenz-Stack weiter Miami/DX sein wird...


    Geschwindigkeitstests stehen noch aus. Ob die DMA-Funktionen der Schnittstelle schneller sind, kann ich noch nicht sagen.


    Leider steht meine A2386 Brückenkarte gerade zusätzlich auch der "Hebebühne", da ich die Schäden des dort ausgelaufenen Akkus nun doch beseitigen muss. Der Schaden war nicht so wild, aber der Sockel des FloppyControllers musste runter und ein neuer drauf. Zusätzlich ein neuer FloppyController, denn der alte hat leicht Grünspan angesetzt. Bei jedem Start der Karte die F1-Taste zu drücken (weil das CMOS wegen der fehlenden Batterie ja nicht so recht stimmt, war zu nervig bei der Entwicklung… :) )


    VG, MOS

    Quote from MOS6510

    Die SANA2 Release 3 Unterstützung ist drin (vorher nur R2). Damit gehen dann auch die DMA-Transferroutinen des Treibers. Mit Miami 3.2b funktioniert das ganze. Leider scheint Miami mit den Funktionen aber ein Problem zu haben. Ich musste einen Workaround ins Device einbauen, nachdem ich mir die Transferroutinen in Miami in Assembler angeschaut habe.


    Jetzt wird's interessant - wir hatten das auch mal mit den DMA-Funktionen eingebaut (damit man einen Kopierschritt einsparen kann), aber Miami (und auch andere Stacks außer Roadshow) haben unsere DMA-stubs nie aufgerufen. Wenn Du nen Hinweis hast, wie Du Miami zum Aufruf der DMA-Copy Routinen bringen kannst, wäre das toll.


    Bisher haben wir nur eine Lösung für AmiTCP, und die ist "etwas dreckig": Man bekommt ja vom Stack einen Pointer auf eine copy-Routine, die man dann selbst aufrufen soll. Wir haben die Datenstrukturen von AmiTCP bekommen (Teil des Quelltextes) und haben unsere eigene Copy-Routine gemacht, die einen Schritt weniger machtl also direkt von der Karte an den Zielort im Speicher und umgekehrt - ohne Zwischenbuffer. Problem ist halt, dass das Stack-spezifisch ist und nur mit AmiTCP funktioniert.


    Miami ist von der Performance her nicht gerade der Brüller - so richtig geflogen ist es damals nur mit MNI-Treiber. Konntest Du einen spürbaren Gewinn messen mit den DMA-copy Routinen?


    Jens

    Quote from Wiesel


    Jetzt wird's interessant - wir hatten das auch mal mit den DMA-Funktionen eingebaut (damit man einen Kopierschritt einsparen kann), aber Miami (und auch andere Stacks außer Roadshow) haben unsere DMA-stubs nie aufgerufen. Wenn Du nen Hinweis hast, wie Du Miami zum Aufruf der DMA-Copy Routinen bringen kannst, wäre das toll.


    Also meine Erkenntnisse beruhen aktuell auf der freien Version von Miami 3.2b. Ich gehe aber davon aus, dass Miami DX das genauso macht.
    Der Stack verhält sich wie in der Spezifikation Sana2R3 vorgegeben: Er liefert beim Öffnen des Devices (u.a.) die Tags "S2 DMACopyToBuff32" und "DMACopyFromBuff32". Wenn das Device etwas von den Paketpuffern haben möchte so ruft er (das Device) die DMA-Funktion auf. Kommt in D0 dann ein Wert ungleich NULL zurück ist das das rohe Zeiger auf die Paketdaten.
    Hat man den Paketpuffer, kann das Device mit dem bestmöglichen Alg für den Prozessor die Daten durch die Gegend schaufeln und den IORequest terminieren. Das war's eigentlich schon…
    ABER: Beim Paketempfang reichte es Miami nicht den IORequest (mit den bereits gefüllten Daten) einfach zurückzuschicken. Miami setzt wohl die Länge der Empfangenen in seiner privaten Paketstruktur (zumindest ist das meine Erkenntnis aus dem Assemberstück). Falls das nicht passiert, erkennt Miami die Empfangenen Daten offenbar nicht…Aktuell interpretiere ich das als Bug in Miami. Ich kann es mir sonst nicht erklären.
    Der Workaround für das Device ist, die Paketlänge im privaten Teil des IORequests zu setzen (eigentlich auch dreckig), falls der Stack sich als "Miami" zu erkennen gab.
    Das war eigentlich schon alles und ist auch keine Hexerei...


    Gern können wir auch beim X-Surf Device mal zusammen drüber schauen, warum es dort nicht geht.


    Speedtests hab ich leider noch nicht. Das Problem mit Miami's DMA Funktionen hatte mich etwas aufgehalten (und leider meine immer noch tauben Finger auch). Aktuell ist meine A2386 auch im Trockendock.

    Für das X-Surf.Device ist die DMA Funktion wie ich es dir schon mal geschrieben hatte vermutlich hochinteressant, wenn der Zielort der Paketdaten in der HW "nicht linear" im Speicher liegt (aber da wolltest Du noch ändern, oder?).
    Aber die Stacks müssen halt den R3-Standard unterstützen…
    Beim Etherbridge Device liegen die Daten linear im Dualported RAM der Brückenkarte bereit, daher ist das entspannter dort. Hier gehen die alten Funktionen auch gut.
    Es sei denn Miami hat nicht sehr performante eigene Transferroutinen. Aber den Teil hab ich mir in Miami noch nicht angeschaut…(dann gibt's auch dort noch Luft nach oben).


    Ich hoffe Jens, ich trete Dir nicht mit dem Device auf die Füße? An die Geschwindigkeit der X-Surf(100) wird sie natürlich nicht heranreichen und nicht jeder hat noch eine Brückenkarte…
    Gewissermaßen sind die beiden Devices ja Geschwister… :) Aktuell macht es gerade wieder Spaß hardwarenahe (Netzwerk)Treiber zu schreiben (nach 4 Jahren iOS)… :)


    VG, MOS

    Hi,


    da mir günstig eine A2286 in die Hände gefallen ist, beschäftige ich mich gerade wieder mit diesem Thema. Ich hab also meine A2088 nun durch die A2286 ersetzt, und sonst alles gleich gelassen, bekomme das Netz damit aber nicht mehr zum Laufen :(


    Was mir auffällt, mit der Karte sind die HD-Zugriffe auf das Image am Amiga wesentlich langsamer, als mit der A2088 das war. Dann ist mir aufgefallen, daß die Janus-Library PC-seitig nun bei 0xD4000 liegt, und nicht mehr bei 0xD0000.
    HIMEM.SYS hab ich schon rausgeworfen, nicht daß der hier Ärger macht. Es gehen schon irgendwie Pakete raus, die scheinen mir aber kaputt zu sein. Komisch ist auch, daß beim Starten von EBSEVER eine Meldung kommt, das wäre nicht die richtige Version 1.2, stattdessen 0.0 :?:


    Jemand ne Idee, woran das liegen könnte?


    EDIT: Solche Pakete kommen da raus anstatt PING:


    Code
    1. 18:57:12.440102 ff:ff:ff:ff:c0:ff > 00:ff:ff:ff:ff:ff, ethertype Unknown (0xd4ff), length 86:
    2. 0x0000: 08ff ffff 00ff 06ff 00ff ffff 00ff 54ff ..............T.
    3. 0x0010: 0aff ffff 00ff 00ff 80ff ffff 0aff 00ff ................
    4. 0x0020: eaff ffff ffff ecff 00ff a0ff ffff 00ff ................
    5. 0x0030: 00ff e0ff ffff e8ff 00ff f8ff ffff 20ff ................
    6. 0x0040: 00ff ffff ffff 00ff ........

    Ich komm hier nicht weiter, immer das selbe Problem, vielleicht hat die Karte auch einen Defekt. Kann mir wenigstens mal jemand bestätigen, daß das hier korrekt ist?

    Quote from kbr

    Dann ist mir aufgefallen, daß die Janus-Library PC-seitig nun bei 0xD4000 liegt, und nicht mehr bei 0xD0000.

    Auch bei der A2286 liegt der Handler per Default bei "D000". Wenn der EBServer schon wegen der Verion meckert, dann stimmt vermutlich schon etwas mt dem DPRAM nicht.
    Ein Wunder, dass überhaupt die Software anspringt....Und der PC bootet aus dem Amiga-Harddisk-file?


    Versuche nochmal die Janus Software 2.1 neuzuinstallieren. Die Installation bringt dann den richtigen Handler für die richtige Karte mit. Der könnte nämlich falsch sein, wenn Du von der A2088 her wechselst.


    Bei meiner A2386 Installation musste ich nach langem Suchen die Software nochmal mit A2286-Option installieren, da Commodore einen Fehler auf der Installationsdiskette hatte und einen nicht funktionstüchtigen Handler für die Karte installierte (!)...

    Wie es der Teufel will, funzt es nun nach Neuinstallieren der PC-Software. Verstehen tue ich das aber nicht, da bei der Auswahl die A2088 und A2286 identisch sind. Leider hab ich mir dabei jetzt mein Hardfile gelöscht, das muß ich erst wieder rüberziehen, aber zum Glück hatte ich ebserver.exe noch auf einer Diskette :thumbup:


    Im Moment steckt die Netzwerkkarte in einem 8-bit Slot, weil in dem 2. 16-bit der SCSI-Controller steckt, Ich steck das mal noch um, und poste dann Performancewerte...

    Es ist zum Verrücktwerden, in einem 16-bit Slot hab ich jetzt wieder die gleichen Probleme, aber wenigstens kann ich damit den Fehler wieder etwas weiter eingrenzen. Am Slot selber kann ich mir aber nicht vorstellen, weil da der SCSI-Controller problemlos läuft. Tja so hat man immer eine Beschäftigung...

    Tja, ich hatte keine Idee mehr, woran das noch liegen könnte, und schieb es somit auf die Etherbridge Software, irgendwas wird da wohl bei 16-bit Datenbus falsch angelegt, aber ohne Einblick in die Sourcen...


    EDIT: Wenn ich mir den tcpdump so anschaue, entsteht mir der Eindruck, daß nur jedes 2. Byte geschrieben wird, oder so, bzw. das Low-Nibble hat komischerweise immer 0xff.

    Hattest du mal mit den Testtools der Packet Treiber herumgespielt (PKTSEND.com, PKTTRAF.COM, PKTWATCH.com...) ?
    Wenn dann machen die DOS Treiber blöd, weil die Hardware vielleicht blöd macht (oberer Socket defekt, etc...).


    Etherbridge benutzt nur die DOS-Treiber, die natürlich laufen müssen.

    Hast Du die "0xff Bytes" auch mit PKTSEND.com gesehen?
    Wenn jedes 2. Byte 0xff geschrieben wird klngt das für mich nach einem RAM-Defekt oder Bus-Defekt. Vielleicht auch einfach verdeckte Kontakte, entweder am Sockel der Netzwerkkarte oder eben auch an der Brückenkarte. Hast Du die schon mal gereinigt?

    Folgendes hab ich zu den Packet Treibern gefunden:



    Quote

    Developers should note that, on many networks and protocol families, thebyte-ordering of 16-bit quantities on the network is opposite to the nativebyte-order of the PC. (802.5 Token Ring is an exception). Thismeans that DEC-Intel-Xerox ethertype values passed to access_type()must be swapped (passed in network order). The IEE 802.3 length fieldneeds similar handling, and care should be taken with packets passedto send_pkt(), so all fields are in the proper order.


    Wurde das berücksichtigt?

    Der Ebserver vom Etherbridge verwendet bei access_type() im Parameter "ethertype" den Wert FFFF, was Wildcard entspricht. Will heißen, gibt mir alles. Als Type wird "Ethernet" fix voreingestellt. Die Byteorder spielt hier also keine Rolle.


    Die Stelle sieht konkret so aus:


    C
    1. res = AccessType( pktDriverIntNumber,
    2. CL_ETHERNET, //class "Ethernet" (0x01)
    3. TYPE_ANY, //=> 0xffff: "type any"
    4. 0, //Unit number "0"
    5. NULL, //=> ALL
    6. 0, //=> Typ len == 0
    7. AsmPacketRecFunc //RX Callback
    8. );


    Nur mal angenommen, die Byteorder würde hier eine Rolle spielen, wie sollte sich dann eine falsche Byteoder der Adressfelder eines Paketes auf ein Vertauschen der Nutzdaten der Pakete selbst auswirken? Wären die Adressen verdreht (durch falsches Big/Little Endian) wäre nur Empfänger und/oder Absender falsch, nicht aber die Nutzdaten des Paketes selbst. Du sagtest ja, du siehst jedes zweite Byte der Nutzdaten mit 0xFF.


    Da die Treiberansteuerung prinzipiell bei anderen Usern funktioniert, kann es aus meiner Sicht bei dir wirklich nur um einen lokalen Defekt einer Speicherseite liegen, also defekte obere/untere 8 bit ISA Hälfte oder in der Netzwerkkarte etc sein...


    VG, Heiko

    Hast schon recht, meine letzte Aussage war Quatsch, denn würde es ja grundsätzlich Probleme geben.


    Hab letztens nochmal damit rumgespielt, scheint wohl wirklich irgendwas an meiner Hardware defekt zu sein, auch mit den PKT-Tools kommt schon Müll raus. Empfangen geht jedoch ohne erkennbare Probleme.
    Eine NE2000 Karte 16bit funktioniert auch tadellos, so daß der Verdacht am ehesten Richtung Netzwerkkarte geht. Wenn ich mal noch viel Lust habe, steck ich die mal in einen normalen PC, aber da muß ich mir erstmal so ein altes Ding mit ISA-Bus rauskramen...


    Klaus