SCSI Terminierung?
Georges Heinesch
Ich habe eine Adapter ASC-19160 SCSI Karte im Betrieb.
Die 3 Stecker sind folgendermassen belegt:
* 50-pin Internal Fast/Ultra-SE Connector
- nicht belegt
* 68-pin Internal LVD/SE Connector
- HP DAT72 C7438A Streamer - nicht terminiert (40MBps / 16 Bit)
(68 poliger Kabel am Ende mit Terminierungsstecker)
* 50-pin External High Density Fast/Ultra-SE Connector
- CD Player - nicht terminiert (20MBps / 8 Bit)
- CD RW Laufwerk - nicht terminiert (20MBps / 8 Bit)
- HP DDS3 C1537A Streamer - nicht terminiert (10MBps / 8 Bit)
- HP DDS3 C1537A Streamer - nicht terminiert (10MBps / 8 Bit)
(50 poliger Kabel am Ende mit Terminierungsstecker)
Die 4 Geräte am externen Stecker sind in einem getrennten Gehäuse
untergebracht, welches sich separat vom Rechner ausschalten lässt.
Das Problem besteht jetzt darin, dass wenn ich ein Backup auf das DAT72
Laufwerk (internes Gerät) mache, ich maximal 25 GB auf das Band bekomme
(native 36 GB) wenn die externen Geräte ausgeschaltet sind (SCSI Kabel
noch immer angeschlossen). Wenn ich jetzt die externen Geräte
einschalte, bekomme ich 33.5 GB auf das Band (die gleichen Daten!).
Diese Werte beziehen sich auf Hardware und Software Kompression
ausgeschaltet! 33.5 GB halte ich normal, wenn man von 2.5 GB Overhead
ausgeht.
Warum hat das Ausschalten der externen Geräte einen Einfluss auf die
Kapazität des internen DAT72 Streamers?
Ich dachte dass wenn ich die externen Geräte abziehe, ich die erwarteten
33.5 GB wieder speichern kann? Leider war dem nicht so. Wieder nur 25 GB.
Es kann doch nicht sein, dass der SCSI Adapter nur richtig funktioniert
wenn externe Geräte angeschlossen _und_ eingeschaltet sind ?!?!
Ich dachte zuerst an ein Terminierungsproblem. Also habe ich testweise
im BIOS des Adaptec die Terminierung auf beiden Steckern auf Enabled
gesetzt. Keine Änderung des Verhaltens. Ich konnte immer nur noch 25 GB
auf das Band schreiben.
Auszug aus dem Benutzerhandbuch:
---- cut here ----
SCSI card SCSI Termination—(Default: Automatic) Determines
the termination setting for the SCSI card. The default
setting for both the LVD/SE and SE connectors is Automatic,
which allows the SCSI card to adjust the termination as needed
depending on the configuration of the connected SCSI devices.
We recommend that you do not change this setting.
---- cut here ----
Frage ... aktivieren die Terminierungseinstellungen im BIOS des Adapters
wirklich die Terminierung, oder legen sie nur Strom auf die TERMPWR
Leitung des Kabels damit der aktive Terminierungsstecker arbeiten kann?
Zusammenfassung:
Externe Geräte eingeschaltet und angeschlossen: 33.5 GB
Externe Geräte ausgeschaltet und angeschlossen: 25 GB
Externe Geräte getrennt vom Adapter: 25 GB
Gruß,
--
Georges Heinesch
Marcel Müller
gleich zu Eingangs, ich vermute kein SCSI-Problem.
Georges Heinesch wrote:
> * 68-pin Internal LVD/SE Connector
> - HP DAT72 C7438A Streamer - nicht terminiert (40MBps / 16 Bit)
> (68 poliger Kabel am Ende mit Terminierungsstecker)
>
> * 50-pin External High Density Fast/Ultra-SE Connector
> - CD Player - nicht terminiert (20MBps / 8 Bit)
> - CD RW Laufwerk - nicht terminiert (20MBps / 8 Bit)
> - HP DDS3 C1537A Streamer - nicht terminiert (10MBps / 8 Bit)
> - HP DDS3 C1537A Streamer - nicht terminiert (10MBps / 8 Bit)
> (50 poliger Kabel am Ende mit Terminierungsstecker)
> Das Problem besteht jetzt darin, dass wenn ich ein Backup auf das DAT72
> Laufwerk (internes Gerät) mache, ich maximal 25 GB auf das Band bekomme
> (native 36 GB) wenn die externen Geräte ausgeschaltet sind (SCSI Kabel
> noch immer angeschlossen). Wenn ich jetzt die externen Geräte
> einschalte, bekomme ich 33.5 GB auf das Band (die gleichen Daten!).
Waren die externen Geräte beim booten des OS auch aus? Wenn nein, wäre
es durchaus denkbar, dass regelmäßige Zugriffe auf die CD-ROMs ohne
selbile ins leere Laufen und dabei den Bus immer wieder blockieren
(Timeout), so dass der DDS-Streamer ständig Buffer Underruns kriegt.
Die meisten Betriebssysteme können nicht sonderlich vernünftig mit zur
Laufzeit an- und abgekoppelten optischen SCSI-Laufwerken umgehen, auch
wenn SCSI das grundsätzlich vorsieht.
Ich mache das selbst auch, jedoch bei dem uralten
Kommandozeilen-Linux-Server bin ich mir ziemlich sicher, dass der ohne
mein Zutun nicht in spontanen Aktivismus verfällt.
Marcel
Georges Heinesch
> ...
> Waren die externen Geräte beim booten des OS auch aus?
Ja. Sie waren sogar abgezogen (Stecker der externen geräte physikalisch
vom SCSI Adapter getrennt).
Gruß,
--
Georges Heinesch
Georges Heinesch
>
> ...
>> Das Problem besteht jetzt darin, dass wenn ich ein Backup auf das DAT72
>> Laufwerk (internes Gerät) mache, ich maximal 25 GB auf das Band bekomme
>> (native 36 GB) wenn die externen Geräte ausgeschaltet sind (SCSI Kabel
>> noch immer angeschlossen). Wenn ich jetzt die externen Geräte
>> einschalte, bekomme ich 33.5 GB auf das Band (die gleichen Daten!).
>
> Waren die externen Geräte beim booten des OS auch aus?
Ja. Beim ersten test waren die noch angeschlossen, aber während des
Bootens ausgeschaltet.
Beim zweiten Test waren sogar abgezogen (Stecker der externen Geräte
physikalisch vom SCSI Adapter getrennt).
In beiden Fällen wußte der Adapter also nichts von den 4 Geräten.
Die einzige Konstallation die derzeit läuft ist:
* 50-pin Internal Fast/Ultra-SE Connector
- nicht belegt
* 68-pin Internal LVD/SE Connector
- HP DAT72 C7438A Streamer - nicht terminiert (40MBps / 16 Bit)
* 50-pin External High Density Fast/Ultra-SE Connector
- alle Geräte eingeschaltet
Das absolut Sonderbare ist, dass wenn ich den Stecker für die externen
Geräte abziehe, ich auch nur 25 GB schreiben kann ?!?! Es sieht so asu
als bräuchte der SCSI Adapter eingeschaltete Geräte am externen Stecker!
Kann doch nicht sein ...
Gruß,
--
Georges Heinesch
Michael Baeuerle
>
> Die einzige Konstallation die derzeit läuft ist:
>
> * 50-pin Internal Fast/Ultra-SE Connector
> - nicht belegt
>
> * 68-pin Internal LVD/SE Connector
> - HP DAT72 C7438A Streamer - nicht terminiert (40MBps / 16 Bit)
>
> * 50-pin External High Density Fast/Ultra-SE Connector
> - alle Geräte eingeschaltet
>
> Das absolut Sonderbare ist, dass wenn ich den Stecker für die externen
> Geräte abziehe, ich auch nur 25 GB schreiben kann ?!?! Es sieht so asu
> als bräuchte der SCSI Adapter eingeschaltete Geräte am externen Stecker!
> Kann doch nicht sein ...
Jein. Was er braucht wie jedes andere SCSI device ist korrekte
Terminierung und die Terminatoren brauchen Energie (TermPower). Das
Installation manual zeigt wie der ASC-19160 funktioniert:
http://www.adaptec.com/en-US/support/scsi/u160/ASC-19160/
Auf Seite 2 (bzw. 4) gibt es ein Bild wo man sieht, dass eine AIC3860
Bridge verwendet wird. Auf dem HA gibt es elektrisch also zwei Busse und
er benoetigt daher 4 Terminatoren, einen an jedem Ende jedes Busses. Da
du den internen 50Pin Stecker nicht verwendest haben beide Busse ein
Ende auf dem HA, dort muessen also beide Terminatoren enabled sein.
Beide manuell auf "enable" zu stellen hast du ja bereits probiert, d.h.
daran liegt es nicht. Die beiden anderen Enden der zwei Busse hast du
ebenfalls terminiert, d.h. dein Aufbau sollte korrekt sein.
Dass es nur funktioniert, wenn du die externen devices eingeschaltet
hast deutet darauf hin, dass diese den SE-Bus mit TermPower versorgen,
der HA aber nicht. Normal speist der HA TermPower auf beide Busse ein
(das kann man im Setup nicht beeinflussen), vielleicht tut deiner das
nicht weil z.B. die Sicherung rausfliegt (*). Das kann passieren wenn du
mehr als 2 Terminatoren auf dem Bus hast, als erstes solltest du also
nochmal pruefen, ob in dem externen Gehaeuse wirklich nur ein Terminator
eingeschaltet ist. Ich habe schon Laufwerke gesehen, da musste man statt
wie uebelich abziehen den Jumper setzen um den Terminator abzuschalten.
Um zu pruefen ob der HA TermPower einspeist gibt es zwei Moeglichkeiten:
a)
Stecke auf die externe Buchse einen Terminator mit Power-LED dran. Wenn
die leuchtet ist TermPower vorhanden.
b)
Messe mit einem Multimeter die Spannung am TermPower Pin, da muessen 5V
anliegen. Pinbelegung:
http://www.connectworld.net/cables/scsifaq.html#32
An Pin 26 der internen 50Pin Buchse kommt man vmtl. am besten ran.
Micha
*) Die ist heutzutage normalerweise selbstrueckstellend beim Ausschalten
Georges Heinesch
> ...
> Jein. Was er braucht wie jedes andere SCSI device ist korrekte
> Terminierung und die Terminatoren brauchen Energie (TermPower). Das
> Installation manual zeigt wie der ASC-19160 funktioniert:
> http://www.adaptec.com/en-US/support/scsi/u160/ASC-19160/
>
> Auf Seite 2 (bzw. 4) gibt es ein Bild wo man sieht, dass eine AIC3860
> Bridge verwendet wird. Auf dem HA gibt es elektrisch also zwei Busse und
> er benoetigt daher 4 Terminatoren, einen an jedem Ende jedes Busses. Da
> du den internen 50Pin Stecker nicht verwendest haben beide Busse ein
> Ende auf dem HA, dort muessen also beide Terminatoren enabled sein.
> Beide manuell auf "enable" zu stellen hast du ja bereits probiert, d.h.
> daran liegt es nicht. Die beiden anderen Enden der zwei Busse hast du
> ebenfalls terminiert, d.h. dein Aufbau sollte korrekt sein.
Ok.
Der LVD Bus wird an einen internen 68 poligen Stecker geführt. Somit
muss er auf dem HA und am Ende des SCSI Kabels terminiert werden. Um
Letzteres muss sich der User selbst kümmern (Terminierung am Ende des 68
poligen Kabels). Wieso stellt das BIOS die Möglichkeit zur Verfügung für
den LVD Bus die Terminierung auf dem HA ein- und auszuschalten, wenn
diese ja immer eingeschaltet sein muss da ja es ja immer das Ende des
LVD SCSI Busses ist?
> Dass es nur funktioniert, wenn du die externen devices eingeschaltet
> hast deutet darauf hin, dass diese den SE-Bus mit TermPower versorgen,
> der HA aber nicht. Normal speist der HA TermPower auf beide Busse ein
> (das kann man im Setup nicht beeinflussen), vielleicht tut deiner das
> nicht weil z.B. die Sicherung rausfliegt (*). Das kann passieren wenn du
> mehr als 2 Terminatoren auf dem Bus hast, als erstes solltest du also
> nochmal pruefen, ob in dem externen Gehaeuse wirklich nur ein Terminator
> eingeschaltet ist. Ich habe schon Laufwerke gesehen, da musste man statt
> wie uebelich abziehen den Jumper setzen um den Terminator abzuschalten.
Werde ich machen ... Rückmeldung folgt ...
> Um zu pruefen ob der HA TermPower einspeist gibt es zwei Moeglichkeiten:
> a)
> Stecke auf die externe Buchse einen Terminator mit Power-LED dran. Wenn
> die leuchtet ist TermPower vorhanden.
Habe ich nicht.
> b)
> Messe mit einem Multimeter die Spannung am TermPower Pin, da muessen 5V
> anliegen. Pinbelegung:
> http://www.connectworld.net/cables/scsifaq.html#32
> An Pin 26 der internen 50Pin Buchse kommt man vmtl. am besten ran.
Werde ich auch machen.
Bleibt die Frage, nach der alleinigen Benutzung des LVD Busses. Wie kann
die Abwesenheit von Geräten auf dem SE Bus Fehler auf dem LVD Bus erzeugen?
Gruß,
--
Georges Heinesch
Georges Heinesch
>
> ...
> Dass es nur funktioniert, wenn du die externen devices eingeschaltet
> hast deutet darauf hin, dass diese den SE-Bus mit TermPower versorgen,
> der HA aber nicht. Normal speist der HA TermPower auf beide Busse ein
> (das kann man im Setup nicht beeinflussen), vielleicht tut deiner das
> nicht weil z.B. die Sicherung rausfliegt (*).
Ich habe jetzt die Spannung des HA zwichen Pin 26 (TERM PWR) und 29
(GND) gemessen. 0V. dabei speilt die BIOD Einstellung des Adapters bzgl.
Terminierung keine Rolle (wie du bereits gesagt hast).
Ist es normal dass TERM PWR 0 V hat?
Im externen Gehäuse speisen jetzt die 2 Streamer (C1534A) TERM PWR. die
Jumper sind gesetzt, d.h. TERM PWR wird gespeist (im Manual nachgeschlagen).
Wie kann das denn jetzt sein?
Habe ich falsch gemessen?
Ich benutze den "Centronics" 50 male Stecker an externen Gehäuse.
Gruß,
--
Georges Heinesch
Marcel Müller
Georges Heinesch wrote:
> Ist es normal dass TERM PWR 0 V hat?
Nö. Da sollten sich zwischen 4,5V und 5V tummeln.
> Im externen Gehäuse speisen jetzt die 2 Streamer (C1534A) TERM PWR. die
> Jumper sind gesetzt, d.h. TERM PWR wird gespeist (im Manual nachgeschlagen).
Das ist nicht hinreichend, da es logischerweise nicht geht, wenn sie aus
sind. Der HA muss TERMPWR auch speisen, sonst haben seine eigenen
Terminatoren keinen Strom. Da die Einspeisung normalerweise über
Schottky-Dioden erfolgt, ist es kein Problem, wenn mehr als ein Gerät
die Leitung speist. Da ein Bus ohne HA aber keinen Sinn ergibt, ist es
normalerweise hinreichend, wenn nur die HAs TERMPWR speisen.
Diode auf dem HA gegrillt?
> Wie kann das denn jetzt sein?
>
> Habe ich falsch gemessen?
Messe nochmal, wenn die externen Geräte an sind. Die speisen ja auch.
Wenn dann immer noch nichts kommt, würde ich mir mal Gedanken um das
Messverfahren machen.
> Ich benutze den "Centronics" 50 male Stecker an externen Gehäuse.
Ist eigentlich egal. Aber an den Centronics-Steckern muss man schon
aufpassen, keinen Kurzen zu machen. An den Lötstellen am HA kommt man
i.d.R. auch noch ganz gut dran. ebenfalls bewährt hat es sich, eine
Stecknadel in die Löcher eines handelsüblichen, internen SCSI-Kabels zu
stecken.
Marcel
Michael Baeuerle
>
> Der LVD Bus wird an einen internen 68 poligen Stecker geführt. Somit
> muss er auf dem HA und am Ende des SCSI Kabels terminiert werden.
Aber nur wenn das Kabel am HA endet wie momentan bei dir! Stell dir den
HA vor wie eine Platte oder ein Tape, du kannst auch mehrere davon im
Rechner haben und ein Kabel mit mehreren Steckern daran "vorbeilaufen"
lassen.
> Um
> Letzteres muss sich der User selbst kümmern (Terminierung am Ende des 68
> poligen Kabels). Wieso stellt das BIOS die Möglichkeit zur Verfügung für
> den LVD Bus die Terminierung auf dem HA ein- und auszuschalten, wenn
> diese ja immer eingeschaltet sein muss da ja es ja immer das Ende des
> LVD SCSI Busses ist?
Das muss nicht so sein. Beispiel: Vom Terminator des internen Kabels zu
einem internen Device, dann zum HA, von dort auf ein Slotblech mit einer
externen Buchse und dann zu weiteren externen LVD-Devices und dem
anderen Terminator. Da die externe Onboard-Buchse des ASC-19160 nur SE
unterstuetzt macht sowas sogar praktisch Sinn.
> [...]
> Bleibt die Frage, nach der alleinigen Benutzung des LVD Busses. Wie kann
> die Abwesenheit von Geräten auf dem SE Bus Fehler auf dem LVD Bus erzeugen?
Weil hier alles logisch wie _ein_ Bus funktioniert, d.h. jedes Device
auf der SE-Seite "sieht" jedes Device auf der LVD-Seite und umgekehrt
(ohne dass der AIC7892 dabei etwas tun muss), die Bridge ist quasi
transparent wenn man sich an das Protokoll haelt. Deswegen gibt es auch
nur einen gemeinsamen Adressraum fuer die SCSI-IDs und man darf diese
auf beiden Bussen nicht doppelt vergeben. Diese Konstruktion
unterscheidet sich von einem "Dual channel"-HA wo das erlaubt ist, da
waeren die Busse komplett getrennt und wuerden sich nicht beeinflussen.
Hier sind sie aber nicht unabhaengig sondern die Bridge verbindet sie
bidirektional. Muell auf den Steuerleitungen des SE-Bus hat damit
potentiell auch auf der LVD-Seite Folgen und fuehrt dort evtl. zu
belegtem Bus oder Protokollfehlern.
Szenario 1:
Ist der SE-Bus nicht korrekt terminiert oder fehlt dort TermPower, dann
ist nicht sichergestellt, dass die Bridge den LVD-Bus unbeinflusst
arbeiten laesst. Je nachdem wie intelligent sie ist, zerschiesst sie
nicht unbedingt die Transfers auf dem LVD-Bus (was schnell zu einer
Fehlermeldung fuehren wuerde), sondern belegt nur zwischen ihnen den Bus
und blockiert ihn eine bestimmte Zeit. Dadurch koennte der Durchsatz
soweit einbrechen, dass das Tape um nicht anhalten zu muessen Fuellbytes
schreibt und damit Kapazitaet verschwendet.
=> Interessant waere also, ob dein Tape Fuellbytes verwendet oder bei
Buffer underruns sofort anhaelt.
Szenario 2:
Durch einen Protokollfehler gab es einen Busreset und das Tape hat
dadurch die von dir gemachten Einstellungen zur Kompression vergessen.
Dadurch ist die Kompression evtl. wieder aktiviert worden und es wurde
dadurch Platz verschwendet (ungeeignete Daten koennen durch Kompression
auch _groesser_ werden).
=> Busresets sollten im Logfile des OS stehen.
=> Pruefe mal, ob die Kompression im Tape nach dem Versuch immer noch
aus ist (default ist ja meistens "on").
Micha
Georges Heinesch
> Georges Heinesch wrote:
> ...
>> Ist es normal dass TERM PWR 0 V hat?
> Nö. Da sollten sich zwischen 4,5V und 5V tummeln.
Irrtum meinerseits. ich habe an Pins 26 TERMPWR gemessen. Sollte aber
Pin 38 sein (falscher Stecker).
TERMPWR am Adapter ist 4.91V
TERMPWR am externen Gehäuse 5.12V
Die externen Geräte werden von den HP C1534A Streamers gespeist. Die
beiden CD Laufwerke speisen nicht.
>> Im externen Gehäuse speisen jetzt die 2 Streamer (C1534A) TERM PWR. die
>> Jumper sind gesetzt, d.h. TERM PWR wird gespeist (im Manual
>> nachgeschlagen).
>
> Das ist nicht hinreichend, da es logischerweise nicht geht, wenn sie aus
> sind. Der HA muss TERMPWR auch speisen, sonst haben seine eigenen
> Terminatoren keinen Strom. Da die Einspeisung normalerweise über
> Schottky-Dioden erfolgt, ist es kein Problem, wenn mehr als ein Gerät
> die Leitung speist. Da ein Bus ohne HA aber keinen Sinn ergibt, ist es
> normalerweise hinreichend, wenn nur die HAs TERMPWR speisen.
Ich habe jetzt 2 Speisungen. Ich lasse jetzt HA und externes Gehäuse
speisen, da du ja schreibst dass es nicht schadet (obwohl es auch so
etwas wie Kriechströme gibt). Die externen Geräte sind aber nicht mein
Problem. Die funktionieren ja tadellos.
> Diode auf dem HA gegrillt?
Nein. falscher Pin. Siehe oben ...
Gruß,
--
Georges Heinesch
Georges Heinesch
> Georges Heinesch wrote:
>> Der LVD Bus wird an einen internen 68 poligen Stecker geführt. Somit
>> muss er auf dem HA und am Ende des SCSI Kabels terminiert werden.
>
> Aber nur wenn das Kabel am HA endet wie momentan bei dir! Stell dir den
> HA vor wie eine Platte oder ein Tape, du kannst auch mehrere davon im
> Rechner haben und ein Kabel mit mehreren Steckern daran "vorbeilaufen"
> lassen.
Hast Recht. An diese Möglichkeit habe ich nicht gedacht!
>> [...]
>> Bleibt die Frage, nach der alleinigen Benutzung des LVD Busses. Wie kann
>> die Abwesenheit von Geräten auf dem SE Bus Fehler auf dem LVD Bus erzeugen?
>
> Weil hier alles logisch wie _ein_ Bus funktioniert, d.h. jedes Device
> ...
Sehr interessant!
> Szenario 1:
> Ist der SE-Bus nicht korrekt terminiert oder fehlt dort TermPower, dann
> ist nicht sichergestellt, dass die Bridge den LVD-Bus unbeinflusst
> arbeiten laesst. Je nachdem wie intelligent sie ist, zerschiesst sie
> nicht unbedingt die Transfers auf dem LVD-Bus (was schnell zu einer
> Fehlermeldung fuehren wuerde), sondern belegt nur zwischen ihnen den Bus
> und blockiert ihn eine bestimmte Zeit. Dadurch koennte der Durchsatz
> soweit einbrechen, dass das Tape um nicht anhalten zu muessen Fuellbytes
> schreibt und damit Kapazitaet verschwendet.
Dass eine falsche Terminierung des SE Busses zu fehlern führt, kann ja
nicht der Fall sein da die Fehler auf auftreten wenn überhaupt keine
Geräte am SE Bus hängen (und kein Kabel - siehe OP)! Somit erübrigt sich
die Termninierung ja.
> => Interessant waere also, ob dein Tape Fuellbytes verwendet oder bei
> Buffer underruns sofort anhaelt.
Wäre in der tat interessant. Wie kann ich das herausfinden? Häufiges
Neupositionieren des Bandes (mechanische Geräusche) höre ich jedenfalls
nicht.
> Szenario 2:
> Durch einen Protokollfehler gab es einen Busreset und das Tape hat
> dadurch die von dir gemachten Einstellungen zur Kompression vergessen.
Nein. Ich kann die Kompression auch einschalten und bekomme immer 23.5
GB anstatt 25 GB (ja, weniger!!!).
> Dadurch ist die Kompression evtl. wieder aktiviert worden und es wurde
> dadurch Platz verschwendet (ungeeignete Daten koennen durch Kompression
> auch _groesser_ werden).
Stimmt. Siehe oben. Bei meinen Daten handelt es sich um bereits stark
komprimiertes Video Material.
> => Busresets sollten im Logfile des OS stehen.
??? Wo suche ich da?
> => Pruefe mal, ob die Kompression im Tape nach dem Versuch immer noch
> aus ist (default ist ja meistens "on").
Am C7438A gibt es keine jumper. Die Software (Retrospect) übernimmt das.
Das scheint auch korrekt zu klappen.
Zum Troubleshooting sollte die einfachste Konstellation, in der der
Fehler auftritt, herhalten. Und das ist ... nur das DAT72 am LVD Bus und
kein Gerät am SE Bus. Wieso kommt da ein Fehler!
Gruß,
--
Georges Heinesch
Michael Baeuerle
> Michael Baeuerle wrote:
> > Georges Heinesch wrote:
> > >
> >
> > Szenario 1:
> > Ist der SE-Bus nicht korrekt terminiert oder fehlt dort TermPower, dann
> > ist nicht sichergestellt, dass die Bridge den LVD-Bus unbeinflusst
> > arbeiten laesst. Je nachdem wie intelligent sie ist, zerschiesst sie
> > nicht unbedingt die Transfers auf dem LVD-Bus (was schnell zu einer
> > Fehlermeldung fuehren wuerde), sondern belegt nur zwischen ihnen den Bus
> > und blockiert ihn eine bestimmte Zeit. Dadurch koennte der Durchsatz
> > soweit einbrechen, dass das Tape um nicht anhalten zu muessen Fuellbytes
> > schreibt und damit Kapazitaet verschwendet.
>
> Dass eine falsche Terminierung des SE Busses zu fehlern führt, kann ja
> nicht der Fall sein da die Fehler auf auftreten wenn überhaupt keine
> Geräte am SE Bus hängen (und kein Kabel - siehe OP)! Somit erübrigt sich
> die Termninierung ja.
Das ist nicht richtig! Bei parallelem SCSI dienen die Terminatoren nicht
nur dazu die Signale zu absorbieren sondern stellen auch den Ruhepegel
(Zustand inaktiv) aller Signale her wenn der Bus nicht belegt ist. Auf
dem SE-Bus haengt hier immer mindestens die Bridge - und diese
funktioniert nicht korrekt wenn einer der Busse nicht terminiert ist
bzw. diesem TermPower fehlt. Nimm als Beispiel den Fall einer Platte auf
dem SE-Bus die nach einem Disconnect die Verbindung mit dem Host
wiederherstellen will:
Die Platte weiss nichts von der Bridge, d.h. sie macht alles wie
ueblich: Als erstes wartet sie bis der SE-Bus frei ist, belegt ihn und
macht eine Arbitration. Wenn sie diese gewinnt muss sie den Host
reselektieren, dazu legt sie SEL, I/O, ihre eigene ID und die ID des
AIC7892 auf den Bus. Damit der AIC7892 mitkriegt dass er reselektiert
werden soll und von wem, muss die Bridge also schonmal mindestens diese
4 Signale auch auf dem LVD-Bus treiben. Der Rest ist mal egal - ich
denke schon hier wird klar, dass wenn bestimmte Leitungen auf dem SE-Bus
ungewuenscht aktiv werden (z.B. weil sie nicht terminiert sind)
ungewuenschte Effekte auch auf dem LVD-Bus passieren koennen.
> > => Interessant waere also, ob dein Tape Fuellbytes verwendet oder bei
> > Buffer underruns sofort anhaelt.
>
> Wäre in der tat interessant. Wie kann ich das herausfinden? Häufiges
> Neupositionieren des Bandes (mechanische Geräusche) höre ich jedenfalls
> nicht.
Ob Fuellbytes verwendet werden steht hoechstens im Manual. Ich dachte
"vielleicht hast du eins und es steht ausnahmsweise nicht nur Blabla
drin" ...
> > Szenario 2:
> > Durch einen Protokollfehler gab es einen Busreset und das Tape hat
> > dadurch die von dir gemachten Einstellungen zur Kompression vergessen.
>
> Nein. Ich kann die Kompression auch einschalten und bekomme immer 23.5
> GB anstatt 25 GB (ja, weniger!!!).
>
> > Dadurch ist die Kompression evtl. wieder aktiviert worden und es wurde
> > dadurch Platz verschwendet (ungeeignete Daten koennen durch Kompression
> > auch _groesser_ werden).
>
> Stimmt. Siehe oben. Bei meinen Daten handelt es sich um bereits stark
> komprimiertes Video Material.
OK, dann liegt es offenbar auch nicht an einem Kompressionsproblem.
> > => Busresets sollten im Logfile des OS stehen.
>
> ??? Wo suche ich da?
Kommt auf das OS an. Bei einem Unix gibt es ueblicherweise Logfiles in
'/var/log' wo dann sowas in der Art drinstehen wuerde:
------------------------------------------------------
kernel: sym0:6:0: ABORT operation started.
kernel: sym0:6:0: ABORT operation timed-out.
kernel: sym0:6:0: DEVICE RESET operation started.
kernel: sym0:6:0: DEVICE RESET operation timed-out.
kernel: sym0:6:0: BUS RESET operation started.
kernel: sym0: SCSI BUS reset detected.
kernel: sym0: SCSI BUS has been reset.
kernel: sym0:6:0: BUS RESET operation complete.
------------------------------------------------------
Windows kenne ich nicht naeher. Bei WindowsNT gabs doch frueher den
"Event viewer" oder so aehnlich ...
> > => Pruefe mal, ob die Kompression im Tape nach dem Versuch immer noch
> > aus ist (default ist ja meistens "on").
>
> Am C7438A gibt es keine jumper. Die Software (Retrospect) übernimmt das.
> Das scheint auch korrekt zu klappen.
>
> Zum Troubleshooting sollte die einfachste Konstellation, in der der
> Fehler auftritt, herhalten. Und das ist ... nur das DAT72 am LVD Bus und
> kein Gerät am SE Bus. Wieso kommt da ein Fehler!
S.o., du brauchst TermPower und Terminatoren auch auf dem SE-Bus damit
der LVD-Bus wie gewuenscht funktioniert. TermPower und der eine
Onboard-Terminator sind allerdings ausreichend um ohne Kabel die wenige
Zentimeter kurzen Leiterbahnen inaktiv zu halten wenn die Bridge sie
nicht treibt.
Im anderen Posting schreibst du, dass TermPower OK ist ... d.h. weil
auch der Onboard-Terminator an ist liegt kein Terminierungsproblem auf
dem SE-Bus vor.
Irgendwie sieht das fuer mich nicht mehr nach einem Hardwareproblem aus
...
Micha
Georges Heinesch
> Georges Heinesch wrote:
> ...
> Das ist nicht richtig! Bei parallelem SCSI dienen die Terminatoren nicht
> nur dazu die Signale zu absorbieren sondern stellen auch den Ruhepegel
> (Zustand inaktiv) aller Signale her wenn der Bus nicht belegt ist. Auf
> dem SE-Bus haengt hier immer mindestens die Bridge - und diese
> funktioniert nicht korrekt wenn einer der Busse nicht terminiert ist
> bzw. diesem TermPower fehlt. Nimm als Beispiel den Fall einer Platte auf
> dem SE-Bus die nach einem Disconnect die Verbindung mit dem Host
> wiederherstellen will:
> Die Platte weiss nichts von der Bridge, d.h. sie macht alles wie
> ueblich: Als erstes wartet sie bis der SE-Bus frei ist, belegt ihn und
> macht eine Arbitration. Wenn sie diese gewinnt muss sie den Host
> reselektieren, dazu legt sie SEL, I/O, ihre eigene ID und die ID des
> AIC7892 auf den Bus. Damit der AIC7892 mitkriegt dass er reselektiert
> werden soll und von wem, muss die Bridge also schonmal mindestens diese
> 4 Signale auch auf dem LVD-Bus treiben. Der Rest ist mal egal - ich
> denke schon hier wird klar, dass wenn bestimmte Leitungen auf dem SE-Bus
> ungewuenscht aktiv werden (z.B. weil sie nicht terminiert sind)
> ungewuenschte Effekte auch auf dem LVD-Bus passieren koennen.
Das ist wieder sehr interessant!
Allerdings ist onboard ja terminiert (mittels der BIOS Einstellung).
Oder muss ich etwa auch noch über diese kurze Distanz (einige cm
Leiterbahnen auf der Platine) einen zweiten Terminator auf dem SE Bus
benutzen? Wenn ja, am internen Stecker oder externen?
BTW ... wenn ich die externen Geräte angeschlossen habe (egal ob ein
oder ausgeschaltet), dann ist dieser SE ja an diesem Ende terminiert da
ich einen Terminator am Ende des Kabels benutze und TERMPWR saft hat.
Trotzdem treten die Fehler auf.
>>> => Interessant waere also, ob dein Tape Fuellbytes verwendet oder bei
>>> Buffer underruns sofort anhaelt.
>> Wäre in der tat interessant. Wie kann ich das herausfinden? Häufiges
>> Neupositionieren des Bandes (mechanische Geräusche) höre ich jedenfalls
>> nicht.
>
> Ob Fuellbytes verwendet werden steht hoechstens im Manual. Ich dachte
> "vielleicht hast du eins und es steht ausnahmsweise nicht nur Blabla
> drin" ...
Dort steht nur das nackte Minimum. Montage, Installation, Jumper. Gibt
es Software wo ich den tape Stream auslesen kann? Da könnte ich
nachträglich ermitteln ob alles mit Null vollgeschrieben wurde oder nicht.
>>> => Busresets sollten im Logfile des OS stehen.
>> ??? Wo suche ich da?
>
> Kommt auf das OS an. Bei einem Unix gibt es ueblicherweise Logfiles in
> '/var/log' wo dann sowas in der Art drinstehen wuerde:
> ------------------------------------------------------
> kernel: sym0:6:0: ABORT operation started.
> kernel: sym0:6:0: ABORT operation timed-out.
> kernel: sym0:6:0: DEVICE RESET operation started.
> kernel: sym0:6:0: DEVICE RESET operation timed-out.
> kernel: sym0:6:0: BUS RESET operation started.
> kernel: sym0: SCSI BUS reset detected.
> kernel: sym0: SCSI BUS has been reset.
> kernel: sym0:6:0: BUS RESET operation complete.
> ------------------------------------------------------
> Windows kenne ich nicht naeher. Bei WindowsNT gabs doch frueher den
> "Event viewer" oder so aehnlich ...
Den gibt es. ich habe ihn 'mal gelöscht und mache einen weiteren
Durchlauf. Vielleicht findet sich etwas ...
>> Zum Troubleshooting sollte die einfachste Konstellation, in der der
>> Fehler auftritt, herhalten. Und das ist ... nur das DAT72 am LVD Bus und
>> kein Gerät am SE Bus. Wieso kommt da ein Fehler!
>
> S.o., du brauchst TermPower und Terminatoren auch auf dem SE-Bus damit
> der LVD-Bus wie gewuenscht funktioniert. TermPower und der eine
> Onboard-Terminator sind allerdings ausreichend um ohne Kabel die wenige
> Zentimeter kurzen Leiterbahnen inaktiv zu halten wenn die Bridge sie
> nicht treibt.
Ah ... damit wäre die Frage bereits beantwortet.
> Im anderen Posting schreibst du, dass TermPower OK ist ... d.h. weil
> auch der Onboard-Terminator an ist liegt kein Terminierungsproblem auf
> dem SE-Bus vor.
>
> Irgendwie sieht das fuer mich nicht mehr nach einem Hardwareproblem aus
> ...
Das habe ich befürchtet. Wo soll ich da bloß anfangen zu suchen ... ?!?!
Man kann sich jetzt auch noch eine andere Frage stellen ... bisher war
die frage immer "warum geht es nicht wenn ..." ... 'mal andersherum ...
"warum geht es wenn die externen Geräte eingeschaltet sind?)
Noch etwas ... kann es sein dass die onboard Terminatoren nicht korrekt
funktionieren?
Gruß,
--
Georges Heinesch
Michael Baeuerle
> Michael Baeuerle wrote:
> >
> BTW ... wenn ich die externen Geräte angeschlossen habe (egal ob ein
> oder ausgeschaltet), dann ist dieser SE ja an diesem Ende terminiert da
> ich einen Terminator am Ende des Kabels benutze und TERMPWR saft hat.
So ist es. Die TermPower Leitung geht durch den ganzen Bus, d.h. der
externe Terminator wird vom HA versorgt wenn du das externe Gehaeuse
abschaltest. Aufpassen muss man da nur bei Onboard-Terminatoren. Alte
Seagate Platten haben z.B. einen Jumper der festlegt ob die Platte
TermPower in den Bus einspeisen soll oder nicht und einen weitere mit
dem man einstellen kann ob der Onboard-Terminator aus dem lokalen Supply
oder dem Bus (TermPower) versorgt werden soll.
> Trotzdem treten die Fehler auf.
Du hast sichergestellt, dass TermPower und 2 Terminatoren (durch
manuelles Einschalten des HA-Onboard-Terminators und den Terminator im
ausgeschalteten externen Gehaeuse) vorhanden sind. Ich bin daher der
Meinung, dass die Terminierung des SE-Bus als Ursache ausgeschlossen
werden kann.
> > [...]
> > Ob Fuellbytes verwendet werden steht hoechstens im Manual. Ich dachte
> > "vielleicht hast du eins und es steht ausnahmsweise nicht nur Blabla
> > drin" ...
>
> Dort steht nur das nackte Minimum. Montage, Installation, Jumper.
War ja klar. Ich erinnere mich an Zeiten, da wurden Consumer-Geraete wie
Radios noch mit Schaltplaenen ausgeliefert ... aber seit man selbst den
Fortschrittsbalken patentieren kann ist sowas natuerlich zu riskant
geworden :-(
> Gibt
> es Software wo ich den tape Stream auslesen kann? Da könnte ich
> nachträglich ermitteln ob alles mit Null vollgeschrieben wurde oder nicht.
Wenn, dann macht das Tape das alles intern. Die potentiellen Fuellbytes
wuerden das Interface nie erreichen, daher kann sie auch keine Software
auf dem Host "sehen".
> > [...]
> > Irgendwie sieht das fuer mich nicht mehr nach einem Hardwareproblem aus
> > ...
>
> Das habe ich befürchtet. Wo soll ich da bloß anfangen zu suchen ... ?!?!
Man koennte es mal mit einem anderen OS versuchen, z.B. mit einer
Linux-Live-DVD (Knoppix oder sowas in der Art). Die Frage ist, ob die
den SCSI-HA an den Start kriegt (Treiber dafuer drauf hat). Falls ja,
kann man damit Tapes mit den 08/15 Unix-Tools 'mt' und 'tar' testen (die
werden vmtl. drauf sein), man braeucht zumindest keine spezielle
Backupsoftware. Kosten wuerde der Versuch ja nichts ...
Damit koennte man ausschliessen, dass irgendwelche Seiteneffekte der Art
"OS-Laufwerksbezeichner werden anders vergeben wenn weitere Tapes
anwesend sind" deine Backupsoftware dazu verleiten irgendwas anders zu
machen.
> Man kann sich jetzt auch noch eine andere Frage stellen ... bisher war
> die frage immer "warum geht es nicht wenn ..." ... 'mal andersherum ...
> "warum geht es wenn die externen Geräte eingeschaltet sind?)
Abgesehen von (ansonsten fehlendem) TermPower der nur von den externen
Geraeten eingespeist werden wuerde faellt mir kein Grund ein. Das hast
du aber bereits gemessen, dass das bei dir nicht der Fall ist.
> Noch etwas ... kann es sein dass die onboard Terminatoren nicht korrekt
> funktionieren?
Nichts ist unmoeglich, aber Terminatoren sind eigentlich weitgehend
unkaputtbar.
Speziell auf dem SE-Bus halte ich das auch fuer unwahrscheinlich weil es
ja funktioniert hat wenn die externen Geraete _eingeschaltet_ waren. Ich
gehe mal davon aus, dass du die externen Geraete auch getestet/benutzt
hast und diese funktioniert haben. Ein Fast20 "Ultra" SE-Bus mit 5
Geraeten drauf wie bei dir darf maximal 1.5m lang sein und ist speziell
bei externen Kabeln sehr anspruchsvoll, der wuerde mit nur einem
Terminator kaum brauchbar funktionieren.
Micha
Georges Heinesch
> Georges Heinesch wrote:
>> Trotzdem treten die Fehler auf.
>
> Du hast sichergestellt, dass TermPower und 2 Terminatoren (durch
> manuelles Einschalten des HA-Onboard-Terminators und den Terminator im
> ausgeschalteten externen Gehaeuse) vorhanden sind. Ich bin daher der
> Meinung, dass die Terminierung des SE-Bus als Ursache ausgeschlossen
> werden kann.
Als bestätigung gilt ja mehr oder weniger, dass wenn ich nichts am SE
Bus angeschlossen habe, es trotzdem nicht korrekt funktioniert.
>> Man kann sich jetzt auch noch eine andere Frage stellen ... bisher war
>> die frage immer "warum geht es nicht wenn ..." ... 'mal andersherum ...
>> "warum geht es wenn die externen Geräte eingeschaltet sind?)
>
> Abgesehen von (ansonsten fehlendem) TermPower der nur von den externen
> Geraeten eingespeist werden wuerde faellt mir kein Grund ein. Das hast
> du aber bereits gemessen, dass das bei dir nicht der Fall ist.
Kann es nicht sein, dass die 5.12 V der externen Geräte Quelle den
Unterschied machen? das ist der einzige unterschied den ich sehe. Ich
schalte die externen Geräte ein und TERMPWR steigt von 4.91 (vom HA) auf
5.12V. kann es nicht sein, dass dieser Spannungsanstieg den Terminator
am LVD Bus erst korrekt arbeiten läßt?
BTW ... TERMPWR wird ja vom SE zum LVD Bus durchgeschleift, oder?
Gruß,
--
Georges Heinesch
Georges Heinesch
>
> ...
> Das Problem besteht jetzt darin, dass wenn ich ein Backup auf das DAT72
> Laufwerk (internes Gerät) mache, ich maximal 25 GB auf das Band bekomme
> (native 36 GB) wenn die externen Geräte ausgeschaltet sind (SCSI Kabel
> noch immer angeschlossen). Wenn ich jetzt die externen Geräte
> einschalte, bekomme ich 33.5 GB auf das Band (die gleichen Daten!).
> Diese Werte beziehen sich auf Hardware und Software Kompression
> ausgeschaltet! 33.5 GB halte ich normal, wenn man von 2.5 GB Overhead
> ausgeht.
Muss hier noch einmal fragen ...
Sind diese Werte normal (hardware und sofware compression
ausgeschaltet)? Backup Software Retrospect 7.5.
DDS 12 GB native: 11.1 GB
DAT72 36 GB native: 33.5 GB
Gruß,
--
Georges Heinesch
Michael Baeuerle
> Michael Baeuerle wrote:
> > Georges Heinesch wrote:
> > >
> > > Man kann sich jetzt auch noch eine andere Frage stellen ... bisher war
> > > die frage immer "warum geht es nicht wenn ..." ... 'mal andersherum ...
> > > "warum geht es wenn die externen Geräte eingeschaltet sind?)
> >
> > Abgesehen von (ansonsten fehlendem) TermPower der nur von den externen
> > Geraeten eingespeist werden wuerde faellt mir kein Grund ein. Das hast
> > du aber bereits gemessen, dass das bei dir nicht der Fall ist.
>
> Kann es nicht sein, dass die 5.12 V der externen Geräte Quelle den
> Unterschied machen? das ist der einzige unterschied den ich sehe. Ich
> schalte die externen Geräte ein und TERMPWR steigt von 4.91 (vom HA) auf
> 5.12V. kann es nicht sein, dass dieser Spannungsanstieg den Terminator
> am LVD Bus erst korrekt arbeiten läßt?
Nein, fuer LVD muss TermPower >3V sein, fuer SE >4V. Maximum ist
beidesmal 5.25V (5V+5%). Die Spannung ist also beidesmal absolut im
gruenen Bereich.
> BTW ... TERMPWR wird ja vom SE zum LVD Bus durchgeschleift, oder?
Evtl. ist es so realisiert um Geld zu sparen (es waere streng nach
Wortlaut der Spec auch nicht verboten). Empfohlen ist aber eine
Strombegrenzung von 2A pro Bus. Auf dem HA von einer gemeinsame Quelle
(hier 5V vom PCI) und dann ueber je eine eigene 2A-Sicherung und Diode
auf jeden Bus waere eine "gute" Implementierung.
Micha
Michael Prinzing
>Sind diese Werte normal (hardware und sofware compression
>ausgeschaltet)? Backup Software Retrospect 7.5.
>
>DDS 12 GB native: 11.1 GB
>DAT72 36 GB native: 33.5 GB
Die Werte sind exakt identisch, wenn der eine in GB (1000 Bytes/kB) und
der andere in GiB (1024 Bytes/kB) angegeben ist.
12 GB = 11,1 GiB
36 GB = 33,5 GiB
Michael
Georges Heinesch
12 / 1024 * 1024 = 11.7 != 11.1
36 / 1024 * 1024 = 35.1 != 33.5
Oder habe ich dich jetzt nicht verstanden?
BTW ... die GB 12 GB auf den tapes sind doch 12 * 2^30 = 1.2885^10
Bytes, oder?
Gruß,
--
Georges Heinesch
Georges Heinesch
Ich muss das Ding irgendwie ans Laufen kriegen ...
Ich habe noch ein paar Tests gefahren.
1. Kabel
(SE leer!)
Das 68 polige SCSI Kabel hat 3 Stecker.
1--2--------3
1-2 # 10 cm
2-3 # 50 cm
Bisher ...
1. Terminator
2. Streamer
3. HA
Testweise habe ich folgendes versucht ...
1. HA
2. Streamer
3. HA
Keine Änderung! Immer noch die gleichen niedrigen Werte auf dem Band ;(
2. Mit dem internen Terminator (wie es sein soll) bekomme ich +/- 24.5
GB auf das Band. Ohne den Terminator 26.2 GB. Mehrfache Tests bestätigen
es. Wie ist es möglich, dass ich ohne den vorgeschriebenen Terminator
mehr auf das Band bekomme?
Vieleicht kommt jetzt jemand auf neue Idee'en. Mir gehen sie jedenfalls
so langsam aus.
Ich werde 'mal versuchen den internen Terminator zu wechseln. ich komme
nicht davon los, dass es irgendwie mit der Terminierung / Kabel /
TERMPWR zu tun hat.
Heute Nacht werde ich Knoppix 'mal bemühen.
Gruß,
--
Georges Heinesch
Michael Baeuerle
> Michael Prinzing wrote:
> >
> > Die Werte sind exakt identisch, wenn der eine in GB (1000 Bytes/kB) und
> > der andere in GiB (1024 Bytes/kB) angegeben ist.
> >
> > 12 GB = 11,1 GiB
> > 36 GB = 33,5 GiB
>
> 12 / 1024 * 1024 = 11.7 != 11.1
> 36 / 1024 * 1024 = 35.1 != 33.5
>
> Oder habe ich dich jetzt nicht verstanden?
>
> BTW ... die GB 12 GB auf den tapes sind doch 12 * 2^30 = 1.2885^10
> Bytes, oder?
Ich wuerde jetzt mal davon ausgehen, dass die Kapazitaet der Medien wie
auch bei Festplatten in GByte (10^9) angegeben ist - weil sich das nach
mehr anhoert. Dann waeren das:
12 * 10^9 / 2^30 [Byte] = 11.2GiByte (auf eine Nachkommastelle gerundet)
bzw. 33.5GiByte.
Das erklaert aber natuerlich in keiner Weise warum du andere Werte
bekommst wenn die externen Geraete abgeschaltet sind ...
Micha
Michael Prinzing
>Michael Prinzing wrote:
>> On Mon, 02 Feb 2009 13:22:13 +0100, Georges Heinesch wrote:
>>
>>> Sind diese Werte normal (hardware und sofware compression
>>> ausgeschaltet)? Backup Software Retrospect 7.5.
>>>
>>> DDS 12 GB native: 11.1 GB
>>> DAT72 36 GB native: 33.5 GB
>>
>> Die Werte sind exakt identisch, wenn der eine in GB (1000 Bytes/kB) und
>> der andere in GiB (1024 Bytes/kB) angegeben ist.
>>
>> 12 GB = 11,1 GiB
>> 36 GB = 33,5 GiB
>
>12 / 1024 * 1024 = 11.7 != 11.1
>36 / 1024 * 1024 = 35.1 != 33.5
1024 * 1024 Bytes sind erst ein MiB. 1 GiB = 1024 * 1024 * 1024 Bytes.
36 * 10^9 / 1024^3 = 33,53
>BTW ... die GB 12 GB auf den tapes sind doch 12 * 2^30 = 1.2885^10
>Bytes, oder?
Offenbar nicht. Wenn ich hier ins Log eines DDS3-Tapes (12 GB native)
schaue, dann steht da z.B.:
------------------------------------------------------
Tape capacity log
7081911 KB remaining capacity, partition 0
0 KB remaining capacity, partition 1
11226096 KB maximum capacity, partition 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0 KB maximum capacity, partition 1
------------------------------------------------------
Die Angabe der Kapazität erfolgt also in GB zu 10^9 Bytes.
Michael
Georges Heinesch
> On Tue, 03 Feb 2009 11:55:52 +0100, Georges Heinesch wrote:
>> Michael Prinzing wrote:
>>> On Mon, 02 Feb 2009 13:22:13 +0100, Georges Heinesch wrote:
>>>
>>>> Sind diese Werte normal (hardware und sofware compression
>>>> ausgeschaltet)? Backup Software Retrospect 7.5.
>>>>
>>>> DDS 12 GB native: 11.1 GB
>>>> DAT72 36 GB native: 33.5 GB
>>> Die Werte sind exakt identisch, wenn der eine in GB (1000 Bytes/kB) und
>>> der andere in GiB (1024 Bytes/kB) angegeben ist.
>>>
>>> 12 GB = 11,1 GiB
>>> 36 GB = 33,5 GiB
>> 12 / 1024 * 1024 = 11.7 != 11.1
>> 36 / 1024 * 1024 = 35.1 != 33.5
>
> 1024 * 1024 Bytes sind erst ein MiB. 1 GiB = 1024 * 1024 * 1024 Bytes.
>
> 36 * 10^9 / 1024^3 = 33,53
Stimmt. Ich habe mich total verrechnet ;(
>> BTW ... die GB 12 GB auf den tapes sind doch 12 * 2^30 = 1.2885^10
>> Bytes, oder?
>
> Offenbar nicht. Wenn ich hier ins Log eines DDS3-Tapes (12 GB native)
> schaue, dann steht da z.B.:
>
> ------------------------------------------------------
> Tape capacity log
> 7081911 KB remaining capacity, partition 0
> 0 KB remaining capacity, partition 1
> 11226096 KB maximum capacity, partition 0
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 0 KB maximum capacity, partition 1
> ------------------------------------------------------
>
> Die Angabe der Kapazität erfolgt also in GB zu 10^9 Bytes.
12 * 10^9 wären ja aber 11.718.750 KB, oder irre ich mich wieder?
Gruß,
--
Georges Heinesch
Georges Heinesch
> ...
> Ich werde 'mal versuchen den internen Terminator zu wechseln. ich komme
> nicht davon los, dass es irgendwie mit der Terminierung / Kabel /
> TERMPWR zu tun hat.
Auch mit dem neuen Adapter die gleichen Ergebnisse.
War's also auch nicht ;(
Gruß,
--
Georges Heinesch
Michael Prinzing
Nein, da hast Du recht, da fehlen nochmal ca. 500MB. Wo die bleiben,
kann ich aber selbst nach einem (oberflächlichen) Blick in ECMA-236
nicht sagen. Wenn ich raten müßte, würden mir folgende Möglichkeiten
einfallen (das ist jetzt aber Spekulation!):
1.) Marketinggründe. Auf ein DDS3-Band mit genau 125m passen eben nicht
genau 12GB. Da es aber deutlich mehr als 11GB sind, verkauft man das
ganze als 12GB-System.
2.) Die angegebene Kapazität stellt die Brutto-Kapazität dar, von der
man noch den Platz für Header, Prüfsummen etc. abziehen muß, um den
netto für Daten wirklich zur Verfügung stehenden Platz zu erhalten.
3.) Mein Programm zur Anzeige des Tape-Log rechnet nicht richtig (habe
keinen Quelltext dafür).
Leider ist selbst der DDS3-Standard in dieser Hinsicht nicht ganz
eindeutig. Dort heißt es nur:
"The DDS-3 format, when recorded on a 3,81 mm wide tape the length of
which is 125 metres, will provide a storage capacity of 12 Gigabytes of
uncompressed user data or typically 24 to 36 Gigabytes of compressed
user data."
ohne daß näher ausgeführt wird, was genau mit "Gigabyte" oder "user
data" gemeint ist.
Trotzdem kann man IMO festhalten, daß auf einem 12GB-Band nur Platz für
weniger als 12GiB Daten ist.
Aber nochmal zurück zu Deinem ursprünglichen Problem: hast Du
eigentlich mal die "hp StorageWorks library and tape tools" auf das
System losgelassen? Die gibt es unter
http://www.hp.com/support/tapetools, und man kann damit
- automatisch nach der aktuellen, zum Laufwerk passenden Firmware
suchen und diese einspielen
- einen ca. 20-minütigen "assessment test" machen, der die Funktionen
des Laufwerks durchtestet
- das Fehler-Log des Laufwerks auslesen
- die Datenübertragungsgeschwindigkeit messen, und zwar sowohl beim
Schreiben auf Band als auch bei der Übertragung der Daten nur in den
Puffer des Laufwerks, ohne daß sie auf Band geschrieben werden
und vieles mehr. Vielleicht kommst Du ja ein Stück weiter, wenn Du
einfach alle verfügbaren Tests durchlaufen läßt, mal mit und mal ohne
externe Geräte.
Michael
Georges Heinesch
> Szenario 1:
> Ist der SE-Bus nicht korrekt terminiert oder fehlt dort TermPower, dann
> ist nicht sichergestellt, dass die Bridge den LVD-Bus unbeinflusst
> arbeiten laesst. Je nachdem wie intelligent sie ist, zerschiesst sie
> nicht unbedingt die Transfers auf dem LVD-Bus (was schnell zu einer
> Fehlermeldung fuehren wuerde), sondern belegt nur zwischen ihnen den Bus
> und blockiert ihn eine bestimmte Zeit. Dadurch koennte der Durchsatz
> soweit einbrechen, dass das Tape um nicht anhalten zu muessen Fuellbytes
> schreibt und damit Kapazitaet verschwendet.
> => Interessant waere also, ob dein Tape Fuellbytes verwendet oder bei
> Buffer underruns sofort anhaelt.
Zum Thema Fuellbytes noch folgendes ...
Wenn das Tape Füllbytes benutzen würde, müsste sich das ja in der
Datendurchsatzanzeige der Backupsoftware (Retrospect) wiederspiegeln.
Ist aber nicht so. Ich habe durchgehen 125 MiB und das Backup stoppt
fast immer in der Gegend von 3:30:00 (210 Minuten).
Das wären dann ... 125 MiB * 210 = 25.6 GiB. Das entspricht in etwa der
Anzeige was auf das Band geschrieben wird ehe ein neues band angefordert
wird. Wenn Fuellbytes dazwischen wären, würde sich der datendurchsatz ja
reduzieren. Das ist aber nicht der Fall. Also scheint es kein underrun
zu geben.
Gruß,
--
Georges Heinesch
Georges Heinesch
>
>>> Die Angabe der Kapazität erfolgt also in GB zu 10^9 Bytes.
>> 12 * 10^9 wären ja aber 11.718.750 KB, oder irre ich mich wieder?
>
> Nein, da hast Du recht, da fehlen nochmal ca. 500MB. Wo die bleiben,
> kann ich aber selbst nach einem (oberflächlichen) Blick in ECMA-236
> nicht sagen. Wenn ich raten müßte, würden mir folgende Möglichkeiten
> einfallen (das ist jetzt aber Spekulation!):
>
> 1.) Marketinggründe. Auf ein DDS3-Band mit genau 125m passen eben nicht
> genau 12GB. Da es aber deutlich mehr als 11GB sind, verkauft man das
> ganze als 12GB-System.
Ich bekomme ja 11.1 GiB auf's Band (12.000.000.000 Bytes), also sollte
das nicht der Fall sein.
> 2.) Die angegebene Kapazität stellt die Brutto-Kapazität dar, von der
> man noch den Platz für Header, Prüfsummen etc. abziehen muß, um den
> netto für Daten wirklich zur Verfügung stehenden Platz zu erhalten.
Dito. Es sind ja Nettodaten die ich schreiben kann.
> 3.) Mein Programm zur Anzeige des Tape-Log rechnet nicht richtig (habe
> keinen Quelltext dafür).
Das könnte natürlich sein.
> Trotzdem kann man IMO festhalten, daß auf einem 12GB-Band nur Platz für
> weniger als 12GiB Daten ist.
In diesen Thread wurde bereits über die Kapazität gesprochen. Es sollten
12 GB sein.
> Aber nochmal zurück zu Deinem ursprünglichen Problem: hast Du
> eigentlich mal die "hp StorageWorks library and tape tools" auf das
> System losgelassen? Die gibt es unter
> http://www.hp.com/support/tapetools, und man kann damit
Die neuste Firmware ist drauf.
> - einen ca. 20-minütigen "assessment test" machen, der die Funktionen
> des Laufwerks durchtestet
>
> - das Fehler-Log des Laufwerks auslesen
>
> - die Datenübertragungsgeschwindigkeit messen, und zwar sowohl beim
> Schreiben auf Band als auch bei der Übertragung der Daten nur in den
> Puffer des Laufwerks, ohne daß sie auf Band geschrieben werden
>
> und vieles mehr. Vielleicht kommst Du ja ein Stück weiter, wenn Du
> einfach alle verfügbaren Tests durchlaufen läßt, mal mit und mal ohne
> externe Geräte.
Hier die Tests. Ich habe das ganze 2x gefahren. Einmal mit den externen
Geräten eingeschaltet (wo der Fehler nicht auftrat) und einmal mit den
Geräten ausgeschaltet. Das >Ergebnis war in beiden Fällen das gleiche.
'DDS Drive Assessment Test'- Ok.
'Device Analysis' - Ok.
'Data compression test' - Ok.
'Connectivity Test' - Ok.
'Media Analysis Test' - Ok.
'Read/Write Test' - Ok.
'Device Self Test' - Ok.
HP L&TT Installation Check
InstallCheck done for HP C7438A
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Drive Connectivity Test :
Drive Connectivity test passed.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
System Configuration Test :
HBA Model : Adaptec SCSI Card 19160 - Ultra160 SCSI
Please check www.hp.com/go/connect for HBA compatibility.
This HBA has a dedicated IRQ channel configured.
There is 1 device connected to the HBA.
This drive has a recommended driver installed.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Drive Read/Write Test :
Drive Read/Write test passed.
Write Back data written to device at path
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Drive Performance Test :
Drive Performance test passed.
Drive performance is constrained. Check HBA and cable
configuration. Also try another tape and clean the drive.
Measured native transfer rate is 2MB/S, 33% of the maximum See
www.hp.com/support/pat for more information.
Write Back data written to device at path 3/0.8.0
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
System Performance Test :
System Performance test passed
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
--
Georges Heinesch
Michael Prinzing
>Zum Thema Fuellbytes noch folgendes ...
>
>Wenn das Tape Füllbytes benutzen würde, müsste sich das ja in der
>Datendurchsatzanzeige der Backupsoftware (Retrospect) wiederspiegeln.
>Ist aber nicht so. Ich habe durchgehen 125 MiB und das Backup stoppt
>fast immer in der Gegend von 3:30:00 (210 Minuten).
Nach 3,5h ist ein DAT72-Band vollständig durchgelaufen (170m Bandlänge,
14,03mm/s Bandgeschwindigkeit). Wenn Du nur mit konstant 125MB/min
schreibst, passen in dieser Zeit natürlich nicht mehr als 25GB auf das
Band. Die normale Datenübertragungsrate für DAT72 ohne Kompression
liegt bei ca. 3MB/s oder 180MB/min.
>Das wären dann ... 125 MiB * 210 = 25.6 GiB. Das entspricht in etwa der
>Anzeige was auf das Band geschrieben wird ehe ein neues band angefordert
>wird. Wenn Fuellbytes dazwischen wären, würde sich der datendurchsatz ja
>reduzieren. Das ist aber nicht der Fall. Also scheint es kein underrun
>zu geben.
Dein Datendurchsatz /ist/ reduziert, das meckern die HP LLT laut Deinem
anderen Posting ja auch an. Das kann eigentlich nur daran liegen, daß
a) das Laufwerk die Daten nicht schnell genug erhält und daher wie
schon erwähnt Leerframes schreibt oder
b) das Laufwerk unzählige read-after-write retries macht, also
fehlerhaft geschriebene Frames erneut (hinter den defekten Frame)
schreibt
zu a): Schau mal ins Handbuch, ob Du das Schreiben von Leerframes
abschalten kannst, evtl. kann man das auch mit den HP LLT
konfigurieren. Das Laufwerk müßte dann sofort anhalten, wenn es keine
Daten mehr zum Schreiben hat und kurz darauf wieder anlaufen. Auch wenn
Du auf diese Art und Weise ein Band mit 36GB füllen könntest, würde ich
das Schreiben von Leerframes aber nur zum Testen abschalten, da auf
Dauer die Mechanik sonst doch arg belastet wird.
zu b.): Sollte dies der Fall sein, müßte es eigentlich die Clean-LED
zum Blinken bringen, außerdem wäre mir da der Zusammenhang mit den
externen Geräten nicht so recht klar. Du kannst die Anzahl der Retries
aber mit den HP LLT prüfen:
- Backup machen oder Band einlegen, das sich seit dem letzten Backup
nicht mehr im Laufwerk befand (auch nicht zum Lesen)
- HP LLT starten, Support -> Extract Device Data -> View Support Ticket
- Im Support Ticket: Detailed Device Information -> Tape drive address
x,y,z -> Tape Log -> Current (falls auf das Band soeben ein Backup
gemacht wurde) bzw. previous (wenn das Band seit dem Backup *genau*
einmal aus dem Laufwerk genommen wurde) Values -> Raw-Retries (das Raw
steht nicht für "roh", sondern leicht mißverständlich für
"read-after-write").
Im Normalfall sollte der Wert möglichst nahe bei Null sein. Wenn dies
der Grund für die verminderte Kapazität sein sollte, müßtest Du aber
astronomische Werte (abertausende) vorfinden.
Eine andere Möglichkeit, wie das Band 3,5h durchgehend laufen könnte
und trotzdem nur 25GB geschrieben werden, sehe ich nicht.
Michael
Michael Prinzing
>Hier die Tests. Ich habe das ganze 2x gefahren. Einmal mit den externen
>Geräten eingeschaltet (wo der Fehler nicht auftrat) und einmal mit den
>Geräten ausgeschaltet. Das >Ergebnis war in beiden Fällen das gleiche.
>
>[...]
>Drive Performance Test :
>
>Drive Performance test passed.
> Drive performance is constrained. Check HBA and cable
>configuration. Also try another tape and clean the drive.
>Measured native transfer rate is 2MB/S, 33% of the maximum See
>www.hp.com/support/pat for more information.
>Write Back data written to device at path 3/0.8.0
Genau hier liegt das Problem, und diese Meldung kannst Du nicht
bekommen haben, als 36GB auf's Band gepaßt haben. Die
Datenübertragungsrate für unkomprimierte Daten müßte 3MB/s betragen.
Neben den Vorschlägen aus meinem anderen Posting bleibt eigentlich nur
noch, mal ein anderes internes SCSI-Kabel zu verwenden, evtl. ist ja
der Terminator am Kabelende defekt. Dein Hostadapter sitzt ja
hoffentlich am äußersten Ende des Kabels? Und auf der Seite ohne
Terminator? *duck*
Beim 29160 gibt es im SCSI-BIOS unter SCSI Controller Settings ->
Advanced Configuration den Punkt 'Domain Validation'. Sofern bei Deinem
19160 ebenfalls vorhanden, solltest Du diese einschalten. Der
Hostadapter sollte sich dann bei der Initialisierung melden, falls er
eine fehlerhafte Terminierung festgestellt hat.
Mit den HP LLT kann man auch unkomprimierbare Testdaten schreiben, ohne
daß dazu von der Platte gelesen wird. Das gäbe einen Hinweis darauf, ob
die Daten zu langsam von der Platte gelesen oder zu langsam auf's
Bandlaufwerk geschrieben werden.
Die HP LLT gibt es auch für Linux. Falls Du sie z.B. unter Knoppix zum
Laufen bekommst und damit dieselbe Meldung bekommst, könntest Du ein
Software-Problem (Backup-Programm und Treiber) unter Windows schonmal
ausschließen. Außerdem könntest Du dann prüfen, ob sich etwas ändert,
wenn Du die interne Platte abklemmst, so daß das Bandlaufwerk das
einzige Gerät am Bus ist.
Evtl. lohnt sich auch ein Blick in das Fehler-Log des Laufwerks. Dazu
wie in meinem anderen Posting beschrieben ein Support-Ticket erstellen,
und dann statt "Tape Log" "Fault Log" auswählen. Die einzelnen "Fault
#" durchgehen und jeweils auf das '+' bei "Error Code" klicken.
Michael
Georges Heinesch
> On Sat, 07 Feb 2009 09:40:20 +0100, Georges Heinesch wrote:
>
>> Zum Thema Fuellbytes noch folgendes ...
>>
>> Wenn das Tape Füllbytes benutzen würde, müsste sich das ja in der
>> Datendurchsatzanzeige der Backupsoftware (Retrospect) wiederspiegeln.
>> Ist aber nicht so. Ich habe durchgehen 125 MiB und das Backup stoppt
>> fast immer in der Gegend von 3:30:00 (210 Minuten).
>
> Nach 3,5h ist ein DAT72-Band vollständig durchgelaufen (170m Bandlänge,
> 14,03mm/s Bandgeschwindigkeit).
Das wären 3:21:57 Stunden.
Bei mir sind es etwa 3:25 bis 3:35. Passt also mehr oder weniger.
> Wenn Du nur mit konstant 125MB/min
> schreibst, passen in dieser Zeit natürlich nicht mehr als 25GB auf das
> Band. Die normale Datenübertragungsrate für DAT72 ohne Kompression
> liegt bei ca. 3MB/s oder 180MB/min.
In den 3:21.57 bekäme ich bei 125 MiB/min 26.470 GB auf das Band.
Auch das stimmt!
In Retrospect habe ich allerdings noch NIE Übertragungswerte über 130
MiB/min gesehen! Also stimmt da in der Tat etwas nicht. Allerdings habe
ich auch nicht mehr 130 MiB/min gesehen, als das Backup korrekt
durchgelaufen ist, i.e. wenn die externen geräte eingeschaltet waren und
ich satte 33.5 GB auf das Band schreiben konnte. Hier hat sich die Zeit
dann aber verlängert.
Hier ein Auszug aus dem Log:
---- cut here ----
- 01.02.2009 08:47:25: Copying Storage (F:)
01.02.2009 15:23:19: Execution stopped by operator
Remaining: 14 files, 8,2 GB
Completed: 52 files, 33,4 GB
Performance: 120,1 MB/minute
Duration: 06:35:53 (01:52:07 idle/loading/preparing)
---- cut here ----
Das wären 4:25:26 (120 MiB/min bei 33.4 GB) + idle time (1:52:07)
entspricht das 6:17:33 (also nicht weit weg von 06:35:53).
Hier "Dev Perf" Tests. Ich komme immer nur auf 2 MiB/s.
|__ Device Performance Test Started on Drive (C7438A) (Tape0)
|__ Testing with 2:1 Compression Ratio
|__ Opening Tape Drive Tape0
|__ Rewinding Tape
|__ Writing 1GB of 4GB
|__ Writing 2GB of 4GB
|__ Writing 3GB of 4GB
|__ Writing 4GB of 4GB
|__ 4 GB written in 1994 seconds at 2 MB/s
|__ Rewinding Tape
|__ Closing Tape Drive Tape0
|__ Device Performance Test Started on Drive (C7438A) (Tape0)
|__ Testing with Zeros
|__ Opening Tape Drive Tape0
|__ Rewinding Tape
|__ Writing 1GB of 4GB
|__ Writing 2GB of 4GB
|__ Writing 3GB of 4GB
|__ Writing 4GB of 4GB
|__ 4 GB written in 1984 seconds at 2 MB/s
|__ Rewinding Tape
|__ Closing Tape Drive Tape0
>> Das wären dann ... 125 MiB * 210 = 25.6 GiB. Das entspricht in etwa der
>> Anzeige was auf das Band geschrieben wird ehe ein neues band angefordert
>> wird. Wenn Fuellbytes dazwischen wären, würde sich der datendurchsatz ja
>> reduzieren. Das ist aber nicht der Fall. Also scheint es kein underrun
>> zu geben.
>
> Dein Datendurchsatz /ist/ reduziert, das meckern die HP LLT laut Deinem
> anderen Posting ja auch an. Das kann eigentlich nur daran liegen, daß
>
> a) das Laufwerk die Daten nicht schnell genug erhält und daher wie
> schon erwähnt Leerframes schreibt oder
>
> b) das Laufwerk unzählige read-after-write retries macht, also
> fehlerhaft geschriebene Frames erneut (hinter den defekten Frame)
> schreibt
Das würde man ja durch mechanische Positionierungsgeräusche hören
(oder?). Wenn ja, dann ist das aber nicht so. Man hört etwa alle 15
Minuten dass das Laufwerk repositioniert (wenn es das Geräusch ist?),
aber dann ist wieder Ruhe. Es ist jedenfalls nicht übermässig oft.
> zu a): Schau mal ins Handbuch, ob Du das Schreiben von Leerframes
> abschalten kannst, evtl. kann man das auch mit den HP LLT
> konfigurieren. Das Laufwerk müßte dann sofort anhalten, wenn es keine
> Daten mehr zum Schreiben hat und kurz darauf wieder anlaufen. Auch wenn
> Du auf diese Art und Weise ein Band mit 36GB füllen könntest, würde ich
> das Schreiben von Leerframes aber nur zum Testen abschalten, da auf
> Dauer die Mechanik sonst doch arg belastet wird.
Klingt plausibel, ist IMHO aber nicht machbar. In HP L&TT habe ich keien
Einstellung gefunden, das Handbuch kannst du vergessen und im Internet
war auch nichts aufzutreiben.
> zu b.): Sollte dies der Fall sein, müßte es eigentlich die Clean-LED
> zum Blinken bringen, außerdem wäre mir da der Zusammenhang mit den
> externen Geräten nicht so recht klar.
Ja, mir auch nicht.
Die Clean-LED hat AFAIK bisher in einem Jahr nur etwa 2x geflshed. Ich
putze aber öfters ... etwa nach jedem zehnten Tape Durchgang.
> Du kannst die Anzahl der Retries
> aber mit den HP LLT prüfen:
>
> - Backup machen oder Band einlegen, das sich seit dem letzten Backup
> nicht mehr im Laufwerk befand (auch nicht zum Lesen)
>
> - HP LLT starten, Support -> Extract Device Data -> View Support Ticket
>
> - Im Support Ticket: Detailed Device Information -> Tape drive address
> x,y,z -> Tape Log -> Current (falls auf das Band soeben ein Backup
> gemacht wurde) bzw. previous (wenn das Band seit dem Backup *genau*
> einmal aus dem Laufwerk genommen wurde) Values -> Raw-Retries (das Raw
> steht nicht für "roh", sondern leicht mißverständlich für
> "read-after-write").
>
> Im Normalfall sollte der Wert möglichst nahe bei Null sein. Wenn dies
> der Grund für die verminderte Kapazität sein sollte, müßtest Du aber
> astronomische Werte (abertausende) vorfinden.
Hier jetzt das Tape Log nach einem erfolgreichen Backup (= wo die
externen Geräte eingeschaltet waren).
|__ Tape Log
||__ Number of Cartridge Loads :1
||__ Total Values
| ||__ Total Groups Written :108941
| ||__ Total Groups Read :55575
| ||__ Total Raw Retries :74
| ||__ Total ECC Retries :1
||__ Current Values
| ||__ Total Groups Written :55557
| ||__ Total Groups Read :55575
| ||__ Total Raw Retries :34
| ||__ Total ECC Retries :1
||__ Previous Values
||__ Total Groups Written :53384
||__ Total Groups Read :0
||__ Total Raw Retries :40
||__ Total ECC Retries :0
---- cut here ----
- 08.02.2009 22:26:13: Copying Tapes on Video (G:)
09.02.2009 02:12:49: Snapshot stored, 117 KB
09.02.2009 02:12:51: Comparing Tapes on Video (G:)
09.02.2009 06:21:32: Execution completed successfully
Completed: 270 files, 26,5 GB
Performance: 114,6 MB/minute (120,2 copy, 109,6 compare)
Duration: 07:55:18 (00:02:56 idle/loading/preparing)
---- cut here ----
Wie das Retrospect Log zeigt, bin ich wieder sehr weit von den 180
MiB/min weg! Trotzdem geht's. Kann doch nicht sein ?!?!
HP L&TT zeigt:
|__ Drive Performance
||__ Drive
||__ Specified max native data rate : 3 MB/sec
||__ Estimated native data rate(last 8 tapes) : 2.5
MB/sec
||__ Write Compression Ratio : 1.0:1
(last 96 GB)
||__ Read Compression Ratio : 1.0:1
(last 52.6 GB)
Hier jetzt ein Tape Log mit ausgeschalteten externen Geräten (wo ich nur
25 GB auf's Band bekomme). Testweise habe ich nur 3 GB auf Band geschrieben:
|__ Tape Log
||__ Number of Cartridge Loads :0
||__ Total Values
| ||__ Total Groups Written :7300
| ||__ Total Groups Read :1894
| ||__ Total Raw Retries :3
| ||__ Total ECC Retries :0
||__ Current Values
| ||__ Total Groups Written :7300
| ||__ Total Groups Read :1894
| ||__ Total Raw Retries :3
| ||__ Total ECC Retries :0
||__ Previous Values
||__ Total Groups Written :0
||__ Total Groups Read :0
||__ Total Raw Retries :0
||__ Total ECC Retries :0
> Eine andere Möglichkeit, wie das Band 3,5h durchgehend laufen könnte
> und trotzdem nur 25GB geschrieben werden, sehe ich nicht.
Um es zusammen zu fassen ... es sind 2 Probleme.
1. Warum habe ich nur 125 MB/s.
2. Warum ist bei 25 GB Schluss wenn ich externe Geräte dran hängen habe?
Scheinbar gibt es ja keine Fehler und trotzdem geht's nicht ?!?!
Gruß,
--
Georges Heinesch
Georges Heinesch
> - HP LLT starten, Support -> Extract Device Data -> View Support Ticket
Ich habe jetzt weitere Tests mit HP L&TT gemacht. es ist einfach
unglaublich, aber bei abgeschalteten externen Geräten denkt der Streamer
einfach das band sei nach 25 GB voll, obwohl da noch was kommt. Ich habe
auch den jeweiligen Support Ticket beider unterstehender Tests
gespeichert. Ich will sie nicht posten da sie zu land sind. Allerdings
fiel mir nichts Merkwürdiges auf!
Der erste Test ist mit den externen Geräten ausgeschaltet. Der zweite
Test ist mit den Geräten eingeschaltet.
---- cut here ----
|__ Device Performance Test Started on Drive (C7438A) (Tape0)
||__ Testing with Zeros
||__ Opening Tape Drive Tape0
||__ Rewinding Tape
||__ Writing 1GB of Whole Tape
||__ Writing 2GB of Whole Tape
||__ Writing 3GB of Whole Tape
||__ Writing 4GB of Whole Tape
||__ Writing 5GB of Whole Tape
||__ Writing 6GB of Whole Tape
||__ Writing 7GB of Whole Tape
||__ Writing 8GB of Whole Tape
||__ Writing 9GB of Whole Tape
||__ Writing 10GB of Whole Tape
||__ Writing 11GB of Whole Tape
||__ Writing 12GB of Whole Tape
||__ Writing 13GB of Whole Tape
||__ Writing 14GB of Whole Tape
||__ Writing 15GB of Whole Tape
||__ Writing 16GB of Whole Tape
||__ Writing 17GB of Whole Tape
||__ Writing 18GB of Whole Tape
||__ Writing 19GB of Whole Tape
||__ Writing 20GB of Whole Tape
||__ Writing 21GB of Whole Tape
||__ Writing 22GB of Whole Tape
||__ Writing 23GB of Whole Tape
||__ Writing 24GB of Whole Tape
||__ 25 GB written in 11925 seconds at 2 MB/s
||__ Rewinding Tape
||__ Closing Tape Drive Tape0
---- cut here ----
---- cut here ----
|__ Device Performance Test Started on Drive (C7438A) (Tape2)
||__ Testing with Zeros
||__ Opening Tape Drive Tape2
||__ Rewinding Tape
||__ Writing 1GB of Whole Tape
||__ Writing 2GB of Whole Tape
||__ Writing 3GB of Whole Tape
||__ Writing 4GB of Whole Tape
||__ Writing 5GB of Whole Tape
||__ Writing 6GB of Whole Tape
||__ Writing 7GB of Whole Tape
||__ Writing 8GB of Whole Tape
||__ Writing 9GB of Whole Tape
||__ Writing 10GB of Whole Tape
||__ Writing 11GB of Whole Tape
||__ Writing 12GB of Whole Tape
||__ Writing 13GB of Whole Tape
||__ Writing 14GB of Whole Tape
||__ Writing 15GB of Whole Tape
||__ Writing 16GB of Whole Tape
||__ Writing 17GB of Whole Tape
||__ Writing 18GB of Whole Tape
||__ Writing 19GB of Whole Tape
||__ Writing 20GB of Whole Tape
||__ Writing 21GB of Whole Tape
||__ Writing 22GB of Whole Tape
||__ Writing 23GB of Whole Tape
||__ Writing 24GB of Whole Tape
||__ Writing 25GB of Whole Tape
||__ Writing 26GB of Whole Tape
||__ Writing 27GB of Whole Tape
||__ Writing 28GB of Whole Tape
||__ Writing 29GB of Whole Tape
||__ Writing 30GB of Whole Tape
||__ Writing 31GB of Whole Tape
||__ Writing 32GB of Whole Tape
||__ Writing 33GB of Whole Tape
||__ 34 GB written in 16680 seconds at 2 MB/s
||__ Rewinding Tape
||__ Closing Tape Drive Tape2
---- cut here ----
Wie kann können ausgeschaltete (oder abgezogene) SCSI Geräte dem
Streamer eine fehlerhafte Tape Capacity vorgaukeln?
So langsam glaube ich dass es sich hierbei um einen Bug (Streamer oder
HA) handelt ?!?!
@Michael
Hast du den gleichen Streamer?
Gruß,
--
Georges Heinesch
Michael Prinzing
>Ich habe jetzt weitere Tests mit HP L&TT gemacht. es ist einfach
>unglaublich, aber bei abgeschalteten externen Geräten denkt der Streamer
>einfach das band sei nach 25 GB voll, obwohl da noch was kommt. Ich habe
>auch den jeweiligen Support Ticket beider unterstehender Tests
>gespeichert. Ich will sie nicht posten da sie zu land sind. Allerdings
>fiel mir nichts Merkwürdiges auf!
>
>Der erste Test ist mit den externen Geräten ausgeschaltet. Der zweite
>Test ist mit den Geräten eingeschaltet.
>
>---- cut here ----
>|__ Device Performance Test Started on Drive (C7438A) (Tape0)
> ||__ Testing with Zeros
> ||__ Opening Tape Drive Tape0
> ||__ Rewinding Tape
> ||__ Writing 1GB of Whole Tape
> ||__ Writing 2GB of Whole Tape
[...]
> ||__ Writing 24GB of Whole Tape
> ||__ 25 GB written in 11925 seconds at 2 MB/s
> ||__ Rewinding Tape
> ||__ Closing Tape Drive Tape0
>---- cut here ----
>
>---- cut here ----
>|__ Device Performance Test Started on Drive (C7438A) (Tape2)
> ||__ Testing with Zeros
> ||__ Opening Tape Drive Tape2
> ||__ Rewinding Tape
> ||__ Writing 1GB of Whole Tape
> ||__ Writing 2GB of Whole Tape
[...]
> ||__ Writing 33GB of Whole Tape
> ||__ 34 GB written in 16680 seconds at 2 MB/s
> ||__ Rewinding Tape
> ||__ Closing Tape Drive Tape2
>---- cut here ----
Da fällt auf, daß das zweite Backup über 4,5h gedauert hat. Wenn wir
davon ausgehen, daß das Band eine Laufzeit von ca. 3,3h hat (36GB bei
3MB/s bzw. 170m bei ca. 14mm/s) dann muß der Streamer das Band während
des Backups für mehr als eine Stunde angehalten
haben, weil er die Daten vom PC nicht schnell genug bekommen hat.
Das erste Backup hat hingegen exakt 3,3h gedauert. Sollte das Band auch
hier am Ende gewesen sein, dann wurde es in diesem Fall nicht
angehalten, obwohl der PC die Daten genauso langsam geschickt hat,
sondern es ist ohne Pause kontinuierlich durchgelaufen.
Kannst Du nach dem Backup und vor dem Zurückspulen irgendwie
feststellen, ob das Band wirklich ganz am Ende ist, auch wenn nur 25GB
geschrieben werden konnten?
Ist Dir irgendein Unterschied zwischen den beiden Backups aufgefallen?
Das Anhalten des Bandes hört man nicht unbedingt, wenn die Kopftrommel
weiterläuft, aber zumindest die Aktivitäts-LED müßte kurze Blinkpausen
machen.
>Wie kann können ausgeschaltete (oder abgezogene) SCSI Geräte dem
>Streamer eine fehlerhafte Tape Capacity vorgaukeln?
Ich glaube nicht, daß sie das tun. Der Streamer schreibt halt einfach,
bis er am Bandende angekommen ist. Hat er das Band zwischendurch
angehalten, ist es komplett mit ca. 36GB beschrieben, hat er es nicht
angehalten, obwohl er die Daten zu langsam erhalten hat, enthält es
Leerframes und entsprechend weniger Daten.
Beim ersten Backup (mit 25GB) ist die Datenübertragungsrate mit
2,096MB/s geringfügig höher als beim zweiten mit 36GB und 2,038MB/s.
Mal angenommen, das war jetzt kein einmaliger Zufall, sondern tritt
immer so auf, dann wäre es zumindest denkbar, daß Du damit womöglich
exakt die Grenze der Datenübertragungsrate getroffen hast, unter der
der Streamer das Band anhält bzw. über der er Leerframes schreibt. Das
ist jetzt natürlich Spekulation, aber falls es zutrifft, kannst Du noch
ewig suchen.
Ich würde daher zuerst die Frage klären, wieso Du (unabhängig von den
externen Geräten) nur ca. 2MB/s auf den Streamer bekommst. Kannst Du
diesen Schreibtest ("Testing with Zeros") mal mit eingeschalteter
Kompression machen? Dann müßte die Datenübertragungsrate nahezu dem
entsprechen, was der SCSI-Bus maximal schafft (bei Deinem Streamer
sollten das also knapp 40MB/s sein), und der Streamer müßte deutlich
länger Pause machen als er läuft. Solltest Du auch hier nur auf wenige
MB/s kommen, liegt es mit Sicherheit am SCSI-Bus.
>@Michael
>Hast du den gleichen Streamer?
Leider nein, ich habe hier nur einen C1555D (DDS-3).
Michael
Michael Prinzing
>Michael Prinzing wrote:
>> On Sat, 07 Feb 2009 09:40:20 +0100, Georges Heinesch wrote:
[zu den Backup-Zeiten habe ich in einem zweiten Posting etwas
geschrieben]
>> b) das Laufwerk unzählige read-after-write retries macht, also
>> fehlerhaft geschriebene Frames erneut (hinter den defekten Frame)
>> schreibt
>
>Das würde man ja durch mechanische Positionierungsgeräusche hören
>(oder?).
Nein, das hört man nicht. Defekte Frames werden nicht überschrieben
(wozu man das Band zurücksetzen müßte), sondern der defekte Frame
bleibt auf dem Band, das Band läuft ohne Unterbrechung ganz normal
weiter, und der Frame wird hinter dem defekten Frame einfach nochmal
geschrieben. Du bemerkst das nur durch einen verringerten
Datendurchsatz, eine verringerte Kapazität des Bandes und ggf. durch
das Blinken der Clean-LED.
>Man hört etwa alle 15
>Minuten dass das Laufwerk repositioniert (wenn es das Geräusch ist?),
Das Laufwerk hat eine eingebaute Kopfreinigung. Könnte sein, daß die
alle 15 Minuten aktiv wird.
>> Du kannst die Anzahl der Retries
>> aber mit den HP LLT prüfen:
>>
>Hier jetzt ein Tape Log mit ausgeschalteten externen Geräten (wo ich nur
>25 GB auf's Band bekomme). Testweise habe ich nur 3 GB auf Band geschrieben:
>
>|__ Tape Log
> ||__ Current Values
> | ||__ Total Groups Written :7300
> | ||__ Total Groups Read :1894
> | ||__ Total Raw Retries :3
> | ||__ Total ECC Retries :0
Der Wert für die RAW-Retries ist IMO absolut in Ordnung, auf keinen
Fall aber für einen Kapazitätsverlust von 30% verantwortlich.
Michael
Georges Heinesch
> On Mon, 09 Feb 2009 17:46:41 +0100, Georges Heinesch wrote:
>
> Da fällt auf, daß das zweite Backup über 4,5h gedauert hat. Wenn wir
> davon ausgehen, daß das Band eine Laufzeit von ca. 3,3h hat (36GB bei
> 3MB/s bzw. 170m bei ca. 14mm/s) dann muß der Streamer das Band während
> des Backups für mehr als eine Stunde angehalten
> haben, weil er die Daten vom PC nicht schnell genug bekommen hat.
Ich glaube dass wir hier etwas außer Acht lassen. Die 3 MiB/s sind IMHO
(!)Höchstwerte. Ich glaube (!) dass der Streamer zu anderen
Geschwindigkeiten (z.B. 2 und 1.5 MiB/s) fähig ist. Wann er
herunterschraubt und warum weiß ich allerdings nicht! Logisch wäre ja,
dass wenn die Daten nicht schnell genug herbei kommen, aber das kann bei
meiner Konfiguration einfach nicht der Fall sein, außer ich habe ein
SCSI Problem.
Im Internet habe ich merkwürdigerweise keinen Anhaltspunkt gefunden,
dass der C7438A andere Schreibgeschwindigkeiten beherrscht. Es ist immer
nur von der maximalen Geschwindigkeit von 3 MiB/s die Rede.
Das würde erklären warum 4.7 Stunden für 36 GB benötigt werden.
> Das erste Backup hat hingegen exakt 3,3h gedauert. Sollte das Band auch
> hier am Ende gewesen sein, dann wurde es in diesem Fall nicht
> angehalten, obwohl der PC die Daten genauso langsam geschickt hat,
> sondern es ist ohne Pause kontinuierlich durchgelaufen.
>
> Kannst Du nach dem Backup und vor dem Zurückspulen irgendwie
> feststellen, ob das Band wirklich ganz am Ende ist, auch wenn nur 25GB
> geschrieben werden konnten?
Dies war mir leider nicht möglich. Egal wie ich mich anlegte (Auswurf
durch Software oder Hardware), das Band wurde immer vor dem Auswurf
zurückgespult. Sorry!
> Ist Dir irgendein Unterschied zwischen den beiden Backups aufgefallen?
> Das Anhalten des Bandes hört man nicht unbedingt, wenn die Kopftrommel
> weiterläuft, aber zumindest die Aktivitäts-LED müßte kurze Blinkpausen
> machen.
Nein, nichts. Keine Blinkpausen, kein Unterschied der mechanischen
Geräusche.
>> Wie kann können ausgeschaltete (oder abgezogene) SCSI Geräte dem
>> Streamer eine fehlerhafte Tape Capacity vorgaukeln?
>
> Ich glaube nicht, daß sie das tun. Der Streamer schreibt halt einfach,
> bis er am Bandende angekommen ist. Hat er das Band zwischendurch
> angehalten, ist es komplett mit ca. 36GB beschrieben, hat er es nicht
> angehalten, obwohl er die Daten zu langsam erhalten hat, enthält es
> Leerframes und entsprechend weniger Daten.
>
> Beim ersten Backup (mit 25GB) ist die Datenübertragungsrate mit
> 2,096MB/s geringfügig höher als beim zweiten mit 36GB und 2,038MB/s.
> Mal angenommen, das war jetzt kein einmaliger Zufall, sondern tritt
> immer so auf, dann wäre es zumindest denkbar, daß Du damit womöglich
> exakt die Grenze der Datenübertragungsrate getroffen hast, unter der
> der Streamer das Band anhält bzw. über der er Leerframes schreibt. Das
> ist jetzt natürlich Spekulation, aber falls es zutrifft, kannst Du noch
> ewig suchen.
Siehe oben. Ich glaube inzwischen eher dass der Streamer auf eine
niedrigere geschwindigkeit geschaltet hat. 2 MiB/s!
> Ich würde daher zuerst die Frage klären, wieso Du (unabhängig von den
> externen Geräten) nur ca. 2MB/s auf den Streamer bekommst. Kannst Du
> diesen Schreibtest ("Testing with Zeros") mal mit eingeschalteter
> Kompression machen? Dann müßte die Datenübertragungsrate nahezu dem
> entsprechen, was der SCSI-Bus maximal schafft (bei Deinem Streamer
> sollten das also knapp 40MB/s sein), und der Streamer müßte deutlich
> länger Pause machen als er läuft. Solltest Du auch hier nur auf wenige
> MB/s kommen, liegt es mit Sicherheit am SCSI-Bus.
Ich kann diesen Test leider nicht in der Form machen. ich kann aber
(wenn ich das HP L&TT richtig vverstanden habe) präparierte Daten
schreiben, die sich 1:2 oder 1:4 komprimieren lassen. Auch wenn ich
diese Einstellung benutze, L&TT zeigt mir immer nur maximal 2 MiB/s an.
Ich habe niemals höhere Werte gesehen, weder bei L&TT, noch bei Retrospect.
Gruß,
--
Georges Heinesch
Georges Heinesch
Noch mehr Tests ...
1. Ich habe die SCSI ID testweise von 8 auf 0 gesetzt (am LCD Bus).
Keine Änderung! (war wohl eher ein Verzweifelungstest ;). Bei
abgeschalteten externen Geräten war wieder bei 25 GB Schluss!
2. Ich habe den Streamer, über einen LVD/SE Adapter, an den internen SE
Bus gesteckt. Siehe da ... mit abgeschalteten (bzw. abgezogenen)
externen Geräten konnte ich jetzt auf einmal 36 GB auf's band schreiben,
allerdings nur mit 90 MiB/s. 2 Tests haben in etwa 6:32:00 34.4 GB
geschrieben, entspricht 90 MiB/s. 120 MiB/s habe ich auf dem SE Bus nie
erreicht.
Gruß,
--
Georges Heinesch
Georges Heinesch
>
> ...
>> @Michael
>> Hast du den gleichen Streamer?
>
> Leider nein, ich habe hier nur einen C1555D (DDS-3).
Gibt es jemand hier der den C7438A betreibt?
Wenn ja, was sind die maximalen Schreibraten?
Gruß,
--
Georges Heinesch
Georges Heinesch
>
> ...
>> @Michael
>> Hast du den gleichen Streamer?
>
> Leider nein, ich habe hier nur einen C1555D (DDS-3).
Kannst du mir bitte sagen welchen HA du benutzt?
Was sind die genauen Einstellungen im BIOS des HA?
Gruß,
--
Georges Heinesch
Georges Heinesch
2 weitere Tests ...
Um auszuschliessen, dass es sich beim Fehler um eine Interaktion
zwischen HA (Adaptec ASC-19160) und Rechner (Dell XPS700) handelt, habe
ich den HA in einen Aldi Medion (Sept. 2001) gesteckt. Um es kurz zu
machen ... wieder keine Änderung.
Ich kriege nur 25 GB auf das Band, und die Speed ist entweder 125 MiB/s
am LVD und 90 MiB/s am SE.
Danach habe ich eine uralte Amiga SCSI platte ausgekramt.
Quantum LPS52 (SCSI-1, ASYN).
http://home.arcor.de/r69/amiga/HD-52.html
http://www.cucug.org/amiga/amiinfo/reviews/Squirrel.txt
Diese Platte sollte so in etwa etwas weniger als 1 MiB/s schreiben. War
auch der Fall. h2test hat die Platte auch geprüft. Alles ok (write: 767
KiB/s - read: 1.07 MiB/s). Allerdings war dieser Test eigentlich
überflüssig, da ich die 2 MiB/s (= maximal erreichte 125 MiB/min) des
Streamers übersteigen wollte, um sicher zu sein dass der HA mehr kann
als 2 MiB/s. Es war mir nicht mehr bewusst dass früher die Platten so
(!) langsam waren.
Leider habe ich habe keine schnellere SCSI Platte um das zu testen ;(
Gruß,
--
Georges Heinesch
Frank Schletz
Fall2 bedeutet egal ob an dem anderen Bus Geräte dran sind oder nicht
und egal ob diese an oder aus sind?
Ich denke, wie viele andere auch, dass dies einfach "Störungen"
Reflexionen oder was auch immer auf dem Bus sind. Bei ausgeschalteten
Geräten wirkt da was wie eine "Antenne". Wenn Lösung 2 (einzelnes Kabel)
hilft, dann sollte man das als Lösung nehmen. Ich würde da persönlich nicht
weiter forschen.
Michael Prinzing
>Michael Prinzing wrote:
>>> Hast du den gleichen Streamer?
>>
>> Leider nein, ich habe hier nur einen C1555D (DDS-3).
>
>Kannst du mir bitte sagen welchen HA du benutzt?
>Was sind die genauen Einstellungen im BIOS des HA?
Ich verwende einen Adaptec 29160, BIOS Version 3.10.0
Eingestellt habe ich eigentlich nichts besonderes (ich zähle mal nur
die Einstellungen auf, die für einen Streamer relevant sein könnten):
SCSI Controller ID: 7
SCSI Controller Parity: Enabled
SCSI Controller Termination:
- LVD/SE: Automatic
- SE: Automatic
SCSI DEVICE Configuration (für alle gleich):
- Sync Transfer Rate: 160
- Initiate Wide Negotiation: Yes
- Enable Disconnect: Yes
- Send Start Unit Command: Yes
Advanced Configuration:
- Reset SCSI Bus at IC Initialisation: Enabled
- Post Display Mode: Verbose
- Domain Validation: Enabled
Michael
Michael Prinzing
>Michael Prinzing wrote:
>> Da fällt auf, daß das zweite Backup über 4,5h gedauert hat. Wenn wir
>> davon ausgehen, daß das Band eine Laufzeit von ca. 3,3h hat (36GB bei
>> 3MB/s bzw. 170m bei ca. 14mm/s) dann muß der Streamer das Band während
>> des Backups für mehr als eine Stunde angehalten
>> haben, weil er die Daten vom PC nicht schnell genug bekommen hat.
>
>Ich glaube dass wir hier etwas außer Acht lassen. Die 3 MiB/s sind IMHO
> (!)Höchstwerte. Ich glaube (!) dass der Streamer zu anderen
>Geschwindigkeiten (z.B. 2 und 1.5 MiB/s) fähig ist. Wann er
>herunterschraubt und warum weiß ich allerdings nicht! Logisch wäre ja,
>dass wenn die Daten nicht schnell genug herbei kommen, aber das kann bei
>meiner Konfiguration einfach nicht der Fall sein, außer ich habe ein
>SCSI Problem.
Es gibt Streamer, die die Schreibgeschwindigkeit verringern können. Ob
Dein Modell das auch kann, weiß ich nicht, vielleicht sagt ja HP LLT
was dazu.
Für eine verringerte Schreibgeschwindigkeit ist meines Erachtens aber
eine Verringerung der Drehzahl der Kopftrommel nötig, und eine um 30%
verringerte Drehzahl müßte man eigentlich hören.
>> Kannst Du nach dem Backup und vor dem Zurückspulen irgendwie
>> feststellen, ob das Band wirklich ganz am Ende ist, auch wenn nur 25GB
>> geschrieben werden konnten?
>
>Dies war mir leider nicht möglich. Egal wie ich mich anlegte (Auswurf
>durch Software oder Hardware), das Band wurde immer vor dem Auswurf
>zurückgespult. Sorry!
Daß das Band vor dem Auswerfen zurückgespult wird, ist klar. Ich dachte
auch eher daran, daß Du am Ende des Backups mit einer Taschenlampe
durch die Lüftungsschlitze leuchtest (sofern überhaupt welche vorhanden
sind) oder notfalls, wenn die Garantie bereits abgelaufen ist und das
ohne größere Schäden geht, den Gehäusedeckel abnimmst.
>> Ich würde daher zuerst die Frage klären, wieso Du (unabhängig von den
>> externen Geräten) nur ca. 2MB/s auf den Streamer bekommst. Kannst Du
>> diesen Schreibtest ("Testing with Zeros") mal mit eingeschalteter
>> Kompression machen? Dann müßte die Datenübertragungsrate nahezu dem
>> entsprechen, was der SCSI-Bus maximal schafft (bei Deinem Streamer
>> sollten das also knapp 40MB/s sein), und der Streamer müßte deutlich
>> länger Pause machen als er läuft. Solltest Du auch hier nur auf wenige
>> MB/s kommen, liegt es mit Sicherheit am SCSI-Bus.
>
>Ich kann diesen Test leider nicht in der Form machen.
Hast Du doch bereits gemacht, nur halt mit abgeschalteter
Komprimierung:
--------------------------------------------------------------
|__ Device Performance Test Started on Drive (C7438A) (Tape0)
||__ Testing with Zeros
^^^^^^^^^^^^^^^^^^
||__ Opening Tape Drive Tape0
--------------------------------------------------------------
>ich kann aber
>(wenn ich das HP L&TT richtig vverstanden habe) präparierte Daten
>schreiben, die sich 1:2 oder 1:4 komprimieren lassen.
Genau. Und in diesem Fenster (Test -> Read/Write Test -> Options ->
Compression Ratio) kannst Du auch "Zeroes (max Compression)" auswählen.
Es werden dann nur Nullen auf's Band geschrieben, die sich natürlich
extrem gut komprimieren lassen, so daß der Streamer immer sehr viel
schneller schreibt als der SCSI-Bus die Daten anliefern kann, selbst
wenn das mit den vollen 40MB/s geschieht. Damit kannst Du prüfen, ob a)
der Streamer anhält, wenn er nichts zu schreiben hat und b) wie schnell
der SCSI-Bus maximal arbeitet. Damit wüßte man dann zumindest mal, ob
der Streamer oder der SCSI-Bus für die geringe Übertragungsrate
verantwortlich ist.
Wenn Du den Test allerdings mit abgeschalteter Komprimierung
durchführst, ergibt sich kein Unterschied, egal ob Du Nullen oder nicht
komprimierbare Zufallsdaten schreibst.
Also: den Jumper zum Einschalten der Komprimierung am Streamer passend
setzen, und den Test nochmal machen.
Michael
Michael Prinzing
>Ich denke, wie viele andere auch, dass dies einfach "Störungen"
>Reflexionen oder was auch immer auf dem Bus sind. Bei ausgeschalteten
>Geräten wirkt da was wie eine "Antenne".
Das kann deswegen nicht sein, weil das Problem auch dann auftritt, wenn
gar keine externen Geräte (und auch kein externes Kabel) angeschlossen
sind.
Michael
Frank Schletz
Hm, Kniffelig.
Und interessant zu lesen. Ich lerne viel, mit
dem ich mich normalerweise nicht beschäftigt
hätte, weil es bei den Bandrobotern auf der
Arbeit nicht so wichtig ist, wie viel nun real
drauf passt.
Michael Baeuerle
>
> 2. Ich habe den Streamer, über einen LVD/SE Adapter, an den internen SE
> Bus gesteckt. Siehe da ... mit abgeschalteten (bzw. abgezogenen)
> externen Geräten konnte ich jetzt auf einmal 36 GB auf's band schreiben,
> allerdings nur mit 90 MiB/s. 2 Tests haben in etwa 6:32:00 34.4 GB
> geschrieben, entspricht 90 MiB/s. 120 MiB/s habe ich auf dem SE Bus nie
> erreicht.
90MiB/s, 120MiB/s? Es hiess doch es kann mit maximal 3MByte/s schreiben
(ohne Kompression). Und wenn man hochrechnet wie lange es damit fuer
34.4GByte braucht komme ich auf:
(34.4 * 1k / 3) / 3600 [h] = 3.19h
... also etwa die Hälfte deiner zwei Durchlaeufe. Signifikant schneller
kann es demnach doch gar nicht gehen oder uebersehe ich was weil Montag
morgen ist?
Micha
Georges Heinesch
Ich habe das Problem gefunden! Es waren die WinXP Treiber!
Ich habe Retrospect mit den HP C7438A Treibern erst vor 3 Monaten
installiert und auch getestet. Alles hat damals funktioniert.
Nachträglich habe ich dann die SCSI Hardware Konfiguration geändert,
ging also davon aus, dass sich an der Software nichts geändert hat!
Vor vor 3 tagen dann stellte ich fest, dass keine Adaptec Treiber mehr
für die ASC-19160 installiert waren. Wie das geschehen konnte ... keine
Ahnung!
Ich habe jetzt die letzten Treiber installiert (u160_xp_2000_sp4.exe),
und alles funktioniert!
- Ich bekomme 180 MB/min unkomprimiert.
- Das Backup hört nicht bei 25 GB auf wenn die externen Geräte a.
Es ist mir allerdings ein Rätsel, wie falsche Treiber diese Effekte
produzieren konnten.
Vielen Dank für die Unterstützung!
Gruß,
--
Georges Heinesch
Georges Heinesch
> On Sat, 14 Feb 2009 20:00:52 +0100, Georges Heinesch wrote:
>
>> Michael Prinzing wrote:
>
>>>> Hast du den gleichen Streamer?
>>> Leider nein, ich habe hier nur einen C1555D (DDS-3).
>> Kannst du mir bitte sagen welchen HA du benutzt?
>> Was sind die genauen Einstellungen im BIOS des HA?
>
> Ich verwende einen Adaptec 29160, BIOS Version 3.10.0
>
> Eingestellt habe ich eigentlich nichts besonderes (ich zähle mal nur
> die Einstellungen auf, die für einen Streamer relevant sein könnten):
>
> SCSI Controller ID: 7
Alles identisch hier.
Danke für die Mühe!
Gruß,
--
Georges Heinesch
Georges Heinesch
> Georges Heinesch wrote:
>> Hallo.
>
> ...
> Ich denke, wie viele andere auch, dass dies einfach "Störungen"
> Reflexionen oder was auch immer auf dem Bus sind. Bei ausgeschalteten
> Geräten wirkt da was wie eine "Antenne". Wenn Lösung 2 (einzelnes Kabel)
> hilft, dann sollte man das als Lösung nehmen. Ich würde da persönlich nicht
> weiter forschen.
Siehe anderes Posting. Es waren die WinXP Treiber! Sie waren irgendwann
installiert und kamen irgendwie abhanden. Es ist mir schon fast peinlich
dass es so eine Banalität war.
Kein Hardware Problem also ...
--
Georges Heinesch
Georges Heinesch
> Georges Heinesch wrote:
> ...
> 90MiB/s, 120MiB/s? Es hiess doch es kann mit maximal 3MByte/s schreiben
> (ohne Kompression). Und wenn man hochrechnet wie lange es damit fuer
> 34.4GByte braucht komme ich auf:
> (34.4 * 1k / 3) / 3600 [h] = 3.19h
> ... also etwa die Hälfte deiner zwei Durchlaeufe. Signifikant schneller
> kann es demnach doch gar nicht gehen oder uebersehe ich was weil Montag
> morgen ist?
War ein Type meinerseits!
90MiB/s sollte heissen 90 MiB/min!
120MiB/s sollte heissen 120 MiB/min!
Sorry für die Konfusion!
Gruß,
--
Georges Heinesch
Frank Schletz
> Siehe anderes Posting. Es waren die WinXP Treiber! Sie waren irgendwann
> installiert und kamen irgendwie abhanden. Es ist mir schon fast peinlich
> dass es so eine Banalität war.
>
> Kein Hardware Problem also ...
>
Faszinierend.
Danke für den Bericht. Gut zu wissen, falls ich so was
mal sehe. Benutze ja selber kein Windows, weder privat
noch auf dem Arbeits-Rechner. Höchstens wenn ich Bekannte
supporte oder was für Kunden entwickle.
Georges Heinesch
> On Sat, 14 Feb 2009 18:37:57 +0100, Georges Heinesch wrote:
>
> Es gibt Streamer, die die Schreibgeschwindigkeit verringern können. Ob
> Dein Modell das auch kann, weiß ich nicht, vielleicht sagt ja HP LLT
> was dazu.
Nein. HP L&TT sagt nichts darüber.
> Für eine verringerte Schreibgeschwindigkeit ist meines Erachtens aber
> eine Verringerung der Drehzahl der Kopftrommel nötig, und eine um 30%
> verringerte Drehzahl müßte man eigentlich hören.
War nicht hörbar.
>> Dies war mir leider nicht möglich. Egal wie ich mich anlegte (Auswurf
>> durch Software oder Hardware), das Band wurde immer vor dem Auswurf
>> zurückgespult. Sorry!
>
> Daß das Band vor dem Auswerfen zurückgespult wird, ist klar. Ich dachte
> auch eher daran, daß Du am Ende des Backups mit einer Taschenlampe
> durch die Lüftungsschlitze leuchtest (sofern überhaupt welche vorhanden
> sind) oder notfalls, wenn die Garantie bereits abgelaufen ist und das
> ohne größere Schäden geht, den Gehäusedeckel abnimmst.
Durch die Öffnnung kann man die Bandposition nicht erkennen, und Öffnen
... traue ich mich nicht so recht. Das Ding kostet doch noch richtig Geld ;)
>> ich kann aber
>> (wenn ich das HP L&TT richtig vverstanden habe) präparierte Daten
>> schreiben, die sich 1:2 oder 1:4 komprimieren lassen.
>
> Genau. Und in diesem Fenster (Test -> Read/Write Test -> Options ->
> Compression Ratio) kannst Du auch "Zeroes (max Compression)" auswählen.
> Es werden dann nur Nullen auf's Band geschrieben, die sich natürlich
> extrem gut komprimieren lassen, so daß der Streamer immer sehr viel
> schneller schreibt als der SCSI-Bus die Daten anliefern kann, selbst
> wenn das mit den vollen 40MB/s geschieht. Damit kannst Du prüfen, ob a)
> der Streamer anhält, wenn er nichts zu schreiben hat und b) wie schnell
> der SCSI-Bus maximal arbeitet. Damit wüßte man dann zumindest mal, ob
> der Streamer oder der SCSI-Bus für die geringe Übertragungsrate
> verantwortlich ist.
Stimmt. Hatte ich übersehen ...
---- cut here ----
Read/Write Test:
Transfer rate : 18.9 MB/s during test execution - write
Read/Write Test - PASSED.
---- cut here ----
|__ Test 'Read/Write Test' started on device 'HP C7438A' at address
'3/0.8.0'
|__ Operations Log
| |__ Performing Device Self Test
| |__ Checking for presence of cartridge
| |__ Performing 1st write phase of read/write test
| |__ Rewinding
| |__ Writing data (0/4096 MB)
| |__ Writing data (1/4096 MB)
| |__ Writing data (2/4096 MB)
...
| |__ Writing data (4094/4096 MB)
| |__ Writing data (4096/4096 MB)
| |__ Rewinding
| |__ Test Passed.
|__ Please ensure a test cartridge is loaded into drive at address
3/0.8.0
(CAUTION: any data on cartridge will be lost!)
(CAUTION: Do not press the eject button during the test - this can
cause unexpected results)
Continue with test?
|__ Passed
|__ Analysis Results
---- cut here ----
Sieht gut aus ;))
Fast 20 MB/s ... also 50% des max. Transfer (40 MB/s). Könnte besser
sein, aber ich werde nicht weiter suchen warum es nicht 39.9 MB/s sind.
> Also: den Jumper zum Einschalten der Komprimierung am Streamer passend
> setzen, und den Test nochmal machen.
Der C7438A hat keinen Jumper für Kompression.
Vielen Dank für deine Unterstützung!
Gruß,
--
Georges Heinesch
Georges Heinesch
> Michael Baeuerle wrote:
> ...
> Könntest du mir bitte den Befehl sagen, wie ich Daten auf das Band
> bekomme. Ich werde wahrscheinlich eine Ubuntu 8.10 Live Version benutzen.
Hätte ich das früher hinbekommen, dann wäre mir der fehler mit den WinXP
Treibern gleich aufgefallen.
Ich hänge immer noch hier ...
http://ubuntuforums.org/showthread.php?t=1064986&highlight=tape
Gruß,
--
Georges Heinesch
Michael Baeuerle
> Georges Heinesch wrote:
> >
> > Könntest du mir bitte den Befehl sagen, wie ich Daten auf das Band
> > bekomme. Ich werde wahrscheinlich eine Ubuntu 8.10 Live Version benutzen.
>
> Hätte ich das früher hinbekommen, dann wäre mir der fehler mit den WinXP
> Treibern gleich aufgefallen.
>
> Ich hänge immer noch hier ...
> http://ubuntuforums.org/showthread.php?t=1064986&highlight=tape
'/dev/st0/bigfile.out' kann nicht gehen, 'st0' ist ein sogenanntes
device file und kein Verzeichnis (Windows nennt es "Ordner") wie 'dev'.
Der Status wird angezeigt, d.h. er sieht dein Tape (sonst waere da I/O
error gekommen). Hast du da auch nichts abgeschnitten? Bei mir sieht das
bei einem QIC-150 Tape (DDS an Linux habe ich gerade nicht parat)
naemlich so aus:
----------------------------------------------------------------------
# mt -f /dev/st0 status
drive type = Generic SCSI-1 tape
drive status = 268435968
sense key error = 0
residue count = 0
file number = 0
block number = 0
Tape block size 512 bytes.
^^^^^^^^^^^^^^^^^^^^^^^^^
Density code 0x10 (QIC-150/250 (GCR 10000 bpi)).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN
----------------------------------------------------------------------
Es geht um die markierte Stelle!
Dass die Sache mit 'dd' nicht ging liegt IMHO an einer falschen
Blocksize. Wenn ich hier auf das QIC-150 Tape mit einer nicht
unterstuetzten Blocksize schreibe bekomme ich diesen Fehler:
----------------------------------------------------------------------
# dd if=/dev/zero of=/dev/st0 bs=1000 count=10
dd: /dev/st0: Input/output error
1+0 records in
0+0 records out
----------------------------------------------------------------------
Auf einem anderen Rechner mit QIC-117 Tape gibt es wie bei dir "Invalid
argument":
----------------------------------------------------------------------
# dd if=/dev/zero of=/dev/qft0 bs=1000 count=10
dd: /dev/qft0: Invalid argument
1+0 records in
0+0 records out
----------------------------------------------------------------------
Der Kernel sollte dabei eine Fehlermeldung ausgegeben haben. 'dmesg'
zeigt die letzten Kernelmeldungen an, bei mir ist da z.B. bei dem SCSI
Tape zu lesen:
----------------------------------------------------------------------
# dmesg
...
st: bufsize 32768, wrt 30720, max buffers 4, s/g segs 16.
Detected scsi tape st0 at scsi0, channel 0, id 4, lun 0
st0: Write not multiple of tape block size.
----------------------------------------------------------------------
Schau mal was da bei dir steht ...
Benutze ich eine passende Blocksize (bei meinem SCSI Tape 512Byte, d.h.
ich muss ein Vielfaches davon angeben), dann geht es wie erwartet:
----------------------------------------------------------------------
# dd if=/dev/zero of=/dev/st0 bs=512 count=10
10+0 records in
10+0 records out
# dd if=/dev/zero of=/dev/st0 bs=1024 count=10
10+0 records in
10+0 records out
----------------------------------------------------------------------
Versuche also erstmal rauszufinden ob es einfach daran liegt, dass dein
Tape mit 1kByte Blocks nicht umgehen kann. Wenn 'mt status' das bei dir
nicht anzeigt, probier mal ein Vielfaches einer Zweierpotenz (1KiByte,
10KiByte, dezimale Werte sind unueblich). Gib ggf. so wie ich einfach
mal "count=10" an bis du eine Blocksize hast die unterstuetzt wird und
rechne dann erst den Wert aus der zur gewuenschten Gesamtkapazitaet
fuehrt.
BTW: Die Kompression spielt evtl. auch noch eine Rolle weil die
ebenfalls blockweise arbeitet, d.h. ohne Kompression werden evtl. auch
andere oder kleinere Blocksizes akzeptiert. Wie man die Kompression
abschaltet haengt von deiner Version von 'mt' ab. Probier mal diese
beiden Moeglichkeiten:
----------------------------------------------------------------------
$ sudo mt -f /dev/st0 compression 0
$ sudo mt -f /dev/st0 datcompression 0
----------------------------------------------------------------------
Wenn du die Kompression eingeschaltet laesst kannst du den Test mit den
Nullen vergessen.
PS:
Damit du verstehst was du da machst (da du noch nie ein Unix benutzt
hast wenn ich dich richtig verstanden habe):
Das device file '/dev/st0' ist dein Tape (bei Unix sind alle Laufwerke
durch Dateien repraesentiert), '/dev/zero' liefert Nullen (quasi eine
unendlich grosse Datei voll mit Nullen). Die verwendeten Parameter fuer
das Programm 'dd' haben folgende Bedeutung:
---------------------------
if: Input file
of: Output file
bs: Blocksize
count: Anzahl der Blocks
---------------------------
Dokumentiert ist das in der zugehoerigen Manual page die man so aufruft
(Verlassen mit 'q'):
----------------------------------------------------------------------
$ man dd
----------------------------------------------------------------------
Das 'sudo' am Anfang braucht man nur wenn der Account unter dem man
eingelogged ist nicht genug Rechte hat den darauf folgenden Befehl
auszufuehren (deswegen fehlt es bei meinen Beispielen oben).
Micha
--
http://micha.freeshell.org/
Michael Prinzing
>Michael Prinzing wrote:
>Sieht gut aus ;))
>
>Fast 20 MB/s ... also 50% des max. Transfer (40 MB/s). Könnte besser
>sein, aber ich werde nicht weiter suchen warum es nicht 39.9 MB/s sind.
Auch die knapp 20MB/s sind ein Wert, mit dem man gut leben kann, zumal
Du ja eh vorhast, nur unkomprimierte bzw. unkomprimierbare Daten zu
sichern.
Ich weiß nicht, ob Dein Streamer auf Dauer (d.h. im Durchschnitt über
längere Zeit und nicht nur als kurzzeitigen Spitzenwert) überhaupt mehr
als die knapp 20MB/s schaffen müßte, und da die Ursache auch ganz
woanders liegen kann (Mainboard, PCI-Bus usw.), würde ich hier nur dann
weitersuchen, falls Du bei Deinen Versuchen unter Linux mit derselben
Hardware deutlich höhere Werte (mehr als 30MB/s) erreichst.
Welche Werte zeigt denn das SCSI-BIOS während des POST für den Streamer
in den Spalten "Sync" und "Bus" an?
>> Also: den Jumper zum Einschalten der Komprimierung am Streamer passend
>> setzen, und den Test nochmal machen.
>
>Der C7438A hat keinen Jumper für Kompression.
Hmm, bist Du sicher? Ich habe mir bei HP eine Bedienungsanleitung
besorgt, die u.a. für das "HP StorageWorks DAT 72" gilt (leider ist
keine genaue Typenbezeichnung angegeben), und dieser ist folgendes zu
entnehmen:
Wenn man von hinten auf das Laufwerk schaut, dann befinden sich außen 4
Jumper zum Einstellen der SCSI-ID. Es folgt ein unbenutzer Jumper und
dann ganz links, neben dem SCSI-Anschluß, der normalerweise gesetzte
Jumper, der zum Deaktivieren der Komprimierung entfernt werden kann.
Michael
Michael Prinzing
>Hallo.
>
>Ich habe das Problem gefunden! Es waren die WinXP Treiber!
>
>[...]
>
>Ich habe jetzt die letzten Treiber installiert (u160_xp_2000_sp4.exe),
>und alles funktioniert!
>
>[...]
>
>Es ist mir allerdings ein Rätsel, wie falsche Treiber diese Effekte
>produzieren konnten.
Die wahrscheinliche Ursache findet sich fei Adaptec in der Beschreibung
der aktuellen Treiber. Dort steht:
"These drivers have been developed to overcome speed negation issues
with some devices, like scanners, CDs and CD-Rs, which may default to
the slowest speed (asynchronous) when using the embedded driver in XP
or earlier Windows 2000 drivers. This can then cause buffer under-runs
with some CD Recorders."
Sprich: der bei XP mitgelieferte Treiber handelt bei Geräten, die keine
Festplatte sind, die Übertragungsgeschwindigkeit nicht korrekt aus und
verwendet den langsamsten aller möglichen Modi, was die
"Geschwindigkeit", die Du bisher beobachtet hast, durchaus erklären
kann. Das führt dann auch bei Deinem Streamer zu Buffer-Underruns, da
die Daten langsamer angeliefert werden, als sie der Streamer auf's Band
schreibt. Womit wir wieder bei den Leerframes wären...
Michael