Hallo zusammen,
vielleicht kann mir ja jemand helfen?
Ich versuche mit cdrdao copy --on-the-fly Audiocds direkt zu kopieren.
Ich benutze ein Plextor 40-fach als Leser an adaptec 2940 (device: 1,3,0) und ein Lite-on Schreiber 12-fach mit ide-scsi Emulation (device: 0,0,0)
Wenn ich den Befehl abschicke wird BURN-FREE automatisch aktiviert, allerdings startet der Buffer mit 100% und geht dann kontinuierlich auf 0% runter. Danach erholt er sich maximal bis 30 oder 40 %, geht aber immer wieder auf 0 zurück.
Wenn ich den Wert für Buffer erhöhe verzögert sich nur der Effekt.
Ich habe gesehen, dass eine ähnliche Anfrage bereits gepostet wurde, allerdings lag es da wohl daran, dass Brenner und Leser am selben IDE Bus hingen. Bei mir ist es aber ein SCSI-Leser und ein IDE-Brenner.
Wenn ich von Festplatte eine CD mit cdrdao brenne bleibt der Puffer immer zwischen 80 und 100%
Für mich stellt sich die Frage, ob das ein Fehler oder eine Funktion ist. Vielleicht ist es ja üblich, dass bei der Verwendung von Burnfree und on-the-fly immer erst der Puffer komplett aufgebraucht wird, allerdings kann ich mir das nicht so ganz vorstellen.
Unter Windoof mit Nero klappt on-the-fly kopieren immer problemlos, auch der Lesepuffer bleibt im grünen Bereich. Aber ich möchte mein Windoof endlich platt machen können <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">
Muss ich bei cdrdao irgendwo die Lesegeschwindigkeit für das CD-ROM-Laufwerk einstellen??
Oder mache ich sonst irgend was falsch ??
Sachdienliche Hinweise bitte hier posten oder direkt an mail@celindir.de
Vielen Dank fürs Kopfzerbrechen
Celindir
cdrdao on the fly kopie buffer geht immer auf null
-
Jochen
Re: cdrdao on the fly kopie buffer geht immer auf null
Tja. Ist DMA für den IDE-Brenner vielleicht nicht aktiviert? "hdparm" wäre da das richtige Kommando, nur weiss ich nicht, wie es bei Geräten aussieht, die über ide-scsi-Emu angesprochen werden...
BurnProof soll m.E. nur anspringen, wenn es unbedingt gebraucht wird. Erst Buffer ausnutzen hallte ich für unsinnig.
Auf meinem reinen SCSI-System habe ich nur einmal einen Bufferabfall gehabt, nämlich als ich den SCSI-Bus mittels ein paar Transfers von Festplatte zu Festplatte dichtgemacht hatte. Wenn auch schon beim Brennen eines Images der Buffer auf 80% runterfallen kann, würde ich die Ursache am Brenner bzw. dessen Anschluss/Interface suchen.
Jochen
BurnProof soll m.E. nur anspringen, wenn es unbedingt gebraucht wird. Erst Buffer ausnutzen hallte ich für unsinnig.
Auf meinem reinen SCSI-System habe ich nur einmal einen Bufferabfall gehabt, nämlich als ich den SCSI-Bus mittels ein paar Transfers von Festplatte zu Festplatte dichtgemacht hatte. Wenn auch schon beim Brennen eines Images der Buffer auf 80% runterfallen kann, würde ich die Ursache am Brenner bzw. dessen Anschluss/Interface suchen.
Jochen
-
Celindir
Re: cdrdao on the fly kopie buffer geht immer auf null
hdparm scheint nicht für ide-scsi emu zu funktionieren.
kann man vielleicht erst hdparm und dann die emu ausführen oder gibt es noch eine andere Lösung?
Ratlos
Celindir
kann man vielleicht erst hdparm und dann die emu ausführen oder gibt es noch eine andere Lösung?
Ratlos
Celindir
-
Celindir
Re: cdrdao on the fly kopie buffer geht immer auf null
by the Way
ist ein buffer underrun nicht eher ein Zeichen dafür, dass die Daten nicht rechtzeitig angeliefert werden und nicht dafür, dass der Brenner zu langsam ist??? Macht es dann überhaupt einen Unterschied, ob beim Brenner DMA aktiviert ist? Oder ist es ein Problem vom SCSI-CDROM Laufwerk, das vielleicht nicht mit voller Leistung angesprochen wird?Oder verstehe ich hier etwas falsch?
Kennt jemand ein Tool um die Geschwindigkeit der Laufwerke mal zu testen??
Ist jemand was bekannt, dass beim on-the-fly kopieren irgendwas die Geschwindigkeit des Lesegerätes herabsetzt? (Irgendein Synchronisations-Effekt oder ähnliches)
Immer noch Ratlos
Celnidir
ist ein buffer underrun nicht eher ein Zeichen dafür, dass die Daten nicht rechtzeitig angeliefert werden und nicht dafür, dass der Brenner zu langsam ist??? Macht es dann überhaupt einen Unterschied, ob beim Brenner DMA aktiviert ist? Oder ist es ein Problem vom SCSI-CDROM Laufwerk, das vielleicht nicht mit voller Leistung angesprochen wird?Oder verstehe ich hier etwas falsch?
Kennt jemand ein Tool um die Geschwindigkeit der Laufwerke mal zu testen??
Ist jemand was bekannt, dass beim on-the-fly kopieren irgendwas die Geschwindigkeit des Lesegerätes herabsetzt? (Irgendein Synchronisations-Effekt oder ähnliches)
Immer noch Ratlos
Celnidir
-
BO
Re: cdrdao on the fly kopie buffer geht immer auf null
das mit dem DMA wird es sein. wenn DMA DEaktiv ist, muss die CPU die ganzen Daten schaufeln und kommt dann evtl nicht hinterher.
-
Celindir
Re: cdrdao on the fly kopie buffer geht immer auf null
OK habe verstanden.
Aber wie aktiviere ich den DMA bei einem scsi-emulierten IDE device?
hdparm verweigert logischerweise an /dev/sg0 (oder /dev/cdrecorder oder /dev/scd0 seinen Dienst und /dev/hdc gibt es nach Aktivierung der scsi-emu nicht mehr.
Im Moment habe ich bei mir in der append-Zeile von Lilo hdc=ide-scsi drinstehen.
Muss ich dann hdparm auch in der append Zeile _vor_ ide-scsi eintragen?
Ich kenne bisher nur den Weg über einen boot.local Eintrag!
Vorschläge sind willkommen!!
Danke
Celindir
Aber wie aktiviere ich den DMA bei einem scsi-emulierten IDE device?
hdparm verweigert logischerweise an /dev/sg0 (oder /dev/cdrecorder oder /dev/scd0 seinen Dienst und /dev/hdc gibt es nach Aktivierung der scsi-emu nicht mehr.
Im Moment habe ich bei mir in der append-Zeile von Lilo hdc=ide-scsi drinstehen.
Muss ich dann hdparm auch in der append Zeile _vor_ ide-scsi eintragen?
Ich kenne bisher nur den Weg über einen boot.local Eintrag!
Vorschläge sind willkommen!!
Danke
Celindir
-
Jochen
Re: cdrdao on the fly kopie buffer geht immer auf null
Mangels IDE-Brenner kann ich, fürchte ich, Dir nicht konkret weiterhelfen. Auch wenn Plextor-Leser gut sind beim Grabben, bremst ihn einmal cdrdao, da es die cdparanoia-libs zum Grabben verwendet. Die gehen hin und lesen jeden Sektor mind. zweimal; öfter, wenn die beiden ersten Leseversuche ´sich nicht decken. Weiterhin kann eine schlechte/verkratzte CD den Leser dazu bringen, mit der Geschwindigkeit runterzugehen, was den Datenstrom zusätzlich dünner macht.
Da Du aber schon beim Brennen eines Images von Platte den Buffer manchmal bis 80% runtergehen siehst, würde ich schon den Brenner bzw. den Weg der Daten dorthin als den kritischen Punkt ansehen.
Schau mal mittels "dmesg | less" die Meldungen des System vom Booten an. Dort wird u.a. auch aufgelistet, welche Devices er am IDE-Controller findet und ob er DMA oder PIO dafür verwendet. Sollte dort "pio" bei dem relevanten Device aufgeführt sein, würde ich mangels hdparm-Möglichkeit einen neuen Kernel bauen. Aktiviere
ATA/IDE/MFM/RLL support --> IDE, ATA and ATAPI block devices --> Generic PCI IDE support
dann erscheint die Option "Generic PCI bus-master DMA support". Wird die aktiviert, darfst Du zu guter Letzt auch noch "Use PCI DMA by Default when available" aktivieren. Zum guten Schluss den Kernel bauen, installieren, booten und schauen, ob sich die Werte geändert haben.
Ausserdem ein Hinweis: Sollte DMA aktiviert sein, aber nicht korrekt funktionieren (wg. schlechtem Kabel, schlechter Platte/Chipsatz-Kombination, ...) kann es passieren, dass der Kernel nicht bootet und im allerschlimmsten Fall Datenverlust auf der Platte verursacht. Ich halte das zwar für sehr unwahrscheinlich, aber ich weise Dich lieber darauf hin, bevor Du mich regrespflichtig machen willst <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">. Also vorher ein Backup machen!
Ansonsten viel Spass bei der Bastelei.
Jochen
Da Du aber schon beim Brennen eines Images von Platte den Buffer manchmal bis 80% runtergehen siehst, würde ich schon den Brenner bzw. den Weg der Daten dorthin als den kritischen Punkt ansehen.
Schau mal mittels "dmesg | less" die Meldungen des System vom Booten an. Dort wird u.a. auch aufgelistet, welche Devices er am IDE-Controller findet und ob er DMA oder PIO dafür verwendet. Sollte dort "pio" bei dem relevanten Device aufgeführt sein, würde ich mangels hdparm-Möglichkeit einen neuen Kernel bauen. Aktiviere
ATA/IDE/MFM/RLL support --> IDE, ATA and ATAPI block devices --> Generic PCI IDE support
dann erscheint die Option "Generic PCI bus-master DMA support". Wird die aktiviert, darfst Du zu guter Letzt auch noch "Use PCI DMA by Default when available" aktivieren. Zum guten Schluss den Kernel bauen, installieren, booten und schauen, ob sich die Werte geändert haben.
Ausserdem ein Hinweis: Sollte DMA aktiviert sein, aber nicht korrekt funktionieren (wg. schlechtem Kabel, schlechter Platte/Chipsatz-Kombination, ...) kann es passieren, dass der Kernel nicht bootet und im allerschlimmsten Fall Datenverlust auf der Platte verursacht. Ich halte das zwar für sehr unwahrscheinlich, aber ich weise Dich lieber darauf hin, bevor Du mich regrespflichtig machen willst <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">. Also vorher ein Backup machen!
Ansonsten viel Spass bei der Bastelei.
Jochen
-
Jochen
Re: cdrdao on the fly kopie buffer geht immer auf null
Hmm... Beim erneuten Lesen Deines ersten Postings ist mir noch was aufgefallen.
Du hast einen 12fach-Brenner. Das 40fach-Plextor wird Audio-Daten roh maximal 20fach grabben, m.E. eher um einiges niedriger. Und wenn man dann den cdparanoia-Effekt mit hereinrechnet, wundert es nicht, wenn der Leser nicht so schnell liefern kann, wie der Brenner die Daten wegfackelt...
Über die Option "--paranoia-mode" kannst Du cdrdao sagen, er soll nicht ganz so sorgfältig grabben - siehe man-page. Andererseits müsstest Du bei schlechter CD besser die Schreibgeschwindigkeit herabsetzen: Du hast die Wahl.
Ich persönlich mache Kopien lieber über Image-datei. Braucht ein bisschen länger, macht aber bei schlechten CDs viel weniger Probleme.
Jochen
Du hast einen 12fach-Brenner. Das 40fach-Plextor wird Audio-Daten roh maximal 20fach grabben, m.E. eher um einiges niedriger. Und wenn man dann den cdparanoia-Effekt mit hereinrechnet, wundert es nicht, wenn der Leser nicht so schnell liefern kann, wie der Brenner die Daten wegfackelt...
Über die Option "--paranoia-mode" kannst Du cdrdao sagen, er soll nicht ganz so sorgfältig grabben - siehe man-page. Andererseits müsstest Du bei schlechter CD besser die Schreibgeschwindigkeit herabsetzen: Du hast die Wahl.
Ich persönlich mache Kopien lieber über Image-datei. Braucht ein bisschen länger, macht aber bei schlechten CDs viel weniger Probleme.
Jochen
-
Celindir
Re: cdrdao on the fly kopie buffer geht immer auf null
@Jochen
Vielen Dank für Deine Mühe.
Letzteres wird wohl die Lösung sein.
Ich habe es gestern dann doch noch geschafft hdparm -d /dev/hdc zu prüfen und es war schon auf 1 (also on)
Mit off hat es auch keinen Unterschied gemacht.
Ich werde das mit der paranoia option mal ausprobieren bzw. mit niedriger Geschwindigkeit und das Ergebnis hier Posten.
Bis dahin schon mal vielen Dank.
Ich hätte auch kein Problem damit via Image zu kopieren, fände es nur blöd, wenn es anders ging nur ich es nicht hinbekommen würde <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
CU
Celindir
Vielen Dank für Deine Mühe.
Letzteres wird wohl die Lösung sein.
Ich habe es gestern dann doch noch geschafft hdparm -d /dev/hdc zu prüfen und es war schon auf 1 (also on)
Mit off hat es auch keinen Unterschied gemacht.
Ich werde das mit der paranoia option mal ausprobieren bzw. mit niedriger Geschwindigkeit und das Ergebnis hier Posten.
Bis dahin schon mal vielen Dank.
Ich hätte auch kein Problem damit via Image zu kopieren, fände es nur blöd, wenn es anders ging nur ich es nicht hinbekommen würde <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
CU
Celindir