Hallo, Ratti:

...

ich ärgere mich hier herum, daß mir mein System einfach zu lahm ist, so ganz im Allgemeinen.

Dieter Kluenter:

Ich denke eher an andere Ursachen. Welche Kernel Version ? Einge Kernel hatten ein fürchterliches Virtual Memory Management, sie dazu mal /usr/src/linux/Documentation/sysctrl/vm.txt

...bereits den Ordner "linux" habe ich nicht, auch keine Datei dieses namens ind "/usr"...

Dann könnte auch die Grafikkarte der Übeltäter sein, welchen X-Server nutzt du ? Das verspätete Reagieren auf Eingabegeräte läßt eher den X-Server vermuten.

OK. Schaun wir mal. DMA scheint m.E. zu funktinieren. Ich habe an mienem normalen IDE-Bus gar keine Platten hängen, die Platten hängen alle an dem Onboard-ATA100 Promise und sind auch dafür ausgelegt. Ich schiebe es dieser Tatsache zu, daß es bei mir den Yast-Eintrag für DMA-aktivierung nicht gibt, ebenso wurde rcidedma anscheinend nicht installiert. Das scheint mir logisch, denn der "normale" IDE-Bus hat nur einen Brenner dranhängen. An dieser Stelle habe ich einfach mal mit hdparm -t die Plattengeschwindigkeit geprüft, mehr als 22 MB/sec sind ein anständiger Wert. DMA scheint also OK und/oder nicht notwendig für Promise zu sein. Kernel Version...ich habe 7.3 von CD installiert, mache fleissig YOU-Updates. Ein uname -a ergibt Linux gesindel 2.4.7-4GB #1 (Datum, Uhrzeit) i586 unknown (Äh, "Gesindel" ist meine Domain, das ist nicht an die Allgemeinheit gerichtet...:-) ) Welchen X-Server? Gute Frage. Der letztens von mir angestoßene Thread, was der Unterschied zwischen Benutzeroberfläche und Windowmanager sei und was denn überhaupt ein X-Server sei, verlief leider im Sande. :-) Ich benutze IceWM und KDE 2.2.1, und yast2 sagt mir, ich benutze XFree86 4:nvidia Einstellungen: 1280x960, 24 Bit/ 16 Mio Farben, 150 Kz, 3D-Beschleunigung aktibviert. Ich habe eine Geforce2 MX, die hat eigentlich ganz gut Bumms, ich baller ganz gern. Ich bin dem Tip gefolgt und habe xosview gestartet. Eigentlich sieht das recht gut aus. Bei zwei Dingen bin ich mir nicht sicher: -Die CPU-Last geht ziemlich hoch, wenn ich Programme öffne. Das könnte ja doch wieder auf DMA hindeuten? -Vom Swap sind 50M benutzt. Vom echten RAM sind nur geschätzt 10% "Free", das ist doch für Linux OK, das hängt doch mit der speziellen Speicherverwaltung zusammen, oder? Weitere 15% sind "Cache", etwa 8% sind "Buff", der große Rest ist "Used+Shar" Sieht plausibel aus. Die PlattenLED macht auch nicht den Eindruck des "dauerswappens". Gibt es Benchmarktools, mit denen man gezielter gucken kann, wobei eigentlich Rechenpower verbraucht wird? Gruß und Danke, Ratti

Hallo, Ratti:

...

Linux gesindel 2.4.7-4GB #1 (Datum, Uhrzeit) i586 unknown

Ralf Corsepius:

Da hätten wir einen heissen Kandiaten.

Meine Empfehlung: Kernel updaten, selbst auf dem SuSE-Server liegen nicht grundlos schon mehrere davon.

Ah ja. Dann entscheide ich mich mal für k_deflt-2.4.16-22.i386.rpm

...

Welchen X-Server?

Gute Frage. X -version

hätte es Dir verraten.

Danke. 4.1.0 protocol Version 11, revision 0, vendor release 6510 vom 2.6.2001 So, dann probiere ich das mal mit dem Kernel, und irgendwas von Nvidia muß man auch noch einspielen für 3D-Beschleunigung. Bis später, hoffentlich. Gruß, Ratti

On Wed, 09 Jan 2002, Ratti wrote:

DMA scheint m.E. zu funktinieren.

Was sagt ein "hdparm -i /dev/hdX"? [..]

Gibt es Benchmarktools, mit denen man gezielter gucken kann, wobei eigentlich Rechenpower verbraucht wird?

"top" ist dann doch etwas ausfuehrlicher... (Zum Rest hat dir ja Ralf schon einiges geschrieben ;) -dnh -- Ein Admin ist wie ein Tierpfleger er muss mir eNTen Pinguinen und Daemonen (ähm habe ich irgendwie noch in keinem Zoo gesehen) umgehen können, eNTen sind aber besonders gefährlich und unberechenbar, beim Putzen sollte man da schon aufpassen das man sich keinen Wurm einfäng[........] -- D. Aubry

On Thu, 10 Jan 2002, Ratti wrote:

Am Don, 2002-01-10 um 02.08 schrieb David Haller:

...

On Wed, 09 Jan 2002, Ratti wrote:

...

DMA scheint m.E. zu funktinieren. Was sagt ein "hdparm -i /dev/hdX"?

Irgendwo zwischen hda und hdd, also der langsame ATA, hängt bloß mein IDE-CD-RW-Laufwerk. Am schnellen Promise hängen zwei Platten und die DVD.

Ok.

Eine der Platten unterstützt DMA Mode 4, die ander Mode 5.

