Seiten: [1] 
|
 |
|
Autor
|
Thema: Problem mit Systemauslastung (Gelesen 7022 mal)
|
Agent-J
Gast
|
Hi Leute, habe da ma n Problem bzw nen Verbesserungsvorschlag.
Andere Programme wie Smartie oder ka verbrauchen ca 1-3% Systemauslastung.
Bei mir liegt STLCD bei 3-18!! Zwar nur für wenige Augenblicke, aber das gibt mir doch schon zu denken (troz niedrigster Prozess Priorität)
Habe ich was falsch gemacht? Oder woran kann das liegen?
LCDSpeed=0
UpdateInterval=900
THX erstmal
|
|
|
|
|
Gespeichert
|
|
|
|
Klinkerstein
Gast
|
an der Priorität unter Windows solltest du am besten nicht herumdrehen. das geht in die hose.
Slebst auf meinem P2 100 (windows nt) lief es mit max. 2%
|
|
|
|
|
Gespeichert
|
|
|
|
Agent-J
Gast
|
Verstehe ich dann zwar net. Habe nen Athlon XP 2400+.
Die Prozessprio war schon von Anfang an so eingestellt.
|
|
|
|
|
Gespeichert
|
|
|
|
OlafSt
Global Moderator
Karma: +13/-0
 Offline
Geschlecht: 
Beiträge: 2138
Master of STLCD and LISA III
|
Ich geb mal etwas technisches zum Besten:
- Die Standardpriorität in Windows-Systemen liegt bei 8 (Die Bandbreite reicht von 0=Idle bis 15=Realtime). Alle normal gestarteten Programme (auch Smartie) laufen mit Prio 8. Daraus folgt, das sich diese Programme um die zugeteilte CPU-Zeit streiten müssen.
- STLCD stellt beim Programmstart Prio 5 für sich selbst ein. Dies ist somit gleichzeitig Basisprio für alle gespawnten Threads. Im Streit um die CPU-Zeit hält sich STLCD also raus.
- Alle anderen Threads laufen mit (BasisPrio-3)
- Beim IOWarrior wird ein Thread statt auf (BasisPrio-3) mit (BasisPrio+1) betrieben.
- Prio 0 wird mit Absicht nicht verwendet, denn Seti@home z.B. läuft ebenfalls mit Prio 0. Solche Programme würden STLCD also nie zum Zuge kommen lassen.
Durch diese Prioritätsverteilung ist gewährleistet, das STLCD niemals "normale" Programme zur Laufzeit verlangsamt. Das Gegenteil ist der Fall. Weiterhin stören Screensaver und ähnliches nicht die Anzeige auf dem LCD.
Das Ändern der Prios vom User bringt das ganze Timing zwischen den Threads durcheinander und ist, wie oben schon erwähnt, eigentlich vollkommen überflüssig.
Die hohe CPU-Last kann zustande kommen, wenn man Noritake-VFD's verwendet oder bei einer falschen Einstellung der $READDRV-Variablen (Log-File !), andere mögliche Ursachen sind mir nicht bekannt.
Prinzipbedingt ist die CPU-Last bei IOW-getriebenen LCD's ein Stück größer als bei Parallelen LCD's (so um die 2-6%), denn hier muß ein sehr komplexes Protokoll eingehalten werden, um überhaupt Daten zum IOW zu bekommen. Wenn es was nützen würde, hätte ich mich bereits bei den Designern des USB beschwert...
Weiterhin laufen Progs wie jaLCD's etc. "seriell" ab, die gesamte Last verteilt sich also über einen gewissen Zeitraum. STLCD dagegen besteht praktisch aus vier gleichzeitig aktiven Programmen, die hin und wieder einmal auch zugleich laufen, 99% der Zeit aber null Last verursachen.
In Langzeitmessungen über 24 und mehr Stunden liegt STLCD bei einem CPU-Verbrauch von etwa 0.8% (gemessen mit TaskInfo 5.0, 1800er Pentium4). Mein höchster Peakwert liegt hier bei 6%. Nebenbei gehen 99.2% der von STLCD verursachten CPU-Last auf das Konto des LCD's. Beim IOW verändert sich das ganze drastisch, hier gehen die 99% auf das Konto des USB.
Und wo wir gerade dabei sind: Die INI-Einstellung "UpdateInterval" dient NICHT als Intervall für die LCD-Aktualisierung (jedenfalls nicht direkt). STLCD ist nicht jaLCDs 
Das Updateinterval gibt an, in welchen Intervallen die intern gesammelten Daten aktualisiert werden. Die LCD-Anzeige wird immer aktualisiert, wenn sich die Anzeige verändert hat - ändert sich nix, wird auch nicht aktualisiert; ändert sich permanent etwas, wird entsprechend des UpdateInterval aktualisiert (darum nur indirekte Wirkung).
Für Neugierige hier einmal eine Übersicht der CPU-Last STLCD nach etwa 45 Minuten Laufzeit mit Standard-INI und IOWarrior-40:
STLCD.EXE: 3,65% (Gesamte CPU-Last des Programms in dieser Zeit)
__STLCD : 0,00% (GUI, nicht angezeigt)
__Thread : 0,00% (Thread für PIO-LCD's, schlafengelegt)
__Thread : 0,00% (Datenaufbereitung)
__Thread : 0,00% (Hilfsthread 1 für Datensammler, vom WinAPI)
__Thread : 3,56% (LCDWriter-Thread über USB)
__Thread : 0,00% (HilfsThread 2 für Datensammer, vom WinAPI)
__Thread : 0,10% (Datensammler)
__Thread : 0,00% (Hilfsthread 3 für Datensammler, vom WinAPI)
Als Peakwert taucht mal 9,37%, mal 12,5% auf. Die meiste Zeit steht da aber 0,00%.
|
|
|
|
« Letzte Änderung: Februar 22, 2004, 13:01:00 von OlafSt »
|
Gespeichert
|
Erstens: Lies was da steht. Zweitens: Denk drüber nach. Drittens: Dann erst fragen
|
|
|
Shark5060
Gast
|
kann ich nur bestätigen...
wenn ich mal wieder mit 3dsmax ein Bild render stört das stlcd schon gewaltig, da 3dsmax ja 99% Prozessorlast bracuht...
aber sonst hat noch nie ein game geruckelt wegen StLCD...
|
|
|
|
|
Gespeichert
|
|
|
|
|
|
EiRoGGe
Gast
|
Ich hab das Problem mit STLCD dass beim Betrieb Norton AV 2004 immer wie wild anfängt zu rechnen mit 50-80% cpu-last. kann sich das einer erklären? die 3-6% cpulast von STLCD stören mich nich aber dauerhaft um die 65% cpulast wegen eigentlich nix is arg 
Jemand ne Idee?
|
|
|
|
|
Gespeichert
|
|
|
|
|
|
|
|
Seiten: [1] 
|
|
|
|
|
weiß gar nich warum ich das mal eingeschaltet hatte.
