🚀 go-pugleaf

Hallo.

Ich hatte jetzt ein halbes Jahr tierische Probleme mit meinem A3000 SCSI
Interface. Ich bekam etliche sehr hilfreiche Mails, jedoch konnte keiner
mit 100%iger Sicherheit sagen, daß es jetzt Dies oder Jenes ist. Es wurden
mir allerlei Vorschläge gemacht, die mich dann schlußendlich auf die
richtige Spur brachten. Da man in den Newsgroups noch immer sehr viel über
alle Arten von A3000 SCSI Problemen ließt, möchte mein Problem jetzt kruz
beschreiben.

Um es gleich vorwegzunehmen, alles funktioniert jetzt
wunderbar in alles möglichen Konfigurationen.

Mein System wie es mal war:
A3000/25 - 2/8 MB RAM
Festplatte : Quantum Fireball 1080S, aktiv terminiert
Streamer   : HP 35470A über 1,8 Meter Kabel mit HA, passiv terminiert
Chips      : WD -04
             DMAC -02
             RAMSEY -04

<sb> Teil 1 - Der WD Chip

Ich kaufte mir einen Streamer hauptsächlich um Backups zu machen, jedoch
auch um Tapes wie ein DOS Device anzusprechen. Somit benutze ich Diavolo
1.27 (inzwischen 3.2) und Tapeworm. Diavolo war quasi nicht zu benutzen.
Ständig meldete die Compare Funktion Fehler auf den Backups. Tapeworm
schien zu funktionieren, bis mal ein Bild runterholen wollte und
feststellte, daß die Hälfte alles IFFs korrupt waren. Die Orginals waren
selbstverständlich gelöscht ;((

Unter anderem brachte mich Rainer Benda darauf, daß es der WD sein könnte.
Die Terminierung prüfte ich mehrmals, die konnte as also nicht sein. Ich
rüstete also den WD auf Revision -08 auf und siehe da, Tapeworm
funktionierte. Ich habe bis heute über 10 GB so abgespeichert (5 Tapes) und
jedes einzeln File mittels der Compare Funktion überprüft. Kein einziger
Fehler bei der Übertragung!

Diavolo funktionierte jedoch immer noch nicht. Es waren weniger Fehler,
aber es lief noch immer nicht so wie es sein sollte.

<sb> Teil 2a - Die Terminierung

Dies war die härtere Nuß. Meine ewigen Fehlerbeschreibungen brachten mir
über 100 Mails, wo mir alles über Termination im Allgemeinen, und im
Speziellen über den A3000 beschrieben wurde.

Der A3000 braucht, gegen alle Regeln, keine Widerstände am HA (der A3000T
braucht welche). Wenn die Kabel kurz sind, ist dies durchaus möglich. Ein
25 poliger Terminationsstecker am externen SCSI Anschluß erübrigt sich also
damit. Externe Geräte können einfach angeschlossen werden. Diese müssen
jetzt aber terminiert werden, da die SCSI Kette wesentlich verlängert
wurde.

Ob es jetzt aktive oder passive Terminierung ist, ist beim A3000 nicht so
wichtig. Der HA ist zwar SCSI-2, arbeitet jedoch nicht so wahnsinnig
schnell, daß man einen aktiven Stecker bräuchte. Aktive Terminierung
liefert lediglich eine konstantere Spannung (2.85V) und braucht weniger
Strom. Wenn man den SCSI-2 Empfehlungen jedoch folgt, terminiert man aktiv
am SCSI-2.

Die Jumper auf den externen Geräten setzen *meistens* nur TermPWR unter
Strom (Pin 25 am 25 poligen Kabel: Pin 26 am 50 poligen Kabel). Diese
Leitung benutzen die Terminationsstecker. Falls hier kein Saft drauf ist,
kann die Terminierung mittels Stecker nicht funktionieren. Beim A3000
liefert der HA den Strom. Es gab A3000, bei denen die Diode D0800 (auf der
Platine neben dem externen SCSI Stecker Richtung Netzteil) entweder gar
nicht vorhanden war, oder verkehrt eingebaut wurde. Dann gib's natürlich
keinen Strom an TermPWR, außer daß Dieser von einem externen Gerät gespeist
wird. Es sollte übrigens auch nur ein Gerät TermPWR speisen. Es kann den
Geräten technisch jedoch nicht schaden, wenn mehrere externe Geräte TermPWR
auch gejumpert haben. Sie sollten (nach den SCSI Regeln) alle eingeschaltet
sein, meistens klappt es aber auch wenn sie ausgeschaltet sind.

Wie findet man jetzt heraus, ob man einen aktiven oder passiven
Terminationsstecker hat? Man misst mit dem Ohmmeter. 4 Punkte reichen: D0,
D1, TermPWR und Masse.

                   passiv  aktiv
                   ------  -----
  Masse   - D0  :  143     *
  D0      - D1  :  264     220
  TermPWR - D0  :  137     *

  * Man kann beim aktiven Stecker nur zwischen D0 und D1 messen, da alles
    andere den Innerwiderstand des Spannungsreglers mißt.

Widerstandarrays sind übrigens immer passiv. Neuere Festplatten sind
meistens aktiv terminiert. Wenn man keine Array mehr auf der Platine sieht,
kann man fast sicher sagen, daß es sich um aktive Termination handelt.

Man sollte auch wissen, daß Händler meistens pasisve Terminatoren liefern.
Die sind halt etwas billiger. Sie liefern ständig SCSI-2 Geräte mit
passiven Terminatoren aus, was nicht den Empfehlungen entspricht (zwei
Freunde von mir konnten das ebenfalls bestätigen). Meinen Streamer mit
Terminator bezog ich von Alternate. Als ich den Stecker nachgemessen hatte,
stellte ich zudem noch fest, daß alle Werte etwa um 10-15% geringer waren
als die errechneten Soll-Werte. Tolleranzen der Widerstände sind also
angeblich angesagt (gewollt?).

Der SCSI Bus sollte auch nicht dreifach terminiert sein. Es gibt Systeme,
wo dies Abhilfe brachte, jedoch ist dann irgendwo was anderes Schuld an
SCSI Problemen. Der SCSI Bus darf nur an beiden physikalischen Enden
terminiert sein. Alles Andere kann funktionieren, sollte es aber nicht.
(siehe oben; fehlende Terminierung am HA)

Zurück zu meinem Problem; aktive Terminierung brachte eine Reduzierung der
Fehler (Backups mit Diavolo), jedoch keine Beseitigung. Also mußte da noch
was sein.

<sb> Teil 2a - Die Chips

Dann gibt es da noch den DMAC und den RAMSEY. Ich hatte bereits betagte
Versionen in meinem A3000, also beschloß ich diese beiden PLCC Chips auch
noch zu wechseln. Man kann dies übrigens mit einer verbogenen Büroklammer
sehr gut bewerkstelligen, und braucht sich keine teure spezielle Zange zu
kaufen. Professionell ist das zwar nicht aber es geht. Wenn man ausrutscht
hat man natürlich alles in der Umgebung umgewalzt ;) Also nur für ruhige
Hände und Gemüter!

Gegen *aller* Mails, gibt es den DMAC in der Version -04 noch in den
Staaten. Ich habe gleich 2 Händler über Newsgroups gefunden. Ich hatte die
Chips innerhalb 3 (drei !) Tagen. Bezahlt wurde mit MasterCard über PGP
kodierte Mails. Der RAMSEY -07 wird noch für den A4000 gebaut, stellt also
bezüglich Beschaffbarkeit kein Problem dar.

Da es beim Diavolo Fehler lediglich um sporadische Übertragungsfehler
von Files ging, die zudem noch meistens in den gleichen Directories lagen,
lag die Vermutung nahe, daß es sich hierbei um ein Problem mit diesen Chips
handeln könnte. Rainer Benda bestätigte mir diese Möglichkeit.

Nun ja, die Chips sind getauscht und es läuft :-))