DMA oder UDMA? (DMA = Multiword DMA sind die DMA Modi die bis 16.6 MB/s gingen, aber dabei (im Ggs. zu PIO) die CPU entlasteten ;)

hdparm -i /dev/hde:

Model=WDC WD307AA, FwRev=05.05B05, SerialNo=WD-WMA111239352 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq } RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=60074784 ^^^^^^^^^^^ Schon mal ueberlegt, in Zukunft 255 Koepfe zu verwenden? (Modus im BIOS manuell auf "LBA" statt auto einstellen ;) Allerdings kann man das nur _vor_ einer Partitionierung der gesamten Platte aendern, also ggfs. bei der naechsten Platte ;)

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 udma0 udma1 udma2 udma3 *udma4

Aha. Es muesste also udma4 (100 MB/s) sein, oder? Ein hdparm -t Wert von > 20 MB/s ist IMO ok. Lass dabei doch mal ein top laufen (am besten auf der Konsole in init 1 oder so, und sonst nix)... Falls das ne CPU Belastung < 50% (ich bekomm < 20% und bis zu 24 MB/s) fuer hdparm liefert, liegt's IMO nicht an den HD / den DMA-Modi... Woran dann das "laaangsam" liegt? Keine Ahnung, lass mal top laufen, und achte dabei auch auf die "buff", "cached" und die "swap" Werte...

Festplatte /dev/hde: 255 Köpfe, 63 Sektoren, 3739 Zylinder

Huch? Jetzt doch 255 Koepfe? Nicht gut. _Kann_ Probleme geben. Laesst sich aber halt (s.o.) nicht ohne komplette Repartitionierung beheben. Oh, ach ja, halt, die HD haengt am Promise, richtig? Kann's sein, dass die HD an einem anderen Controller partitioniert wurde??? Also, ich habe die Erfahrung gemacht (mit nem Promise Ultra33), dass der nur ein Geometrie-mapping verwendet (naemlich IIRC auch mit 16 Koepfen), das sich leider nicht einstellen laesst. Nun hatte ich eine HD die mal an nem Chipsatz[1]-Controller hing mit 255 Koepfen konfiguriert (und partitioniert), und erstaunlicherweise lief die HD auch so am Promise, aber grauslich langsam (Verz. einlesen dauerte Minuten!). Beheben kann man diesen Geometrie-Konflikt leider nur durch eine komplette Repartitionierung der gesamten Platte am jew. Controller. [..]

/dev/hdf muß ich irgendwann mal wegsichern, da sind meine ollen Windows-Daten drauf, i.d.R. gar nicht gemountet.

Hehe, so Partitionen hab ich auch noch ;) -dnh PS: Deine Zeilen sind zu lang und deine Msg-Id ist noch ungueltig, hatten wir das Thema nicht schonmal? Kannst dich ggfs. nochmal per PM melden ;) [1] Intel 80430HX/PIIX -- Dann lass' uns in Zukunft BASIC nehmen. Mach' 'mal ein groesseres Projekt in NIXDORF-Basic. Das ist eigentlich so unmoeglich wie Duennschiss an einen Nagel zu haengen. Das erhebt Deine Kunstform zur Abrobatik. -- Hans Bonfigt in dasr

On Fri, 11 Jan 2002, Arne-Erik Martin wrote:

Am Fri, 11 Jan 2002 00:14:30 +0100 schrieb David Haller :

...

On Thu, 10 Jan 2002, Ratti wrote:

...

Am Don, 2002-01-10 um 02.08 schrieb David Haller:

...

On Wed, 09 Jan 2002, Ratti wrote:

...

DMA scheint m.E. zu funktinieren. Was sagt ein "hdparm -i /dev/hdX"?

[...]

...

...

CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=60074784 ^^^^^^^^^^^ Schon mal ueberlegt, in Zukunft 255 Koepfe zu verwenden? (Modus im BIOS manuell auf "LBA" statt auto einstellen ;)

Ich bin nicht so er Hardwarefreak, welchen Vorteil hat das?

