VOICE Homepage: http://www.os2voice.org |
[Vorherige Seite] [Nächste Seite] [Artikelübersicht] |
September 2000
editor@os2voice.org
Von Christian
Hennecke ©September 2000
The OS/2 Files: http://www.os2world.com/os2files/ In diesem Artikel erwähnte Dateien und Webseiten: OS/2 Warp 4 Capacity Planning and Performance Tuning Guide - http://www.software.ibm.com/os/warp/performance/w4tuning.html |
Es ist wieder Zeit, einen Gang zuzulegen. Diesen Monat werfen wir einen Blick auf die Leistung des Grafiksubsystems und einige Optimierungen für die GUI. Aber damit nicht genug! In den letzten Wochen gab es in den Newsgruppen der comp.os.os2.* Hierarchie diverse Threads, in denen über Probleme mit hohen CPU-Lasten bei DOS- und Win-OS/2 Sitzungen diskutiert wurde. Der zweite Teil dieses Artikels enthält einige Hinweise, um diese Probleme zu beseitigen oder wenigstens zu mildern, sowie ein paar allgemeine Betrachtungen zu DOS- und Win-OS/2 Sitzungen.
Nun noch ein Hilferuf: Der letzte Teil dieser Serie im nächsten Monat soll sich mit dem Drucken unter OS/2 und den Netzwerkkomponenten beschäftigen. Da ich jedoch ein relativer Netzwerk-Neuling bin, sind meine Kenntnisse über mögliche Optimierungen hier eher gering. Falls Sie also Tips hierzu haben oder undokumentierte Features kennen, senden Sie mir bitte eine Nachricht. Informationen über Netzwerkdrucker sind ebenfalls willkommen, da diese anscheinend nicht einfach einzurichten sind. Vielen Dank!
Dieser Artikel ist Teil einer Serie über Verbesserungen des OS/2 Systems, die im VOICE Newsletter veröffentlicht wird. Die Artikel der letzten Monate beschäftigten sich mit der Leistung von CD-ROM Laufwerken und Festplatten, mit dem Multitaskingverhalten und der Stabilität des Systems, sowie mit Speicherverbrauch. Die englischen Versionen sind über die VOICE Homepage unter der URL http://www.os2voice.org/newsletters.html erhältlich. Die gesamte Serie steht ebenso auf meiner Homepage Die OS/2 Akten - http://www.os2world.com/os2files/ in der Sektion "Tuning" zu Verfügung.
Alle Tips sind, soweit nicht anders erwähnt, auf alle OS/2 Warp Versionen anwendbar. Dabei wird auch auf alte, langsame Rechner eingegangen, weswegen einige Tips auf modernen Maschinen nur geringe Verbesserungen erzielen dürften. Möglicherweise enthalten die Artikel dieser Serie Fehler oder Auslassungen, die ihr System ins Nirwana befördern können. Ich empfehle deshalb dringend, ein Backup zu erstellen, bevor sie an ihren Systemeinstellungen herumfummeln. Ich hab' sie gewarnt.
Die in diesen Artikeln präsentierten Informationen wurden aus diversen Quellen zusammengetragen. Ein größerer Teil ist eine Übersetzung des Dokumentes "How to Supercharge OS/2 Warp" von Richard Oliver Kut aus dem Jahre 1996, das ich auf diese Weise fortzuführen gedenke. Ich danke IBM für das Dokument namens OS/2 Warp 4 Capacity Planning and Performance Tuning Guide und die Top Tips to Improve OS/2 Warp Version 4 Performance, die sich ebenfalls als sehr hilfreich erwiesen haben und noch einige zusätzliche, sehr detailllierte Informationen enthalten. Außerdem finden sich hier die Ergebnisse persönlicher "Experimente" wieder, wie auch Hinweise Bekannter und natürlich all der hilfsbereiten Leuten aus den OS/2 Gruppen des Usenet. Eine weitere wertvolle Quelle war das "OS/2 Warp 4 Kompendium" von Olaf Koch.
Wenn es um die Beschleunigung der Grafikdarstellung geht, sind die wichtigsten Dinge die verwendete Auflösung, Farbtiefe und ein guter Treiber. Allgemein gilt, daß mit der Anzahl Pixel, die ihre Grafikarte darstellen muß, auch die dafür notwendige Zeit und die benötigte Rechenleistung steigen. Wenn sie also mit einer Auflösung von 800x600 leben können, dürfen sie eine bessere Leistung erwarten, als wenn sie 1024x768 oder höher auswählen. Zudem verhält sich die Schnelligkeit der Grafikdarstellung umgekehrt zur verwendeten Anzahl Farben. Wenn sie also nicht unbegingt 16,7 Millionen Farben (24 oder 32bit Farbtiefe) benötigen, benutzen sie weniger. 65335 Farben oder 16bit Farbtiefe werden schneller dargestellt und ihre Augen werden den Unterschied nicht bemerken.
Anmerkung: Leider gibt es kaum noch Firmen, die vernünftige OS/2 Treiber für ihre Grafikkarten anbieten. Seitdem ELSA den OS/2 Markt verlassen hat, ist eigentlich nur noch Matrox zu nennen. Wenn man berücksichtigt, daß heutzutage die Treiber die Hauptursache für Geschwindigkeitsunterschiede sind (meine Matrox G400 bietet praktisch die gleiche Leistung bei 800x600 und 1600x1200 Auflösung), ist das schon sehr ärgerlich.
Glücklicherweise begann die Firma Scitech Soft 1999, ihr Produkt Scitech Display Doctor nach OS/2 zu portieren. Dabei handelt es sich um einen universellen Grafiktreiber, der beschleunigte, Plug&Play-fähige Treiber für die meisten Grafikchipsätze auf der Erde bietet. Dazu kommen z.B. noch benutzerdefininierbare Grafikmodi und die Möglichkeit, die Bildwiederholfrequenz während des Betriebs zu wechseln. Laut Sysbench (ein Benchmarkprogramm für OS/2) erreicht meine Matrox G400 mit dem Display Doctor fast die doppelte Geschwindigkeit wie mit dem Matrox Treiber. Ein Test mit einer Matrox G100 ergab sogar einen noch wesentlich höheren Vorsprung. Dieser Treiber ist ein kommerzielles Produkt, das sich momentan noch im Beta-Test befindet, aber bereits bei vielen im täglichen Einsatz ist. IBM hat inzwischen eine abgespeckte Version mit weniger Auflösungen und geringeren Wiederholraten (max. 85Hz) lizensiert, die alle OS/2 Nutzer gratis nutzen können. Sie ist über das Device Driver Pak On-Line erhältlich.
Falls sie einen Intel Prozessor benutzen, können sie diesen Abschnitt überspringen. Wenn sie jedoch einen AMD K6-2 oder K6-III mit CXT Core benutzen, sollten sie weiterlesen.
Diese Prozessoren bieten Funktionen namens Write Allocation und Write Combining. Durch sie kann die Geschwindigkeit beim Datentransfer in den Grafikspeicher und allgemeinen Schreiboperationen in den Speicher erheblich erhöht werden, allerdings müssen diese Funktionen angeschaltet werden. Unglücklicherweise wird dies vom BIOS der meisten Motherboards versäumt und muß dann von einem Treiber durchgeführt werden. Meines Wissens ist diese Funktion in jedem Grafiktreiber für Windows enthalten, aber unter OS/2 ist der Scitech Display Doctor der einzige, der sie beherrscht.
Wer den SDD nicht benutzt, steht jedoch nicht ganz mit leeren Händen da. Mehrere Entwickler haben Freeware Treiber geschrieben, die beim Bootprozeß die Features aktivieren. Ich empfehle das Paket setup4k6 von Cornel Huth, da es auch ein kleines Programm enthält, welches sehr hilfreich bei der Bestimmung der Parameter ist, die dem Treiber übergeben werden müssen. Problematisch ist, daß die Startadresse des Framebuffers angegeben werden muß. Bei Matrox Karten sollte dies angeblich sehr einfach sein, da das MGA Settings Programm die Adresse als Board mapping auf der Seite Information ausweist. Das ist leider falsch! Benutzen sie diesen Wert nicht!
Besorgen sie sich stattdessen das Freeware Tool DIVETEST. Starten sie es, wählen sie den DIVE Reiter und klicken sie Query Caps. Nun sollten sie den richtigen Wert im Feld Starts at: unterhalb der Zeile Get Framebuffer Information entnehmen können. Benutzen sie diesen Wert, um die Parameter für den Treiber zu bestimmen. Nach dessen korrekter Installation stiegen die von Sysbench gemessenen DIVE-marks der Matrox G400 von 80.613 auf 117.665 und damit auf den mit dem SDD erreichbaren Wert. Auf die normale Grafikdarstellung hat dies keinen Einfluß. Ein letzter Stolperstein: Deaktivieren sie EnDIVE, andernfalls sinkt die Leistung. Da die EnDIVE Implementation bei den meisten Grafiktreibern fehlerhaft ist, werden sie kaum Funktionalität vermissen.
Auch Bitmap-Hintergründe machen sich in Bezug auf die Leistung der Grafikdarstellung bemerkbar. Sie mögen sehr schön auf ihrer Arbeitsoberfläche oder in Ordnern aussehen, verbrauchen aber Speicher und vor allem Prozessorleistung. Am besten sparen sie sich solche Bilder für den Hintergrund, der beim Sperren angezeigt wird.
Im gleichen Zusammenhang ist die Verwendung von Farben der gemischten Farbpalette zu nennen. Diese werden langsamer dargestellt, als Farben der reinen Farbpalette. Dieser Effekt tritt jedoch bei schnellen Rechnern in den Hintergrund.
Bedenken sie, daß auch Mauszeiger Bitmaps sind. Abhängig von Stil und Größe der Mauszeiger werden also unterschiedliche Mengen Speicher genutzt. Am besten benutzen sie kleine schwarz-weiß Zeiger. Damit können sie auch die Verlangsamung und das Flackern, die bei DIVE Programmen auftreten können, verhindern. Außerdem sollten sie den Komet-Cursor ausschalten, da auch dieser zusätzlichen Speicher und Prozessorleistung verbraucht.
Halten sie die Anzahl offener Fenster gering. Wenn sie nicht benötigte Fenster schließen oder minimieren, wird der Bildschirm schneller berechnet. Der Inhalt von Ordnern wird im ein- oder zweispaltigen Format schneller angezeigt, als im Standard "wie plaziert". Dies können sie auf der Notizbuchseite Anzeige der Ordnereinstellungen ändern. Außerdem sollten sie für die Anzeige in Ordnern eine kleine Bildschirmschrift verwenden und keine Type1- oder Truetype-Schriften.
Die Anzeigegeschwindigkeit von Fenstern kann durch das Ausschalten der Fensteranimation (die vor dem Fenster erscheinenden Rechtecke o.ä.) ein wenig erhöht werden. Rechtsklicken sie dazu auf die Arbeitsoberfläche und wählen sie Systemkonfiguration aus dem Kontextmenü. Öffnen sie nun das System Objekt. Auf der Notizbuchseite Fenster können sie nun die Animation deaktivieren.
Ein weiterer Hinweis betrifft die Kontextmenüs der Ordner, die beim Rechtsklick mit der Maus erschienen. Wenn man weiß, wie man auf andere Weise (z.B. Drag&Drop) verschiebt, kopiert, eine Referenz erstellt, sucht usw., können die umfangreichen Einträge schnell auf die Nerven gehen. Um diese überflüssigen Einträge unter Warp 3 loszuwerden, fügen sie der CONFIG.SYS die Zeile
SET MENUSTYLE=SHORT
hinzu und starten sie das System neu. Wenn sie Warp 4 besitzen, öffnen sie das Objekt System in der Systemkonfiguration, gehen sie zum Reiter Menü und wählen sie Kurze Menüs. Dort können sie auch die Option Menüleisten für Ordner deaktivieren und damit etwas Platz auf dem Bildschirm sparen. Alle normalerweise in der Leiste enthaltenen Einträge finden sich auch im Kontextmenü des Ordners wieder.
Eine komfortablere Möglichkeit, die Menüs anzupassen, bietet XFolder/XWorkplace. Dort können die gewünschten Einträge in einem Notizbuch einzeln aktiviert oder deaktiviert werden.
Wenn sie Veränderungen am Inhalt eines Ordners vornehmen, z.B. durch Löschen einer Datei, so wird das System die Ordneransicht innerhalb einer gewissen Zeitspanne automatisch auf den neuen Stand bringen. Bei Ordnern mit vielen Objekten kann dies einige Zeit dauern, insbesondere wenn die Option Sortierfolge beibehalten aktiv ist und/oder sie die Detailansicht benutzen. Indem sie
SET AUTOREFRESHFOLDERS=NO
zu ihrer CONFIG.SYS hinzufügen, können sie dieses Verhalten abschalten. Allerdings muß dann der Ordner geschlossen und wieder geöffnet oder Sofort aktualisieren aus dem Kontextmenü selektiert werden, damit die Anzeige des Inhaltes angeglichen wird.
Der Begriff, den jeder mit Computergrafik assoziiert, ist "Bildschirmschoner". Der in OS/2 eingebaute kann auf der Seite Sperren der Einstellungen der Arbeitsoberfläche aktiviert werden. Es gibt eine Reihe weiterer Optionen, darunter Automatisch sperren und Beim Starten sperren. Beide sind aus der Sicht des Speichersparers keine gute Einrichtung. Sie zu aktivieren, wird weniger die Grafikausgabe bremsen, aber einigen Hauptspeicher verbrauchen, der anderen Anwendungen nicht zur Verfügung steht. Die aktivierte Option Beim Starten Sperren verlängert außerdem die für das Hochfahren benötigte Zeit. Das ist sicher nicht das Ende der Welt, aber ein weiterer Beitrag zur Verlangsamung ihres Systems. Benutzen sie stattdessen besser das Warpcenter oder die Klickstartleiste, um ihren Rechner zu sperren.
Eine letzte Sache, die Einfluß auf die Geschwindigkeit der Grafikdarstellung nimmt, ist das Kopieren des Grafik-BIOS aus dem langsamen ROM ins schnellere RAM. Dies wird auch als "BIOS Shadowing" oder "Spiegeln" bezeichnet. In den BIOS Einstellungen ihres Rechners werden sich irgendwo Einträge zum "Shadowing" des Grafik- und des System-BIOS finden. Wenn sie diese gefunden haben, schalten sie sie aus. Allerdings, AUS! Der einfache Grund dafür ist, daß OS/2 eigene eingebaute Routinen hierzu besitzt. Wenn sie also die Routinen des System-BIOS nicht auschalten, kann es sein, daß der Rechner effektiv gebremst wird, da der Vorgang zweimal ausgeführt wird. Zudem geht das Shadow-RAM ihrem verfügbaren Hauptspeicher verloren!
Mit den Einstellungen EMS_MEMORY_LIMIT, XMS_MEMORY_LIMIT und DPMI_MEMORY_LIMIT läßt sich direkt die Menge des einer Sitzung maximal zur Verfügung stehenden Speichers beeinflussen. Maximal heißt jedoch nicht, daß dieser Speicher dem übrigen System automatisch nicht mehr zu Verfügung steht. Der Speicher wird nur dann der Sitzung zugeteilt, wenn das Programm ihn auch tatsächlich anfordert. Es lohnt sich also nicht, bei einem Programm, daß niemals mehr als 1MB verbraucht, die Einstellungen auf 1MB einzuschränken. Interessant wird diese Einstellung dann, wenn Programme automatisch große Teile des zu Verfügung stehenden Speichers nutzen, aber auch mit weniger Speicher sehr gut zurechtkommen.
Windows-Programme benötigen keinen EMS-Speicher. Sie können also den Parameter EMS_MEMORY_LIMIT auf Null und EMS_FRAME_LOCATION auf NONE setzen. Durch das Abschalten der EMS-Unterstützung kann etwas Speicher gespart werden.
Win-OS/2 bietet die Möglichkeit gleichzeitig betriebene Programme entweder in einer gemeinsamen Sitzung oder in getrennten Sitzungen laufen zu lassen. Beide Betriebsmodi besitzen spezifische Vor- und Nachteile.
Bei getrennten Sitzungen wird für jede Sitzung eine komplette eigene Win-OS/2 Umgebung gestartet. Insofern ist natürlich der Speicherverbrauch erheblich größer als bei einer gemeinsamen Sitzung. Dafür wird jedoch der Absturz eines Win-OS/2 Programmes nicht den Absturz der anderen Win-OS/2 Programme, die in der selben Sitzung laufen, nach sich ziehen. Zudem sind sie in der Lage, für jede der getrennten Sitzungen eigene Einstellungen zu verwenden. Damit können dann auch Programme gleichzeitig verwendet werden, die sich gegenseitig ausschließende Einstellungen erfordern.
Für Schriften gelten grundsätzlich die gleichen Empfehlungen wie für "normales" OS/2.
Die Verwaltung von Schriften geschieht unter OS/2 und Win-OS/2 getrennt. Unter beiden System registrierte Schriften werden also beim Start einer Win-OS/2 Umgebung ein weiteres mal geladen und belegen nochmals Speicher. Andererseits bietet sich dadurch die Möglichkeit, eine Optimierung auf nur die jeweils benötigten Schriften vorzunehmen.
Zusätzlich bieten die Einstellungen für Win-OS/2 Sitzungen die Option WIN_ATM, mit der festgelegt wird, ob der Sitzung der Adobe Type Manager (ATM) und damit die Verwendung von Adobe Type1 Schriften zu Verfügung steht. Ist WIN_ATM auf ON gesetzt, werden der ATM und alle registrierten Type1 Schriften geladen. Bei getrennten Sitzungen wird dies auch pro Sitzung durchgeführt. Wenn sie also z.B. Aldus Pagemaker für DTP benutzen, sollten sie möglichst nur Adobe Type1 Schriften verwenden und den ATM für andere Programme, welche die Schriften nicht benötigen, deaktivieren.
Eines der unangenehmsten Probleme mit vielen DOS- und einigen Windows-Programmen macht sich durch das Ansteigen der CPU Last auf 100% - meist gleich nach dem Start - bemerkbar. Die Ursache liegt darin, daß DOS Programme in einer Single-Tasking Umgebung wie DOS nie die Ressourcen mit anderen Programmen teilen mußten und die Entwickler deshalb für die Abfrage von Eingaben das sogenannte Polling verwenden konnten. Dabei werden bei Erwartung einer Eingabe ständig die Eingabegeräte sozusagen gefragt "Hast Du etwas für mich? Hast Du etwas für mich?". In wenigen Momenten zwischen zwei Tastendrücken kann ein Programm hunderte oder tausende Male die Tastatur abfragen. Dabei wird natürlich enorm Leistung verschenkt. Wenn dann tatsächlich etwas eingegeben wurde und das Programm dann wirklich arbeitet anstatt zu warten, sinkt die CPU Last und kehrt nach Beendigung der Berechnung wieder zu 100% zurück. Dieser Effekt ist auch bei schlecht programmierten Windowsanwendungen wie MS Money 2.0 zu beobachten. Das Problem ist hier, daß das Polling anderen Prozessen CPU-Zeit stiehlt, insbesondere solchen, die auf niedrigster Prioritätsstufe laufen (idle priority), wie z.B. der SETI@home Klient oder PMViews Laderoutine. Dies kann soweit gehen, daß andere Programme gar nicht mehr ausgeführt werden.
Was kann also dagegen getan werden? Leider ist diese Frage nicht ganz einfach zu beantworten. Es gibt verschiedene Lösungsansätze, die jeweils nur bei einer begrenzten Anzahl von Applikationen Wirkung zeigen. Einige Optimierungen können in den Sitzungseinstellungen vorgenommen werden.
Diese enthalten die miteinander verknüpften Optionen IDLE_SECONDS und IDLE_SENSITIVITY. Nachdem ein Programm eine Eingabeabfrage startet, wartet OS/2 den über IDLE_SECONDS eingestellten Zeitraum, bis die Leerlauferkennung gestartet wird. Der Standardwert ist 0 (Null), also beginnt die Erkennung sofort. Mit der zweiten Option wird ein Schwellenwert festgelegt, der von OS/2 benutzt wird um zu erkennen, ob ein Programm sich im Leerlauf befindet oder nicht. Wenn das Programm mit einer höheren Frequenz "pollt" als im Schwellenwert festgelegt, wird OS/2 es als im Leerlauf befindlich ansehen, seinen Anteil an der Rechenzeit reduzieren und diesen anderen Aplikationen zu Verfügung stellen. Durch Herabsetzen des Schwellenwertes sollte es möglich sein, einiges an CPU-Zeit zurückzugewinnen.
Eine etwas brutalere Möglichkeit ist das Setzen der Einstellung DOS_BACKGROUND_EXECUTION auf OFF. Bei dieser Einstellung wird die Ausführung eines Programmes gestoppt, sobald ihm der Fokus entzogen wird. Das Programm erhält erst wieder Rechenzeit, wenn es wieder in den Vordergrund gebracht wird. Natürlich ist das Programm nicht in der Lage, Berechnungen durchzuführen, solange es im Hintergrund ist, und wird nach wie vor anderen Prozessen Rechenzeit entziehen, wenn es im Vordergrund ist.
Falls die oben beschriebenen Methoden nicht erfolgreich sind, gibt es noch andere, die sie probieren können. Es exitieren ein paar TSRs, welche Rechenzeit der Sitzung, in der sie gestartet werden, abgeben können. Um sie zu laden, müssen sie über die AUTOEXEC.BAT Datei gestartet werden. Alle diese Helferlein können von Hobbes /pub/dos Verzeichnis und Peter Norloffs OS/2 BBS bezogen werden. Viele davon wurden für spezifische Applikationen geschrieben, aber OS/2 Time Slice Releaser (OSTSR), F4_35_CA und TAME sind allgemein verwendbar.
OSTSR ist nur für Programme interessant, die eine Anpassung für DesqView, eine alte DOS Multitaskingerweiterung, enthalten. OSTSR gaukelt den Programmen vor, in einer DesqView Umgebung zu laufen. Wenn diese nun einen Aufruf absetzen, um unbenutzte Rechenzeit an DesqView abzugeben, fängt OSTSR diesen ab und wandelt ihn in einen entsprechenden OS/2 Aufurf um. Die abzugebende Rechenzeit kann per Kommandozeile angepaßt werden. Probieren sie einmal OSTSR 8 in der AUTOEXEC.BAT. OSTSR ist Freeware.
F4_35_CA ist ein Freeware-Paket von Veit Kannegieser. Fügen sie einmal das enthaltene Programm F4_35_CA.COM ihrer AUTOEXEC.BAT hinzu und starten sie dann ein DOS- oder Win-OS/2-Programm, das Probleme bereitet. Leuchtet die Rollen- oder Scrollock-LED ihrer Tastatur auf, so kann F4_35_CA Rechenzeit freigeben. Näheres entnehmen sie bitte der Dokumentation in der Datei ENTPACK.DEU.
Die Herangehensweise des TAME Paketes ist etwas anderns und ähnelt mehr der OS/2 Prozeßverwaltung. Es überwacht die Aktivität des Programmes, daß in der selben Sitzung läuft und gibt Rechenzeit an andere Prozesse ab, wenn eine Leerlaufphase festgestellt wird. Zudem wird bei der nächsten Zuteilung von Rechenzeit eine weniger tolerante Einstellung verwendet. TAME bietet vielfältige Optionen, darunter einige, die bei der richtigen Konfiguration helfen. All diese zu dokumentieren, würde den Rahmen dieses Artikels sprengen. TAME /TINY /I 9 /TS OS/2 hat sich jedoch als gute Voreinstellung bewährt. Laut Dokumentation ist TAME Shareware (US$20). Die neuste Version, die ich finden konnte, war 3.33 (eine Version 3.34 enthielt die identischen Dateien) aus dem Jahr 1996. Insofern ist nicht klar, ob man das Programm noch registrieren kann.
Die Programme können zusammen verwendet werden. Zudem können sie die Option DOS_AUTOEXEC benutzen, um verschiedene Startdateien zu verwenden, falls sie unterschiedliche Parameter für OSTSR oder TAME brauchen.
Damit wären wir für diesen Monat am Ende. Im nächsten Monat schließen wir die Serie mit einem Artikel zum Drucken und Netzwerken unter OS/2 ab. Nochmals: Falls Sie irgendwelche Hinweise zur Optimierung der Netzwerkkomponenten haben, lassen Sie mir diese bitte zukommen.
Artikelübersicht
editor@os2voice.org
[Vorherige Seite] [Inhalt]
[Nächste Seite]
VOICE Homepage: http://www.os2voice.org