Hallo Leute Laut Datenblatt ist die Platte mit "Ultra ATA/100" spezifiziert. Ich habe (mit SuSE 9.0) nun folgenden "Effekt": Wenn ich die Platte mit DEVICES_FORCE_IDE_DMA="/dev/hda:udma5" in "/etc/sysconfig/hardware" betreibe, bekomme ich, beim booten, folgende Meldung: ------ hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest } hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete DataRequest } blk: queue c03bf900, I/O limit 4095Mb (mask 0xffffffff) hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest } hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete DataRequest } blk: queue c03bfa5c, I/O limit 4095Mb (mask 0xffffffff) ------ Mh, da das System einwandfrei läuft, eigentlich mehr aus Interesse: Was sagt mir das _genau_? Soweit ich in den "Kernel-Entwickler-Listen" nachgeforscht habe, hat es wohl irgend etwas mit "response" Zeiten zu tun. "Allein, mir fehlt das tiefere Verständnis" ;-) Frage: Was sagt die Meldung aus? (Möglicherweise bin ich auch mal wieder zu "blöd" um "den google-Wust" richtig zu entziffern) Beste Grüße Gerald -- Gerald Engl Bunsenstrasse 13 81735 Muenchen 089/676736
Gerald Engl schrieb:
Laut Datenblatt ist die Platte mit "Ultra ATA/100" spezifiziert.
Ja, solche Blaetter sagen immer viel... :-)
Ich habe (mit SuSE 9.0) nun folgenden "Effekt":
Wenn ich die Platte mit DEVICES_FORCE_IDE_DMA="/dev/hda:udma5" in "/etc/sysconfig/hardware" betreibe, bekomme ich, beim booten, folgende Meldung:
------ hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest } hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete DataRequest } blk: queue c03bf900, I/O limit 4095Mb (mask 0xffffffff) hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest } hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete DataRequest } blk: queue c03bfa5c, I/O limit 4095Mb (mask 0xffffffff) ------
Mh, da das System einwandfrei läuft, eigentlich mehr aus Interesse:
Was sagt mir das _genau_?
Es sieht so aus, als kaeme das System nicht mit dem UDMA-Mode, den Du gewaehlt hast, zurecht.
Soweit ich in den "Kernel-Entwickler-Listen" nachgeforscht habe, hat es wohl irgend etwas mit "response" Zeiten zu tun.
Wenn die Kernel-Entwickler das sagen, wird es sicher stimmen. Das Problem ist aber manchmal nicht die Platte selbst, man muss immer alle beteiligten Komponenten im Blick haben.
"Allein, mir fehlt das tiefere Verständnis" ;-)
Da musst Du dann in den Kernel-Source schauen, was genau diese Fehlermeldung ausloest. Was sagen denn $> hdparm -i /dev/hda bzw. ein $> hdparm /dev/hda und ein $> hdparm -tT /dev/hda auf Deinem System? CU, Th.
Hallo Thomas Thomas Hertweck wrote:
Ja, solche Blaetter sagen immer viel... :-)
Na ja, hängt dann immer davon ab ob bei der Implementierung der entsprechende Standard _wirklich_ eingehalten wird. ;-)
Es sieht so aus, als kaeme das System nicht mit dem UDMA-Mode, den Du gewaehlt hast, zurecht.
Soweit ich in den "Kernel-Entwickler-Listen" nachgeforscht habe, hat es wohl irgend etwas mit "response" Zeiten zu tun.
Wenn die Kernel-Entwickler das sagen, wird es sicher stimmen. Das Problem ist aber manchmal nicht die Platte selbst, man muss immer alle beteiligten Komponenten im Blick haben.
Das war der Hintergrund für meine Frage. Soweit ich es verstanden habe wird beim aktivieren des DMA-Modus die Platte abgefragt, was sie "wirklich kann". Soweit ich es verstanden habe, antwortet wohl nicht jede Platte so wie gewünscht. Scheint wohl auch etwas zeitkritisch zu sein, bzw. die Antwort kommt in einer (vom Kernel) nicht erwartetet Form. BTW: Hardware ist in Ordnung, Fehler auf dem Filesystem (ext3) sind bisher nicht aufgetreten.
"Allein, mir fehlt das tiefere Verständnis" ;-)
Da musst Du dann in den Kernel-Source schauen, was genau diese Fehlermeldung ausloest.
<schmunzel> Also wieder extremer Kaffeemißbrauch und versuchen (als "Nichtprogrammierer") aus den Sourcen schlau zu werden. Ich stimme Dir allerdings zu, die "Wahrheit" liegt wie immer in den Quellen..... </schmunzel>
Was sagen denn $> hdparm -i /dev/hda bzw. ein $> hdparm /dev/hda und ein $> hdparm -tT /dev/hda auf Deinem System?
Danke für den Hinweis, hdparm ist bekannt und wird auf anderen Rechnern verwendet um die Platten "zu Konfigurieren". Es ging mir eher darum mal zu testen was denn die YaST-speziefischen Lösungen so erzeugen.
CU, Th.
Beste Grüße Gerald -- Gerald Engl AED-SICAD Aktiengesellschaft Lilienthalstrasse 7 / 85579 Neubiberg Tel.: +49 89 45026-110
Gerald Engl schrieb:
Thomas Hertweck wrote:
[...] Da musst Du dann in den Kernel-Source schauen, was genau diese Fehlermeldung ausloest.
<schmunzel> Also wieder extremer Kaffeemißbrauch und versuchen (als "Nichtprogrammierer") aus den Sourcen schlau zu werden.
Ich stimme Dir allerdings zu, die "Wahrheit" liegt wie immer in den Quellen..... </schmunzel>
Naja, Du willst es im Detail wissen. Also musst Du entweder jmd. finden, der dieses Detailwissen hat und es mit Dir teilt (was vermutlich schwierig wird, da es nicht viele Leute gibt in dieser Hinsicht), oder Du musst in die Kernelquellen schauen, wo die Meldung generiert wird und was die Ursache dafuer ist. Dass das leicht ist, hat ja keiner gesagt, aber sich Detailwissen anzueignen ist in der Regel immer mit etwas Aufwand verbunden.
Was sagen denn $> hdparm -i /dev/hda bzw. ein $> hdparm /dev/hda und ein $> hdparm -tT /dev/hda auf Deinem System?
Danke für den Hinweis, hdparm ist bekannt und wird auf anderen Rechnern verwendet um die Platten "zu Konfigurieren". Es ging mir eher darum mal zu testen was denn die YaST-speziefischen Lösungen so erzeugen.
Das kann man ja nicht wissen, dass Du hdparm kennst und an- sonsten auch nutzt. Was ist denn nun die Ausgabe obiger drei Befehle? Das waere ja nun schon interessant. Wenn es naemlich Probleme mit DMA gibt, dann kann es schon mal sein, dass der Kernel das deaktiviert fuer das Device - insofern denkst Du vielleicht nur, aufgrund Deiner Einstellungen benutzt Du DMA, aber in Wirklichkeit ist dem gar nicht so. Allerdings solltest Du das anhand der Performance recht schnell merken, wenn kein DMA aktiv ist. CU, Th.
Hallo Thomas Thomas Hertweck wrote:
Naja, Du willst es im Detail wissen. Also musst Du entweder jmd. finden, der dieses Detailwissen hat und es mit Dir teilt (was vermutlich schwierig wird, da es nicht viele Leute gibt in dieser Hinsicht), ...
ACK. Wie Du schon sagst, ...jmd. finden... war Grund für die Frage, könnte ja sein, daß auf der Liste jemand mitliest, der das Thema schon längst "erschlagen" hat.
....oder Du musst in die Kernelquellen schauen, wo die Meldung generiert wird und was die Ursache dafuer ist. Dass das leicht ist, hat ja keiner gesagt, aber sich Detailwissen anzueignen ist in der Regel immer mit etwas Aufwand verbunden.
Nochmal ACK. Ist ja auch das normale Vorgehen (Zuerst Recherchieren, dann "solange die Doku auf den Kopf hauen" bis man es verstanden hat). Manchmal muß man aber auch die Frage stellen, ob sich der Aufwand lohnt. Ging mir schon sehr oft so, daß sich Probleme (bzw. vermeintliche Probleme) mit einem neueren Release (irgendeiner Software) von selbst erledigt haben. Ob in einem solchen Falle der Aufwand (s.o.) gerechtfertigt war, ist dann oft fraglich. Aber das ist ein anderes Thema. [hdparm]
Das kann man ja nicht wissen, dass Du hdparm kennst und an- sonsten auch nutzt.
Sorry, eigene "Betriebsblindheit". Möchtest Du "meine Kristallkugel". ;-) ;-) Aber Spaß beiseite: Ich lese hier auf der Liste seit etlichen Zeiten beinahe täglich mit, schreibe zugegeben sehr selten, da es für fast alle Themen hier "Regulars" gibt, die über die jeweiligen Teilbereiche wesentlich mehr Wissen haben. Ansonsten mache ich das ganze beruflich (am liebsten *nixe/*nuxe aber auch M$, geht halt nicht anders). Das Problem (etwas allgemeiner gefasst) ist: Man weiß nicht was für Voraussetzungen die einzelnen Teilnehmer der Liste mitbringen.
Was ist denn nun die Ausgabe obiger drei Befehle? Das waere ja nun schon interessant. Wenn es naemlich Probleme mit DMA gibt, dann kann es schon mal sein, dass der Kernel das deaktiviert fuer das Device - insofern denkst Du vielleicht nur, aufgrund Deiner Einstellungen benutzt Du DMA, aber in Wirklichkeit ist dem gar nicht so. Allerdings solltest Du das anhand der Performance recht schnell merken, wenn kein DMA aktiv ist.
Muß ich heute Abend mal genauer untersuchen. Mal sehen, kommt u.U. was interessantes dabei heraus. Gruß Gerald -- Gerald Engl AED-SICAD Aktiengesellschaft Lilienthalstrasse 7 / 85579 Neubiberg Tel.: +49 89 45026-110
Am Dienstag, 28. Oktober 2003 11:13 schrieb Gerald Engl:
Danke für den Hinweis, hdparm ist bekannt und wird auf anderen Rechnern verwendet um die Platten "zu Konfigurieren". Es ging mir eher darum mal zu testen was denn die YaST-speziefischen Lösungen so erzeugen.
Bei Suse wird DMA mit dem Script /etc/init.d/boot.idedma aktiviert. Dabei werden dann Variablen benutzt die Du z.B. mit Yast setzt. Es werden also auch nur die Optionen -X und -d für hdparm benutzt. Übrigens sagt die Ausgabe von "hdparm -d" nicht besonders viel aus ob DMA wirklich läuft oder nicht. Auch an der Ausgabe von "hdparm -t" allein kann man meist nicht viel ablesen, da sich bei schnellen Rechnern die Transferraten mit DMA nicht sonderlich erhöhen lassen. Ich schaue mir deshalb immer noch die Prozessorauslastung mit top an während "hdparm -t" läuft. Allerdings werde ich selbst hier auch nicht schlauer mit der Ausgabe von hdparm. Bin nämlich gerade dabei ein paar alte Mainboards und CD-ROM Laufwerke zu testen. Ich verstehe nicht ganz den Unterschied zwischen den Optionen -i und -I (klein und gross i): -i Display the identification info that was obtained from the drive at boot time, if available. This is a feature of modern IDE drives, and may not be sup ported by older devices. The data returned may or may not be current, depending on activity since booting the system. [....] -I Request identification info directly from the drive, which is displayed in a new expanded format with considerably more detail than with the older -i flag. There is a special "no seatbelts" varia [...] Beispiel: linux: hdparm -Xmdma0 /dev/hdc /dev/hdc: setting xfermode to 32 (multiword DMA mode2) linux: hdparm -i /dev/hdc [....] DMA: sdma0 sdma1 sdma2 *mdma0 mdma1 mdma2 [....] linux: hdparm -I /dev/hdc [....] DMA: *sdma0 sdma1 sdma2 mdma0 mdma1 *mdma2 (?) [....] In der letzen Ausgabe sind mit dem * zwei DMA-Modi als aktiv gekennzeichnet. Das habe ich vorher bei keinem anderen IDE-Gerät gesehen. Hdparm kommt das wohl auch komisch vor und hat deshalb ein "?" dahinter geschrieben. Mit -X kann ich nichts daran ändern, es verändert nur die Ausgabe von hdparm -i. Das sieht für mich widersprüchlich zum obigen Man-Page-Auszug aus. Muss man das LW noch irgendwie resetten. Daher meine Frage, wie kann ich den wirklich aktuell benutzten DMA-Modus eines Gerätes abfragen? Grüsse, Rüdiger
Am Montag, 27. Oktober 2003 18:48 schrieb Gerald Engl:
Hallo Leute
Laut Datenblatt ist die Platte mit "Ultra ATA/100" spezifiziert.
Ich habe (mit SuSE 9.0) nun folgenden "Effekt":
Wenn ich die Platte mit DEVICES_FORCE_IDE_DMA="/dev/hda:udma5" in "/etc/sysconfig/hardware" betreibe, bekomme ich, beim booten, folgende Meldung:
------ hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest } hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete DataRequest } blk: queue c03bf900, I/O limit 4095Mb (mask 0xffffffff) hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest } hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete DataRequest } blk: queue c03bfa5c, I/O limit 4095Mb (mask 0xffffffff) ------
Mh, da das System einwandfrei läuft, eigentlich mehr aus Interesse:
Was sagt mir das _genau_?
Soweit ich in den "Kernel-Entwickler-Listen" nachgeforscht habe, hat es wohl irgend etwas mit "response" Zeiten zu tun.
"Allein, mir fehlt das tiefere Verständnis" ;-)
Frage: Was sagt die Meldung aus?
(Möglicherweise bin ich auch mal wieder zu "blöd" um "den google-Wust" richtig zu entziffern)
Habe die selben Probleme seit SuSE 8.2. Es liegt am Kernel, einen Verbesserungsvorschlag habe ich leider auch noch nicht gefunden. Gruss Heinz Dittmar
Hallo Heinz Heinz Dittmar wrote:
Habe die selben Probleme seit SuSE 8.2. Es liegt am Kernel, einen Verbesserungsvorschlag habe ich leider auch noch nicht gefunden.
Das war einer der Hintergründe meiner Frage. Ich habe "den Effekt" auch schon unter SLES8 beobachten können. Um eine Lösung zu finden muß man aber erst _wirklich_ verstehen woran es liegt. Unter Umständen schadet das ganze ja auch nicht, sondern ist nur ein "Mißverständnis" zwischen Kernel und Hardware. Beste Grüße Gerald -- Gerald Engl AED-SICAD Aktiengesellschaft Lilienthalstrasse 7 / 85579 Neubiberg Tel.: +49 89 45026-110
Hallo, Am Montag, 27. Oktober 2003 18:48 schrieb Gerald Engl:
Laut Datenblatt ist die Platte mit "Ultra ATA/100" spezifiziert.
udma5 funktioniert nur wenn Dein Controller das unterstützt und Du ein 80poliges Kabel verwendest! Das verstehe ich zwar nicht, weil die Stecker weiterhin nur 40 pins haben, ist aber so.
Ich habe (mit SuSE 9.0) nun folgenden "Effekt":
Wenn ich die Platte mit DEVICES_FORCE_IDE_DMA="/dev/hda:udma5" in "/etc/sysconfig/hardware" betreibe, bekomme ich, beim booten, folgende Meldung:
------ hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest } hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete DataRequest } blk: queue c03bf900, I/O limit 4095Mb (mask 0xffffffff) hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest } hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete DataRequest } blk: queue c03bfa5c, I/O limit 4095Mb (mask 0xffffffff) ------
Solche Meldungen bekomme ich manchmal im Zusammenhang mit meinem Brenner - funktioniert aber trotzdem . Denke der kann irgendwie nicht all das, was er vorgibt zu können. man hdparm "hdparm -I /dev/hda" sagt Dir was Deine HD für DMA-Modi kann, und welcher aktiviert ist. Schau Dir auch mal die Optionen "-d -X -t -T" und spiel damit ein bischen rum.
Mh, da das System einwandfrei läuft, eigentlich mehr aus Interesse:
Zumindest bei meinem Brenner habe/hatte ich oft das Problem, daß der Kernel (oder wer auch immer) ab und zu DMA einfach ausgeschalten hat. Deshalb habe ich die richtigen Parameter für hdparm durch rumprobieren gesucht.
Gerald Engl Bunsenstrasse 13 81735 Muenchen
Ich schick Dir mal ne Ansichtskarte. Grüsse, Rüdiger
Hallo Rüdiger Rüdiger Meier wrote:
udma5 funktioniert nur wenn Dein Controller das unterstützt und Du ein 80poliges Kabel verwendest! Das verstehe ich zwar nicht, weil die Stecker weiterhin nur 40 pins haben, ist aber so.
Ich vergaß explizit zu erwähnen, daß die Hardwarevoraussetzungen (Controller, Kabel. Kabellänge, etc.) erfüllt sind. Ich setze sowas halt voraus. ;-)
Solche Meldungen bekomme ich manchmal im Zusammenhang mit meinem Brenner - funktioniert aber trotzdem . Denke der kann irgendwie nicht all das, was er vorgibt zu können.
Ich hatte das bei Brennern auch schon. Die Lösung war in diesen Fällen DMA im BIOS zu deaktivieren und mit hdparm "vernünftige" Settings einzustellen.
man hdparm
Danke, ;-) sowas setze ich auch voraus. Sonst hätte ich nach "hdparm" gefragt.
Zumindest bei meinem Brenner habe/hatte ich oft das Problem, daß der Kernel (oder wer auch immer) ab und zu DMA einfach ausgeschalten hat. Deshalb habe ich die richtigen Parameter für hdparm durch rumprobieren gesucht.
Siehe oben. Beste Grüße Gerald -- Gerald Engl AED-SICAD Aktiengesellschaft Lilienthalstrasse 7 / 85579 Neubiberg Tel.: +49 89 45026-110
Am Dienstag, 28. Oktober 2003 11:21 schrieb Gerald Engl:
man hdparm
Danke, ;-) sowas setze ich auch voraus. Sonst hätte ich nach "hdparm" gefragt.
Sorry, wollte Dir nicht Sachen erklären, die Du gemacht hast, aber dann schreibe doch nächstens statt
Laut Datenblatt ist die Platte mit "Ultra ATA/100" spezifiziert.
und
Wenn ich die Platte mit DEVICES_FORCE_IDE_DMA="/dev/hda:udma5" in "/etc/sysconfig/hardware" betreibe,
lieber: "hdparm sagt, daß die Platte mit udma5 läuft." Grüsse, Rüdiger
Hallo Rüdiger Rüdiger Meier wrote:
Sorry, wollte Dir nicht Sachen erklären, die Du gemacht hast, aber dann schreibe doch nächstens statt
[snip]
lieber: "hdparm sagt, daß die Platte mit udma5 läuft."
O.K. Sorry, ich bin in diesem Falle wohl mal wieder das beste Beispiel für "Betriebsblindheit" ;-) Gruß Gerald -- Gerald Engl AED-SICAD Aktiengesellschaft Lilienthalstrasse 7 / 85579 Neubiberg Tel.: +49 89 45026-110
Hallo Leute
Also wie versprochen (jetzt sitz ich endlich wieder zu Hause) die
Ausgaben von hdparm bzw. "der Tests".
Mit den "von YaST" vorgenommenen Settings.
------------
hdparm -i /dev/hda
/dev/hda:
Model=Maxtor 2B020H1, FwRev=WAK21R90, SerialNo=B1J0SNXE
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=40020624
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: (null):
* signifies the current active mode
------------
hdparm /dev/hda
/dev/hda:
multcount = 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 2491/255/63, sectors = 40020624, start = 0
------------
hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 1924 MB in 2.00 seconds = 961.52 MB/sec
Timing buffered disk reads: 112 MB in 3.04 seconds = 36.88 MB/sec
------------
Erster Test mit "mit bonnie":
bonnie -s 600 -d /tmp
Bonnie 1.4: File '/tmp/Bonnie.4553', size: 629145600, volumes: 1
Writing with putc()... done: 15512 kB/s 92.8 %CPU
Rewriting... done: 10889 kB/s 4.6 %CPU
Writing intelligently... done: 36880 kB/s 13.6 %CPU
Reading with getc()... done: 12404 kB/s 70.5 %CPU
Reading intelligently... done: 25908 kB/s 5.1 %CPU
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
---Sequential Output (nosync)--- ---Sequential
Input-- --Rnd Seek-
-Per Char- --Block--- -Rewrite-- -Per Char-
--Block--- --04k (03)-
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU
/sec %CPU
mule 1* 600 15512 92.8 36880 13.6 10889 4.6 12404 70.5 25908 5.1
151.7 0.4
(Umbrüche sind manchmal lästig )
Jetzt die Ergebnisse mit der von mir normalerweise über "hdparm" bei
Festplatten (wenn passend) verwendeten Parameter (hdparm -c1 -d1
-m16 -k1 -K1 /dev/hd?):
------------
hdparm -i /dev/hda
/dev/hda:
Model=Maxtor 2B020H1, FwRev=WAK21R90, SerialNo=B1J0SNXE
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=40020624
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: (null):
* signifies the current active mode
------------
hdparm /dev/hda
/dev/hda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 1 (on)
readonly = 0 (off)
readahead = 8 (on)
geometry = 2491/255/63, sectors = 40020624, start = 0
------------
hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 2288 MB in 2.00 seconds = 1144.00 MB/sec
Timing buffered disk reads: 112 MB in 3.01 seconds = 37.22 MB/sec
------------
Zu dem Ganzen noch ein neuer "bonnie"-Lauf:
bonnie -s 600 -d /tmp
Bonnie 1.4: File '/tmp/Bonnie.1512', size: 629145600, volumes: 1
Writing with putc()... done: 15706 kB/s 93.3 %CPU
Rewriting... done: 11462 kB/s 5.1 %CPU
Writing intelligently... done: 38918 kB/s 14.5 %CPU
Reading with getc()... done: 12679 kB/s 71.5 %CPU
Reading intelligently... done: 26438 kB/s 5.7 %CPU
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
---Sequential Output (nosync)--- ---Sequential
Input-- --Rnd Seek-
-Per Char- --Block--- -Rewrite-- -Per Char-
--Block--- --04k (03)-
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU
/sec %CPU
mule 1* 600 15706 93.3 38918 14.5 11462 5.1 12679 71.5 26438 5.7
167.0 0.4
------------
Hallo, Am Tue, 28 Oct 2003, Gerald Engl schrieb:
------------ hdparm -i /dev/hda
/dev/hda: Model=Maxtor 2B020H1, FwRev=WAK21R90, SerialNo=B1J0SNXE [..] hdparm -tT /dev/hda /dev/hda: Timing buffered disk reads: 112 MB in 3.04 seconds = 36.88 MB/sec [..] Jetzt die Ergebnisse mit der von mir normalerweise über "hdparm" bei Festplatten (wenn passend) verwendeten Parameter (hdparm -c1 -d1 -m16 -k1 -K1 /dev/hd?): [..] hdparm -tT /dev/hda /dev/hda: Timing buffered disk reads: 112 MB in 3.01 seconds = 37.22 MB/sec [..] Mh, alles "ganz prickelnd", was?
BTW: Wenn die Parameter für die Platte mit hdparm gesetzt werden, gibt es keine "ominöse" Meldung beim booten.
Verwende 'hdparm -c1 -d1 -k1 -K1 /dev/hda'. Und gib evtl. dem Kernel die Geometrie mit (das musste ich bei ner aelteren Maxtor auch machen). hda=2491,255,63 Vergleiche die Geometrie aber noch mit der Ausgabe von fdisk -l /dev/hda | grep sectors -dnh --
Genauso könntest Du einen Grafiker in den Farbraum schicken. Was mich daran erinnert, dass Maler zwar von Farb_tönen_, Musiker aber von Klang_farben_ reden. [Michael Fesser, Markus Kottenhahn in <darw/>]
Gerald Engl schrieb:
[...] hdparm /dev/hda
/dev/hda: multcount = 16 (on) IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off)
Sieht soweit gut aus. Allerdings ist "keepsettings" bei Dir "off", d.h. ueber einen Reset hinweg wird nicht ver- sucht werden, DMA aktiv zu halten. Das sollte man auf "on" setzen (als -k1 bei hdparm), wenn man sich sicher ist, dass DMA prinzipiell mit dem Laufwerk funktioniert (geht sicher auch ueber YaST2, oder?). Aber vorsicht, man kann so auch gerne mal in Reset-Loops laufen, wenn es Probleme in der Benutzung von DMA mit dem Laufwerk gibt.
hdparm -tT /dev/hda
/dev/hda: Timing buffer-cache reads: 1924 MB in 2.00 seconds = 961.52 MB/sec Timing buffered disk reads: 112 MB in 3.04 seconds = 36.88 MB/sec
Sieht soweit OK aus, neuere Festplatten schaffen aller- dings i.d.R. bei "buffered disk reads" deutlich ueber 50 MB/s.
[...eigene Einstellungen...] hdparm /dev/hda
/dev/hda: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 1 (on)
Sieht soweit OK aus. Man beachte den Unterschied zu oben, wenn Du hier Deine eigenen hdparm-Einstellungen benutzt.
hdparm -tT /dev/hda
/dev/hda: Timing buffer-cache reads: 2288 MB in 2.00 seconds = 1144.00 MB/sec Timing buffered disk reads: 112 MB in 3.01 seconds = 37.22 MB/sec
Da tut sich natuerlich wenig. Deutliche Unterschiede merkst Du erst, wenn Du DMA mal deaktivierst und dann nochmal ein "hdparm -tT /dev/hda" aufrufst. Dann gehts ab in den Keller mit dem Datendurchsatz.
[...] BTW: Wenn die Parameter für die Platte mit hdparm gesetzt werden, gibt es keine "ominöse" Meldung beim booten.
Dann muesste man wohl mal schauen, was SuSE da im Skript macht, das DMA aktiviert, im Vergleich zu Deinem eigenen Aufruf per hdparm. CU, Th.
participants (7)
-
David Haller -
Gerald Engl -
Gerald Engl -
Heinz Dittmar -
Peter Wiersig -
Rüdiger Meier -
Thomas Hertweck