Also, zuerstmal den, dass man vor dem "magischen" Zylinder 1023 mehr Platz hat, was je nach Bootloader doch entscheidend sein kann. Denn die CHS-Felder in den Partitionstabellen koennen max. 1023/255/63 als Werte enthalten, wobei 1023 ein "ungueltiger Wert" fuer die Zylindernummer ist, ueber die BIOS-Funktion INT13h,2 kann man also maximal den Sektor 1022/255/63 ansprechen. Dieser liegt mit dem 255-er Geometrie-mapping bei 7,8365 GB, beim 16-er bei gerade mal 503.5 MB... Ansonsten ist's AFAIK primaer eine Frage, mit welchem Mapping die Platte partitioniert wurde, denn Win32 (aber weder DOS noch Win3.x (noch NT < X.Y?)) und Linux (und andere aktuellere x86-OS) sprechen die HD nach dem Booten und dem laden der eigenen Treiber eh via LBA an. Bei Linux+LILO laeuft das z.B. so ab: - BIOS fuehrt POST usw. aus - BIOS laedt (via INT13h, s.u.) den MBR ins RAM und startet den Code in den ersten 446 Bytes (die restlichen 66 Bytes sind 4*16 Byte Partitions- tabelle und 2 Byte (0x55 0xAA) "Signatur"). Falls der Code kein gueltiger Bootcode ist (z.B. alles genullt wie bei einer "frischen" HD) gibt das BIOS eine Fehlermeldung aus (IIRC irgendwas a la "Non System Disk. Press ...") und rebootet nach einem Tastendruck. - Der Code aus dem MBR (z.B. der erste Teil von LILO) laedt nun ggfs. zuerst "seinen Rest" (bei LILO u. anderen Bootmanagern), der an verschiedenen Stellen der HD liegen kann (meist aber wird der freie Platz im Rest des ersten Kopfes verwendet (CHS 0/0/2 bis CHS 0/0/63)) und macht "weiter". Da zu diesem Zeitpunkt das "Programm" nur sehr rudimentaer ist (in 446 Bytes lassen sich nicht viele Maschinenbefehle unter- bringen ;) geschieht dieses "laden des Restes" ueber die o.g. BIOS- Funktion INT13h,2. Und diese Funktion kann eben nur CHS... Unter DOS kann man das mit "debug" emulieren (ssss steht fuer die (wechselnde) "Segment"-Adresse): -a100 -ssss:0100 mov ax,0201 ; ah=02 -> Funktion 2 = Lese Sektor ; al=01 -> 1. Parameter: 0x01 = 1 Sektor -ssss:0103 mov bx,1000 ; Param: bx -> Zieladresse im Speicher, ; (relativ zum "Segment"), in das gelesen ; werden soll -ssss:0106 mov cx,0001 ; Param: ch=00 -> Bits 0-7 d. Zyl. ; cl=01 -> Bits 8-9 d. Zyl. (MSB) und ; Bits 0-5 d. Sektors -ssss:0109 mov dx,0080 ; Param: dh=00 -> Kopfnummer ; dl=80 -> Geraet, 0x80 = erste HD ; (das ist analog zu dem was man mit ; "bios=" in der lilo.conf angeben kann). -ssss:010c int 13 ; es soll INT13 mit den oben "gesetzten" ; Parametern aufgerufen werden... -ssss:010e ; nur ein "Return" -g=100,10e Siehe dazu die c't 05/1997, S. 188ff, Kasten "Bordmittel".[1] - Der "komplette" Bootmanager / Bootloader macht nun weiter, liest die Partitionstabelle (ab "ssss:11be", wurde ja schon geladen ;), startet z.B. im Falle von DOS den ersten Sektor einer FAT-Partition die mit "format" und "sys" behandelt wurde oder knueppelt (im Falle von LILO das Linux startet) den Kernel in den Speicher und startet diesen (bei "other=" statt "image=" verhaelt sich LILO -- je nach "loader" -- wie ein DOS-MBR-Bootcode). Weitere "Spielereien" (verstecken/aktivieren von Partitionen usw.) werden noch vorher erledigt... Nun, was soll das alles sagen? Nunja, wenn der Bootmanager nicht, wie z.B. grub, entsprechende Treiber beinhaltet -- und auch diese muessen erst einmal von HD geladen werden! -- kann der Bootmanager bzw. -loader nur das BIOS verwenden, um eben den Rest zu laden. Und da "greift" die Beschraenkung auf die magischen 1023 Zylinder... Ich weiss jetzt aber leider nicht, ob und wie z.B. aktuelle BIOSe auch Funktionen bereitstellen (INT13 Ext?), die es moeglich machen, ueber die LBA Adresse Sektoren von einer HD zu laden, ich vermute aber schon. Die Option "lba32" in LILO scheint das aber zu tun, aber ob da ein entsprechender Treiber von LILO dazugeladen wird, oder ob das BIOS verwendet wird weiss ich nicht, und im Moment will ich auch nicht die LILO-Sourcen durchwuehlen... Achso, ja, Performance-maessig hat die Geometrie AFAIK nix zu bedeuten, da modernere HDs dem BIOS sowieso nicht die "echte" Geometrie melden, sondern "intern" die dem BIOS gemeldete Geometrie auf die echte umsetzen (z.B. bei Maxtor HDs kann man das recht gut an der Modellbezeichnung[2] erkennen: Die letzte Ziffer in den (nun) aelteren Modellbezeichnungen, wie z.B. das n in {5,9}xxxx{D,H,U}n steht fuer die Anzahl der echten "Koepfe", also z.B. bei 92041U4 sind es also 2 "Scheiben" mit 4 Koepfen. Was die HD dann ans BIOS meldet steht auf einem anderen "Blatt"[3]. Ach ja, ich will's nicht verschweigen, das Mapping mit 255 Koepfen hat einen Nachteil, naemlich dass es einen u.U. einen (groesseren) "Verschnitt" beim Partitionieren gibt, da Partitionen immer auf Zylindergrenzen beginnen/enden muessen[4]. Und noch ein "Ach ja", diesmal ein wichtiges: Wenn das alles zu konfus war, bitte nachfragen! Bei dem Thema sind Missverstaendnisse zu leicht "unangenehm" ;) -dnh [1] Diese c't (ggfs. zusammen mit der c't 06/2000) gehoert zusammen mit einer DOS-Bootdiskette auf der "debug" ist, zur "Ueberlebens- ausruestung" bei defekten Partitionstabellen ;)) Bequemer geht's aber auch mit sog. "Diskeditoren" (s. c't 6/00). [2] cat /proc/ide/hdX/model [3] naemlich unter "physical" in /proc/ide/hdX/geometry die "logische" Geometrie, also das verwendete "Mapping" (s.o.) steht unter "logical". Bei mir z.B. (siehe die Ausgabe bei [4]) Wie man bei [4] sieht verwende ich durchgaengig ein "X Zylinder / 255 Koepfe / 63 Sektoren"-Mapping... [4] Der Verschnitt laesst sich (glaube ich) mit folgendem (C&P faehig) berechnen (der Inhalt von "DRIVES" ist an die Buchstaben der vorhandenen HDs anzupassen! [5]): DRIVES="a b c"; \ for drv in $DRIVES; \ do \ cat /proc/ide/hd${drv}/{model,geometry}; \ c="`cat /proc/ide/hd${drv}/capacity`"; \ cap=`echo "$c / 2048" | bc`; \ phys=`cat /proc/ide/hd${drv}/geometry | head -1 | \ sed 's@[^0-9]*\([0-9/]*\)@\1@;s@/@*@g'`; \ log=`cat /proc/ide/hd${drv}/geometry | tail -1 | \ sed 's@[^0-9]*\([0-9/]*\)@\1@;s@/@*@g'`; \ diff=`echo "scale=2; ( ($phys) - ($log) ) / 2048" | bc`; \ echo "$diff MB Verschnitt aus $cap MB"; echo; \ done Bei mir z.B.: Maxtor 91303D6 physical 25249/16/63 logical 1584/255/63 1.96 MB Verschnitt aus 12427 MB Maxtor 92041U4 physical 39703/16/63 logical 2491/255/63 1.32 MB Verschnitt aus 19541 MB IBM-DTLA-305040 physical 19710/16/255 logical 5005/255/63 5.60 MB Verschnitt aus 39266 MB [5] ok, ein "2>/dev/null" hinter dem "done" hilft auch schon ;) -- BTDT. The comment "You _are_ our current T1-provider, now what were you saying about savings?" usually perplexes them long enough for you to put the phone handset down somewhere quiet and sneak off to recharge your caffeine-supply. -- Tanuki in asr on $TELCO ads

On Sat, 12 Jan 2002, Andreas Meyer wrote:

David Haller schrieb:

[snipp... er entschwebte in Dimensionen, in die keiner fähig war zu folgen]

*snigger* Doch scheinbar schon mindestens einer (der sich per PM gemeldet hat, danke dafuer uebrigens ;)

...

[4] Der Verschnitt laesst sich (glaube ich) mit folgendem (C&P faehig) berechnen [..] Als ich mir vor einem Jahr diese Maxtor 5T040H4 gekauft habe, wurde sie vom BIOS nicht erkannt.

Per Hand (Modus "manual") ging nicht? Als was ist die HD jetzt eingetragen ("auto", "LBA" oder was)?

ST3660A physical 1057/16/63 logical 528/32/63 .49 MB Verschnitt aus 520 MB

*hehe* $ echo "1057*16; 528*32" | bc 16912 16896 Ne ungerade Zylindernummer bei "physical" ist keine gute Voraussetzung fuer eine andere Geometrie als eben diese ;)

Maxtor 5T040H4 physical 79408/16/63 logical 79408/16/63 0 MB Verschnitt aus 39083 MB

Die einzige Möglichkeit die ich sah, war eine kleine Seagate mit der boot-Partition davorzuhängen und dort lilo zu installieren.

Naja, oder so :)) -dnh -- "Wer nicht merkt das er Merkbefreit ist, dem sollte man eine Merkbefreiung für´s Leben verpassen. D.B.D.D.H.K.P. Das macht Spass und tut nicht weh." [WoKo in dag°]