<sb> Teil 3 - Synchron Modus

Da gibt es dann noch den Synchron Modus. Also dieser Modus reduziert das
Overhead des SCSI Busses, bringt aber keine drastischen Geschwindigkeits-
vorteile. Falls es externe Störeinflüße gibt, treten diese im SYNC Moduc
eher auf. Falls das SYNC Flag gesetzt ist, fragt der HA lediglich die
Geräte einzeln ab, ob sie SYNC unterstützen. Falls nicht, wird dieser Modus
bei diesen Geräten nicht angewendet. Es gibt jedoch Geräte, die vorgeben
SYNC zu beherrschen, dies aber nicht tun. Wenn man ein solches Gerät hat,
sollte man das SYNC Flag mittels SCSIPrefs (u.A. - zu beziehen aus dem
Aminet) löschen.

Hier ein Zeitvergleich eines Backups der Amiga Plus CD 5/6 mit Diavolo 3.2
und 2 Transfer Buffern (32 KB und 128 KB).

  SYNC  Buffer  Zeit     Rang
  ----  ------  -------  ----
  ON    32 KB   1:13:01  2
  OFF   32 KB   1:13:37  4
  ON    128 KB  1:12:06  1
  OFF   128 KB  1:13:25  3

Rang wie zu erwarten, jedoch keine erheblichen Vorteile punkto Zeit im
SYNC Modus.

--

Mein System heute:
A3000/25 - 2/12 MB RAM
Festplatte : Quantum Fireball 1080S, aktiv terminiert
Streamer   : HP 35470A über 1,8 Meter Kabel mit HA, aktiv terminiert
Chips      : WD -08
             DMAC -04
             RAMSEY -07

Falls ich jetzt nicht alle Klarheiten beseitigt haben sollte, bitte
nachfragen ;=). Ich bin übrigens kein Informatiker oder Techniker. Alle
Informationen wurden mir von Leuten in den Newsgroups mitgeteilt, bei denen
ich mich bedanken möchte. Ohne deren Hilfe würde mein System wahrscheinlich
noch immer nicht korrekt laufen.


Vielen Dank !


--
 Georges Heinesch, Luxembourg
 geohei@ibm.net
 PGP 2.6.2i public key available on request and on public servers

... because water just isn't wet enough !