Archiv verlassen und diese Seite im Standarddesign anzeigen : Was sagt mir diese Ausgabe von hdparm -t?
Moin-Moin,
ich habe zwei IDE-Laufwerke (DVD und Brenner), die als SCSI-Emulation laufen. DVD ist SecMaster und Brenner SecSlave. Ich hab mir sagen lassen, dass man dafür auch DMA einstellen kann (hdparm -d1 /dev/hdc usw.).
Ich wollte jetzt mal testen, wie der Datendurchsatz ist und hab hdparm -t /dev/hdc gemacht. Folgendes kam dabei raus:
*******kiste:/home/sushi # hdparm -d /dev/hdc
/dev/hdc:
using_dma = 1 (on)
*******kiste:/home/sushi # hdparm /dev/hdc
/dev/hdc:
HDIO_GET_MULTCOUNT failed: Input/output error
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
BLKRAGET failed: Input/output error
HDIO_GETGEO failed: Invalid argument
*******kiste:/home/sushi # hdparm -t /dev/hdc
/dev/hdc:
Timing buffered disk reads: read() failed: Input/output error
*******kiste:/home/sushi #
Was sagt mir das jetzt? Bitte mal dringend um Hilfe. Meine CPU-Auslastung ist nämlich beim Rippen von DVD auf Festplatte ziemlich hoch (40% und mehr).
Gruß, Sushi:confused:
Hallo,
soweit ich weiß, hat SuSE standardmäßig DMA-Support nicht für CD-Laufwerke im Kernel integriert.
Ich kann mir nicht vorstellen, dass man DMA für eine SCSI-Emulation einrichten kann; wo hast du das denn gehört?
Lasse mich aber gern belehren.
/noodles
Original geschrieben von noodles
Ich kann mir nicht vorstellen, dass man DMA für eine SCSI-Emulation einrichten kann; wo hast du das denn gehört?
Diese Antwort findet man, wenn man hier im Forum nach "scsi" und "dma" sucht ;).
Susu
also ich lass meine beiden laufwerka im dma.modus laufen, als auch im scsi.emu. und det funzt bei mir.
Also, ich schnall es anscheinend einfach nicht...
Ich muss mein DVD-LW scsi-emulieren, da ich sonst in den Brennprogrammen z. B. kein Iso-Image einer CD auf Festplatte ziehen kann. Wie schonmal gesagt, mein DVD ist das bessere LW für sowas (Brenner taugt halt nur fürs Brennen).
Wenn ich aber die Emu laufen habe, kostet das ne Menge CPU-Leistung beim Rippen: ohne DMA an ca. 60-75% systemseitige CPU-Auslastung, mit DMA (was aber anscheinend nicht richtig funzt) hab ich z. B. beim Auslesen einer Audio-CD auf HD immer noch 40-60% CPU-Last...
Da stimmt doch irgendwas nicht. Von anderen hab ich gehört, sie hätten beim Rippen eine Auslastung von unter 10%. Ist das jetzt gelogen??? Haben alle nur SCSI-Platten und -Laufwerke? :confused: Vielleicht kann mich da ein versierter "Alt-Linuxer" mal gründlich aufklären.
Wie bringe ich die CPU-Last runter?
Susu *abgenervtbin*
Original geschrieben von icle
also ich lass meine beiden laufwerka im dma.modus laufen, als auch im scsi.emu. und det funzt bei mir.
Und was hast Du z. B. beim Audio Rippen für'ne CPU-Auslastung??? Würd mich mal brennend interessieren...
Susu
Na, da kann mir wohl keiner weiterhelfen, was? :mad:
hmm, also wenn ich eine Audio-CD rippe, ist die Prozessorauslastung so bei 50% mit cdparanoia.
Hab gerade mal cdda2wav ausprobiert, ca.20%.
Das Laufwerk als SCSI emuliert. Und DMA ist aktiv.
Mit welchen Programm rippst du ??
Original geschrieben von move
hmm, also wenn ich eine Audio-CD rippe, ist die Prozessorauslastung so bei 50% mit cdparanoia.
Hab gerade mal cdda2wav ausprobiert, ca.20%.
Das Laufwerk als SCSI emuliert. Und DMA ist aktiv.
Mit welchen Programm rippst du ??
Ich nutze meistens k3b (Audio oder Iso-Image) oder grip (Audio-Rippen). k3b nutzt meines wissend cdrecord. Grip nutzt cdpraranoia... Ich hab jetzt allerdings nicht im Kopf, wie die Auslastung mit grip ist... (meine Angabe bezog sich auf k3b).
Wie gesagt, ich finde 40 oder 50% schon recht hoch für ein Multi-Tasking-System. Und es soll ja Leute geben, die tatsächlich nur 10% Auslastung haben. Da muss doch was zu machen sein???
DMA wird übrigens manchmal abgeschaltet (z. B. Iso-Image auf Festplatte schreiben mit k3b). Ich steig da echt nicht durch...
*mussmanvielleichtauchnichtverstehengrummel*
Susu :confused:
Bei grip kann man den verwendeten ripper einstellen. Stell den mal von cdparanoia auf cda2wav
Original geschrieben von sepp2k
Bei grip kann man den verwendeten ripper einstellen. Stell den mal von cdparanoia auf cda2wav
Ist cda2wav denn genauso "gut" wie cdparanoia??? Ich möchte nämlich schon möglichst genau auslesen (hab unter WinXP immer EAC benutzt und vermisse es schmerzlich).
Trotzdem kann mir anscheinend keiner erklären, woher meine hohe CPU-Auslastung kommt? Und wie das mit der SCSI-Emu und DMA wirklich funzt... *seufz*
Susu :(
corresponder
18.12.02, 19:47
hi,
wenn du den ide-bus knechtest, ist die auslastung logisch...
der ide wird ja vom hauptprozessor verwaltet und dann kannst du ja auch ausrechnen, was da gerade über den bus fliesst, bei 48x oder so....:D
deshalb machen scsi-cederoms sinn...
beim brennen hab ich so um die 6-16 % auslastung auf der hauptcpu
:D
Original geschrieben von corresponder
wenn du den ide-bus knechtest, ist die auslastung logisch...
der ide wird ja vom hauptprozessor verwaltet und dann kannst du ja auch ausrechnen, was da gerade über den bus fliesst, bei 48x oder so....:D
deshalb machen scsi-cederoms sinn...
beim brennen hab ich so um die 6-16 % auslastung auf der hauptcpu
Gibt es eigentlich auch SCSI-DVD-Laufwerke (wenn das ne blöde Frage ist, einfach lachen und trotzdem beantworten ;))? Oder muss ich da doch auf IDE-ATAPI zurückgreifen???
Nichtsdestotrotz höre ich immer wieder von Leuten, die auch ne Emu + DMA laufen haben, und deren CPU-Auslastung trotzdem geringer ist... ich mein, spinnen die alle???
Gruß, Susu
corresponder
18.12.02, 20:32
eigendlich hast du ja eine rennmaschine !
komisch...
ich komm grade auch nicht drauf...sorry
oder, bei mir kommt der fehler, wenn kein medium drin liegt.....
:cool:
Original geschrieben von corresponder
eigendlich hast du ja eine rennmaschine !
komisch...ich komm grade auch nicht drauf...sorry
oder, bei mir kommt der fehler, wenn kein medium drin liegt.....
Äh, WELCHER Fehler???
Ja eben, eigentlich hab ich ne Rennmaschine. Und wenn ich überlege, dass hier viele noch mit nem 600er PII arbeiten (die sicherlich nicht alle SCSI-LWs und -Platten haben), dann müsste bei denen die CPU-Auslastung beim Rippen ja bei 150% liegen *lach*
Vielleicht seh ich ja auch den Wald vor lauter Bäumen nicht, aber ich verstehs einfach nicht...
Nochmal die Bitte: KLÄRT EINE UNWISSENDE AUF!!! HÜÜÜÜÜLFÄÄÄÄÄÄÄ!!! :mad:
Susu
corresponder
18.12.02, 21:02
Timing buffered disk reads: read() failed: Input/output error
der fehler !
aber ehrlichgesagt, komm ich nicht drauf....
welches tool bringt dir denn die ausslastungsanzeige von deiner cpu ?
Original geschrieben von corresponder
welches tool bringt dir denn die ausslastungsanzeige von deiner cpu ?
top
Original geschrieben von corresponder
beim brennen hab ich so um die 6-16 % auslastung auf der hauptcpu
Welche Auslastung ich beim BRENNEN habe, hab ich noch gar nicht gecheckt. Ich hab erstmal nur die Auslastung beim Rippen betrachtet...
corresponder
18.12.02, 21:12
naja,
ich mein rippen ist doch auch anstrengent und eventuell schnappt sich grip halt alles, was da ist....
:D
Original geschrieben von corresponder
eventuell schnappt sich grip halt alles, was da ist...
Mit der Auslastung bezog ich mich aufs Rippen mit k3b (grip hab ich noch nicht überprüft, aber das schenkt sich wohl nicht viel).
Komisch ist auch, dass beim Rippen von Audio auf Festplatte DMA aktiviert bleibt, beim schreiben eines Iso-Images auf Festplatte jedoch wird es deaktiviert.
Naja, ich weiß ja nicht, was SuSE alles an Einstellungen implementiert hat, die evtl. das System so bremsen können. Klar, KDE3 ist auch ein super Ressourcen-Fresser (ich steh auf Klicki-Bunti :p), aber wie gesagt, mit dem Athlon XP 1800+ sollte es eigentlich laufen wie geschmiert. Auch 256 MB RAM (+ 520 MB Swap) sollten vollends genügen...:p
Wenn Du noch drauf kommst (oder jemanden kennst, der da weiterhelfen kann *lach*), dann BITTE melden!!! Danke *knicksmach*
Gruß, Susu
Vielleicht erbarmt sich ja noch jemand und klärt eine dumme Frau mal auf...:ugly:
corresponder
19.12.02, 21:53
ich glaube, es liegt, wie ich schon schrieb einfach daran, dass du beim rippen ja daten über den ide bus schaufelst (prozz muss machen) und der ripprozess an sich ja auch noch cpulast fordert.....
irgendwie hab ich die 40% in deinen ersten posting überlesen...das is doch kein problem - oder ?
solang die kisteim leerlauf nich mutiert....
:D
ich habe das ganze mal bei mir getestet. Ich habe ein älteres Board, bzw. ein älteres System. Ich bekomme da in etwa 80% Auslastung. Das liegt allerdings an der art der Daten. Audio Daten werden nun mal anders verarbeitet, als normale Daten. Deshalb gibt es bei den CD-lw ja auch eine extra angabe, wie schnell Audio-Daten gelesen werden können.
Der DMA - modus hat mit der SCSI-emulation nichts zu tun. Die SCSI emulation setzt erst auf den tatsächlichen IDE-port auf. Der DMA - modus läuft auf Hardware ebene, während die SCSI emulation erst auf den Treiber für den Chipsatz aufsetzt.
Dein DMA - problem kann allerdings am Suse Linux kernel liegen. Suse hat den DMA - modus für CD - laufwerke im kernel abgeschaltet. Da kann auch hdparm nichts mehr machen. Was du bei Suse in diesem Fall tun must, ist den kernel neu zu compilieren. Klingt schwierig, ist aber in diesem Fall sehr einfach, da keine neuen Module etc erstellt werden müssen.
Ich habe das Problem schon einmal beschrieben. Eine Anleitung findest du hier (http://www.linuxforen.de/forums/showthread.php?s=&threadid=40766&highlight=DMA)
Was die Merkwürdige Fehlermeldung angeht, bei hdparm -t /dev/hdc ... das liegt AFAIK daran das es CD-lws sind, und darauf nicht schreibend zugegriffen werden kann. Es ist auf keinen fall schlimm.
Hoffe geholfen zu haben;)
Original geschrieben von Kentar
Hoffe geholfen zu haben;)
Hallo Kentar,
ja, Du hast geholfen. Du hast es echt verständlich erklärt.
Aber ehrlich gesagt trau ich mir noch nicht zu, einen neuen Kernel zu backen, da ich mich erst seit Mitte Oktober mit Linux beschäftige... :cool:
Naja, über kurz oder lang komme ich wohl nicht darum herum...
Trotzdem erstmal vielen Dank für Deine Hilfe!
Susu
P.S. Wünsche frohe Weihnachtstage und nen guten Rutsch ins neue Jahr... :D
kannst eigentlich ohne bedenken deinen kernel neu compilen.
nenn´ ihn einfach um, lilo.conf oder grub.conf anpassen.
dann neuen kernel backen, ins /boot schieben, wieder .conf´s anpassen. dann neu booten und
schauen ob alles funktioniert. wenn nicht, kannst ja mit dem stdkernel booten.
und fallst du die richtigen einstellungen getroffen hast, saved danach die /usr/src/kernel-source/.config (da ist alles vermerkt, wie dein kernel compiled ist). brauchst dann eigentlich nicht wieder in kernelmenü reinschauen. einfach .config reinschieben ( ;) ) und los gehts.
schau dir aber das menü ruhig mal an, damit du damit vertraut wirst. was was ist, was was bedeutet ....
k, cu
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.