Hallo, Ratti:

...

Am schnellen Promise hängen zwei Platten und die DVD. Eine der Platten unterstützt DMA Mode 4, die ander Mode 5.

David Haller:

DMA oder UDMA? (DMA = Multiword DMA sind die DMA Modi die bis 16.6 MB/s gingen, aber dabei (im Ggs. zu PIO) die CPU entlasteten ;)

UDMA. Eine hat 66 (Mode 4), die andere 100 (Mode 5). Da sie beide an der gleichen Strippe hängen, werden sie sich wohl auf 4 geeinigt haben. (Ich will das nicht ändern, sonst wäre eine zusammen mit dem DVD-Laufwerk, das wäre wahrscheinlich die schlechtere Lösung)

...

CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=60074784 ^^^^^^^^^^^ Schon mal ueberlegt, in Zukunft 255 Koepfe zu verwenden? (Modus im BIOS manuell auf "LBA" statt auto einstellen ;)

Bringt das was ? Es ist gut möglich, das du Recht hast:

...

Festplatte /dev/hde: 255 Köpfe, 63 Sektoren, 3739 Zylinder

Huch? Jetzt doch 255 Koepfe? Nicht gut. _Kann_ Probleme geben. Laesst sich aber halt (s.o.) nicht ohne komplette Repartitionierung beheben.

Oh, ach ja, halt, die HD haengt am Promise, richtig?

Kann's sein, dass die HD an einem anderen Controller partitioniert wurde???

...das ist nämlich möglich. Ich habe das Asus A7V-Board und bin von dem Bug im Via-Chipsatz betroffen. Jedesmal beim DVD-gucken stürzte der Rechner ab und die Windows-Partition war komplett weg. :-((( Daher habe ich möglichst viel an den Promise gehängt, um von "normalen" AT-Bus wegzukommen. Darum hängt auch das DVD-Laufwerk dort und nicht woanders. Ich glaube, ich kauf mir gegen die Winterdepressionen einfach mal eine neue Platte.

Aha. Es muesste also udma4 (100 MB/s) sein, oder? Ein hdparm -t Wert von > 20 MB/s ist IMO ok. Lass dabei doch mal ein top laufen (am besten auf der Konsole in init 1 oder so, und sonst nix)...

Ich hatte schon Werte gepostet, wahrscheinlich überschneiden sich die Mails. Das sieht für mich ganz OK aus. Auf dem Rechner habe ich ja auch ein Windows drauf. Im direkten Vergleich ist die Linux-Installation einfach "zäher". So simple Sachen wie "swappt dauernd" oder "Platte lahm" scheinen es nicht zu sein, die Anzeigen sehen OK aus. Ich beschreibe mal mein "Feeling", die Werte sind nicht gemessen, sondern gefühlt: :-) Mein Eindruck geht dahin, daß die Verteilung der Rechenzeit einfach schlecht ist. Ich starte z.B. "convert" mit ordentlich was zu tun, und der Prozess braust mit Volldampf los. Hole ich jetzt ein anderes Fenster in den Vordergrund, hat das erst mal gar keine Ressourcen, es dauert einige Sekunden, bis dem System klar ist, daß es hier von 95:5-Aufteilung auf 50:50 runter muß. Starte ich die nächste Anwendung - wieder das gleiche. Haben sich die Anwendungen eingependelt, geht alles prima. Hatte eine Anwendung nix zu tun, wird sie "geparkt" und ist dann erst mal wieder lahm. Das stört mich sehr, wenn diese Anwendung z.B. KDE ist. Es ist gut möglich, daß ich das einfach von Windows anders gewohnt bin, wenn ich da ein Hintergrundfenster nach vorne hole, ist es sofort da, es gibt keine Verzögerungen oder sichtbare Redraw-Verzögerungen. Ich nehme mal an, daß Windows (Da auch dort die Rechenzeit nicht vom Himmel fällt) immer eine "Reserve" behält. Vielleicht kann man auch Linux so konfigurieren? Mir ist es egal, ob eine Grafik 2 Minuten konvertiert oder 2 Minuten und 20 Sekunden, aber mich stört es, wenn ich auf ein Hintergrundfenster klicke und es gibt eine Verzögerung von einer halben Sekunde beim "Nach-vorne-holen". Ich glaube, ich stöpsel trotzdem noch mal RAM dazu. Ach so, das Kernelupdate hat gefühlsmässig was gebracht, danke an die Tipgeber.

PS: Deine Zeilen sind zu lang und deine Msg-Id ist noch ungueltig, hatten wir das Thema nicht schonmal? Kannst dich ggfs. nochmal per PM melden ;)

Machen wir per PM :-) Gruß, Ratti

Hallo, Ratti:

...

Ich habe das Asus A7V-Board und bin von dem Bug im Via-Chipsatz betroffen. Jedesmal beim DVD-gucken stürzte der Rechner ab und die Windows-Partition war komplett weg. :-(((

Thomas Hertweck:

Ich glaube nicht, dass das am VIA Bug liegt, oder Du hast weder ein BIOS-Update gemacht noch einen aktuellen Linux- Kernel. Ich habe ein Asus A7V133, und bei mir haengen

Ich habe immer das aktuelle Bios. Dem Via-Problem ist über das Bios auch nicht so wirklich beizukommen, außer man setzt die Zugriffszeiten so lahm, daß man seinen alten Rechner hätte behalten können.

2 Festplatten, DVD und CD-RW am VIA-IDE-Controller, und da stuerzt nichts ab, da gehen beim Kopieren auch keine Daten verloren, oder aehnliches. Viel mehr ist es so, dass die Performance meiner Festplatten am VIA Controller bes- ser ist als am externen Promise-Controller (selbst getest-

Kann ich für mich so nicht bestätigen. Allerdings ist die Aussage auf diversen Hardware-Seiten ja auch ganz klar: Abhängig von anderen Komponenten reagiert der Rechner mehr oder weniger heftig. Manche Leute kriegen ihre Kiste nichtmal sicher gestartet! Bei mir tritt das Problem nur unter Vollast auf. Da ich begeisterter 3D-Gamer bin und mir zu diesem Zweck relativ anspruchsvolle Hardware in der Kiste habe, wäre das für mich ein inakzeptabler Risikofaktor.

tet unter vergleichbaren Bedingungen) -- dieses Verhalten laesst sich auch auf einigen Hardwaretest-Seiten im Inter- net nachlesen. Der Promise Chip ist ein nettes Add-On (ich habe an ihm zwei aeltere Festplatten angeschlossen), aber auch nicht der ultimative Performancegewinn.

Du mußt auch UDMA-Platten anschliessen, sonst fährst du mit'm Porsche spazieren und hast hinten zwei Güllewagen dranhängen. ;-) Für interessierte: http://www.au-ja.de Gruß, Ratti

Hi! Thomas Hertweck wrote:

hdparm -t /dev/hdb (IBM; 60GB; UDMA100; VIA-Southbridge) 64 MB in 1.66 seconds = 38.79 MB/sec

Ich kann nicht bestätigen, daß der Promise sooo langsam arbeitet: (habe in dem Thread was von ~16MB gelesen) # hdparm -t /dev/hdf /dev/hdf: Timing buffered disk reads: 64 MB in 1.65 seconds = 38.79 MB/sec # cat /proc/ide/hdf/model IC35L040AVER07-0 (IBM; 40GB; Promise) Was wären für den Promise denn gute Werte? Muß ich mir Sorgen machen, weil ich ungefähr die selbe Performance habe wie Thomas an seinem internen Controller? Ach ja, mein Board ist auch ein Asus A7V... CU Martin

Hi! Thomas Hertweck wrote:

Martin Oehler wrote:

...

# hdparm -t /dev/hdf /dev/hdf: Timing buffered disk reads: 64 MB in 1.65 seconds = 38.79 MB/sec

Nein, nein, Deine Werte sind doch super. Nur, wenn ich meine IBM Platte vom VIA-Controller (siehe oben) an den Promise- Controller haenge, dann liefert hdparm bei mir deutlich gerin- gere Werte. Ob das nun ein generelles Problem des Promise ist, ob das an dem Zusammenspiel mit der IBM Platte haengt, ob das am Kernel liegt, oder ob sonst noch etwas die Ursache dafuer ist, weiss ich ehrlich gesagt nicht.

Hmm, ich benutze den Kernel 2.4.16 und habe sogar noch das Original-BIOS drauf (Rev. 1004D). Wovon ich etwas enttäuscht bin ist diese Option des sog. System-Tunings, was im Yast2 angeboten wird. Entweder bringt das sowieso nichts oder es nimmt mich auf den Arm. :-) Schalte ich das aus, erhalte ich knapp 1 MB weniger pro Sekunde (habe den anderen Wert mal oben stehen lassen): # hdparm -t /dev/hdf /dev/hdf: Timing buffered disk reads: 64 MB in 1.71 seconds = 37.43 MB/sec Tuning kann man sowas wohl nicht nennen... :-( CU Martin

On Sun, 13 Jan 2002, Thomas Hertweck wrote:

Nur, wenn ich meine IBM Platte vom VIA-Controller (siehe oben) an den Promise- Controller haenge, dann liefert hdparm bei mir deutlich gerin- gere Werte.

An was wurde bei dem Experiment denn die HD partitioniert? Ein Geometriekonflikt zwischen Partitionierung und dem was der Promise (nicht einstellbar) verwendet bremst gewaltig... -dnh -- 274: Nikoma-Newsserver Museum für prähistorische Gruppen. (Ulrich Mindrup)

Martin Oehler wrote:

Hi!

Thomas Hertweck wrote:

...

hdparm -t /dev/hdb (IBM; 60GB; UDMA100; VIA-Southbridge) 64 MB in 1.66 seconds = 38.79 MB/sec

Ich kann nicht bestätigen, daß der Promise sooo langsam arbeitet: (habe in dem Thread was von ~16MB gelesen)

# hdparm -t /dev/hdf /dev/hdf: Timing buffered disk reads: 64 MB in 1.65 seconds = 38.79 MB/sec

# cat /proc/ide/hdf/model IC35L040AVER07-0 (IBM; 40GB; Promise)

Was wären für den Promise denn gute Werte? Muß ich mir Sorgen machen, weil ich ungefähr die selbe Performance habe wie Thomas an seinem internen Controller? Ach ja, mein Board ist auch ein Asus A7V...

Nein, in beiden Fällen ist die Platte der begrenzente Faktor. Mehr ist da mit keinem Controler rauszuholen. -- Markus Kossmann markus.kossmann@inka.de

Am Freitag 11 Januar 2002 19:58 schrieb Ratti:

Hallo,

Ratti:

...

...

Am schnellen Promise hängen zwei Platten und die DVD. Eine der Platten unterstützt DMA Mode 4, die ander Mode 5.

David Haller:

...

DMA oder UDMA? (DMA = Multiword DMA sind die DMA Modi die bis 16.6 MB/s gingen, aber dabei (im Ggs. zu PIO) die CPU entlasteten ;)

UDMA. Eine hat 66 (Mode 4), die andere 100 (Mode 5). Da sie beide an der gleichen Strippe hängen, werden sie sich wohl auf 4 geeinigt haben. (Ich will das nicht ändern, sonst wäre eine zusammen mit dem DVD-Laufwerk, das wäre wahrscheinlich die schlechtere Lösung)

...

...

CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=60074784

^^^^^^^^^^^ Schon mal ueberlegt, in Zukunft 255 Koepfe zu verwenden? (Modus im BIOS manuell auf "LBA" statt auto einstellen ;)

Bringt das was ?

Ich glaube nicht, Meine 2 40-er IBM laufen auch so -> ohne Probleme. hdparm -t bringt auf beiden Platten zw. 32 und 33 MB/s.

Es ist gut möglich, das du Recht hast:

...

...

Festplatte /dev/hde: 255 Köpfe, 63 Sektoren, 3739 Zylinder

Huch? Jetzt doch 255 Koepfe? Nicht gut. _Kann_ Probleme geben. Laesst sich aber halt (s.o.) nicht ohne komplette Repartitionierung beheben.

Oh, ach ja, halt, die HD haengt am Promise, richtig?

Kann's sein, dass die HD an einem anderen Controller partitioniert wurde???

...das ist nämlich möglich. Ich habe das Asus A7V-Board und bin von dem Bug im Via-Chipsatz betroffen. Jedesmal beim DVD-gucken stürzte der Rechner ab und die Windows-Partition war komplett weg. :-((( Daher habe ich möglichst viel an den Promise gehängt, um von "normalen" AT-Bus wegzukommen. Darum hängt auch das DVD-Laufwerk dort und nicht woanders. Ich glaube, ich kauf mir gegen die Winterdepressionen einfach mal eine neue Platte.

...

Aha. Es muesste also udma4 (100 MB/s) sein, oder? Ein hdparm -t Wert von > 20 MB/s ist IMO ok. Lass dabei doch mal ein top laufen (am besten auf der Konsole in init 1 oder so, und sonst nix)...

Ich hatte schon Werte gepostet, wahrscheinlich überschneiden sich die Mails. Das sieht für mich ganz OK aus.

Auf dem Rechner habe ich ja auch ein Windows drauf. Im direkten Vergleich ist die Linux-Installation einfach "zäher". So simple Sachen wie "swappt dauernd" oder "Platte lahm" scheinen es nicht zu sein, die Anzeigen sehen OK aus.

Ich beschreibe mal mein "Feeling", die Werte sind nicht gemessen, sondern gefühlt: :-)

Das müssen keine großen Zugriffe sein, 4-5 MB da blitzt kaum die LED auf, dauert logischerweise aber länger als direkt im Speicher und dann "fühlt" man das.

Mein Eindruck geht dahin, daß die Verteilung der Rechenzeit einfach schlecht ist. Ich starte z.B. "convert" mit ordentlich was zu tun, und der Prozess braust mit Volldampf los. Hole ich jetzt ein anderes Fenster in den Vordergrund, hat das erst mal gar keine Ressourcen, es dauert einige Sekunden, bis dem System klar ist, daß es hier von 95:5-Aufteilung auf 50:50 runter muß. Starte ich die nächste Anwendung - wieder das gleiche. Haben sich die Anwendungen eingependelt, geht alles prima. Hatte eine Anwendung nix zu tun, wird sie "geparkt" und ist dann erst mal wieder lahm. Das stört mich sehr, wenn diese Anwendung z.B. KDE ist.

Könnte am SWAP liegen, wie sieht es denn da aus ? Ich kenne das von meiner Kiste das is' Athlon 800 mit 256 MB StarOffice Kmail Mozilla Organizer .... da füllt sich der Speicher ziemlich schnell, insbesondere bei den KDE-Apps. Ich verwende den Windowmaker, und der ist noch um einiges sparsamer als KDE. Wenn er dann den Prozess in den SWAP verdrängt hat, und Du es wieder nutzen willst, muß er es ja erst wieder von der Platte in den Speicher bringen, das dauert dann etwas

Es ist gut möglich, daß ich das einfach von Windows anders gewohnt bin, wenn ich da ein Hintergrundfenster nach vorne hole, ist es sofort da, es

Naja dort giebt es das auch, wenn der Speicher knapp wird wird geswappt.

gibt keine Verzögerungen oder sichtbare Redraw-Verzögerungen. Ich nehme mal an, daß Windows (Da auch dort die Rechenzeit nicht vom Himmel fällt) immer eine "Reserve" behält. Vielleicht kann man auch Linux so konfigurieren? Mir ist es egal, ob eine Grafik 2 Minuten konvertiert oder 2 Minuten und 20 Sekunden, aber mich stört es, wenn ich auf ein Hintergrundfenster klicke und es gibt eine Verzögerung von einer halben Sekunde beim "Nach-vorne-holen".

Ich glaube, ich stöpsel trotzdem noch mal RAM dazu.

Is immer gut :)

Ach so, das Kernelupdate hat gefühlsmässig was gebracht, danke an die Tipgeber.

Hatte bei mir auch einiges bewirkt, der 2.4.17 scheint doch um einiges besser zu laufen als der original SuSE 2.4.10.

...

PS: Deine Zeilen sind zu lang und deine Msg-Id ist noch ungueltig, hatten wir das Thema nicht schonmal? Kannst dich ggfs. nochmal per PM melden ;)

Machen wir per PM :-)

Gruß, Ratti

Mirko -- +--[ Mirko Richter (RHCE) ]------------------------+ | Networks & Communicationsystems | | Ernst-Thaelmann-Str. 5, D-06774 Soellichau | | E-MAIL: m.richter@ngi-box.de | | Tel. +49/(0)34243/3369-50 \\\\ | | Fax. +49/(0)34243/3369-28 (O O) | +-----------------------------------oOOo-(_)-oOOo--+

Hallo David, hallo Liste! am Samstag 12 Januar 2002 01:10 schrieb David Haller:

On Fri, 11 Jan 2002, Mirko Richter wrote: ["Bringt" Partitionierung mit 255 im LBA-Modus (im BIOS) statt mit 16 K. was?]

...

Ich glaube nicht, Meine 2 40-er IBM laufen auch so -> ohne Probleme. hdparm -t bringt auf beiden Platten zw. 32 und 33 MB/s.

Sorry, mit Performance hat das nichts zu tun... (s. die anderen Mails hier -- hier will ich nur weiteren Missverstaendnissen vorbeugen ;)

-dnh

Ich habe für einen Proxy auch mal so ein ASUS-Board mit ViA Chip (genauen Typ weiß ich im Moment leider nicht) verwendet, damals dachte ich noch naja so ein Promise ist nicht schlecht und habe die Platten (2x 60GB-7,2krpm) an den Promise gehägt, jede an eimen Kanal. Aber mit Geschwindigkeit war nur Pustekuchen, die eine lieferte ~16MB/s , die andere knapp 20, trotz idedma u.s.w., das war mir dann doch einwenig wenig. Insbesondere der Unterschied zw. den beiden Platten war mir nicht geheuer, waren es doch die gleichen Modelle und hatten auch die gleichen Einstellungen. Anschließend hab ich die Platten zusammen an den 2.IDE-Kanal vom ViA, am ersten hing ja schon die 30-er Systemplatte (brachte ~30MB/s), und siehe da beide Platten lieferten auf einmal 38MB/s. Warum der Promise so langsam war, weiß ich nicht, ich kann es mir nur damit erklären, daß das Treiber-Modul nicht gerade optimal ist. Es gab irgendwann in der ct' mal ein Testbericht über den Promise, wo er z.B. unter Win95/98 eine sehr gute Performace hatte und unter NT ziemlich miserabel abschnitt. Vielleicht ist Ratti's Problem auch eine "Sammlung" aus mangel an Speicher, SWAP-Verhalten, dem Promise und ... MfG Mirko -- +--[ Mirko Richter (RHCE) ]------------------------+ | + Netzwerke, Kommunikation, Computer, Service | | + Diskless Linux-Systeme | | + EPROM + FLASHROM Programmierung | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | Mirko Richter | | Networks & Communicationsystems | | Ernst-Thaelmann-Str. 5, D-06774 Soellichau | | E-MAIL: m.richter@ngi-box.de | | Tel. +49/(0)34243/3369-50 \\\\ | | Fax. +49/(0)34243/3369-28 (O O) | +-----------------------------------oOOo-(_)-oOOo--+

Hallo und guten Morgen, Ratti:

...

...

...

Am schnellen Promise hängen zwei Platten und die DVD. Eine der Platten unterstützt DMA Mode 4, die ander Mode 5.

David Haller:

...

...

CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=60074784 ^^^^^^^^^^^ Schon mal ueberlegt, in Zukunft 255 Koepfe zu

David Haller:

Achso: CurSects < 0 laesst mich auch noch die Stirn runzeln... (und sei's ein Bug in hdparm wg. "zu kleiner" Variable).

Das übersteigt meine Kompetenz. Zur Vorgeschichte der Platte: Der VIA-Bug hat mir mehrfach die Partitionstabellen zerschossen, sodaß immer die erste Partition zerballert war. Selbst formatieren war nicht genug, man mußte sie löschen und neu anlegen. Daß der Rest immer zu retten war, heisst natürlich nicht, daß er 100%ig OK ist. Ich werde also einfach mal eine neue Platte kaufen, sie zur Systemplatte machen, das System rüber-tar-en und mal gucken. Da ich z.Zt. drei Systeme auf dem Rechner habe (Suse, Win2K, WinXPlosive) ist einfach alles randvoll. Burps. ;-) Da ich gerade von Windows zu Linux wechsle, habe ich kein Backup und werde auch keins machen, die Datenmengen sind einfach zu riesig. Sobald ich ganz sicher bin und z.B. meine Outlook-Express-Mailbase und die Windows-Software wegschmeissen kann, wird das alles wieder überschaubar, und dann wird auch wieder gebackupt. Meine Software ist natürlich gesichert, nur das ganze Gerödel nicht, was so rumliegt. ;-)

...

Ich habe das Asus A7V-Board und bin von dem Bug im Via-Chipsatz betroffen. Jedesmal beim DVD-gucken stürzte der Rechner ab und die Windows-Partition war komplett weg. :-(((

Hm. War das nicht so, dass das nur bei "gleichzeitiger Belastung" der beiden IDE Kanaele zuschlug? Falls ja, haenge doch mal die mit dem (laut fdisk) 255-Koepfe-Schema partitionierte HD wieder an den Onboard- Controller... Ein Backup hast du doch, oder?

Schlimmer. Der VIA-Bug schlug zu bei viel Last auf dem Bus. Das kann man am einfachsten erzeugen, indem man ordentlich mit IDE rumhühnert (Deswegen war auch immer alles nach dem DVD-angucken weg), es reicht aber auch schon ein IDE-Kanal plus 100MB/s-Netzwerk, und ich habe natürlich beides. ;-) Bei mir kam verschärfend eine Soundblaster-LiveValue dazu. Diese Karten haben auch einen Bug, der passt zum VIA-Bug wie Bruce sein Fuß aufs Auge: Sie erzeugen unnötig Traffic auf dem Bus. Das Resultat sind falsche Schreiboperationen auf der Platte. Autsch. Daher:

Wenn du das machst, kopiere (egal wie lahm) am besten alles von der alten HD auf die neue, und repartitioniere die (alte) HD komplett. So sollte sich der Geometrie-Konflikt beheben lassen. Anschliessend kannst du ja die Daten wieder zurueckkopieren...

...werde ich garantiert niemals wieder eine Platte an meinen internen Bus hängen. "Langsam" wäre hier nicht das Problem, sondern "kaputt". Da hängt nur der Brenner, und ich bin etwas altmodisch: Während ich brenne, lasse ich den Rechner in Ruhe, also vertretbares Risiko.

Achso: Mach erstmal (s.u.) eine laengere Beobachtung mittels top...

Habe ich inzwischen. Die Werte sind soweit anständig, die Standardprobleme "zu wenig RAM" und "kein DMA" sind m.E. ausgeschlossen. Ich denke mal - zu den 256 MB nochmal 128 zustecken wir noch etwas rausholen - die Platte nochmal ordentlich zu plätten wird was bringen - Kernel-Update hat bereits ordentlich was gebracht (jetzt 2.4.16-4GB)

AFAIK nein. (und Windows ist da "eigentlich" auch nicht schneller, nur wendet es halt ein paar Tricks an, die die GUI bevorzugen, AFAIK). Ich sach nur "a la IE" ;)

Tja... :-) Ja, wahrscheinlich kommen da einfach subjektive Erfahrungen zu tragen, z.B. daß mein mozilla/win sich bereits beim Start in den Hintergrund geladen hat und auf URL-Klick "sofort" da war, während das "echte" Laden unter Linux jedesmal 5 Sekunden dauert. Und die Speicherverwaltung von Programmen wie Photoshop ist wahrscheinlich einfach besser als die von diversen Linux-Hobbyprogrammierern... ich will da um Himmels willen keinen Schlecht machen, da sitzen bei Adobe halt den ganzen Tag Leute und feilen für Geld an sowas rum, wenn es da nicht "fixer" würde als ein Wochenend-Spaßprojekt, dann müsste man die Leute feuern. ;-)

...

Ach so, das Kernelupdate hat gefühlsmässig was gebracht, danke an die Tipgeber.

Welcher laeuft denn nun bei dir? 2.4.17?

-16, s.o. war das neueste, was ich bei Suse gefunden habe. Wie erfahrt ihr eigentlich alle, daß es einen neuen Kernel gibt, ob der was taugt und wann man updaten sollte? Ich mache hier immer fleissig YOU, aber den Kernel hatte ich völlig vergessen. Gruß, Ratti