Hallo zusammen.
Habe heute mal ein wenig mit den Handles in BBE herumgespielt. Angeblich sind ja nur 3500 möglich; mehr kann auch in den Voreinstellungen nicht eingestellt werden. Wenn ich aber den Wert in der geos.ini manuell eintrage, dann scheinen auch mehr zu funktionieren.
Zur Zeit habe ich den Wert auf 4090 erhöht; BBE läuft dann immer noch stabil. Ab einem Wert von 4100 läßt es sich bei mir nicht mehr starten. Kontrolliert habe ich den Wert mit dem Process Viewer. Da wird der Wert der verfügbaren und der belegten Handles angezeigt - und noch etliches mehr. Zwar habe ich 4090 Handles in der geos.ini eingetragen, angezeigt im Process Viewer werden aber nur 3741. Immerhin mehr als zuvor. [size=10] [/size]:D[size=10] [/size]
Außerdem habe ich den Eindruck, daß mein BBE einen spürbaren Geschwindigkeitszuwachs erfahren hat. [size=10] [/size]:D[size=10] [/size]
[size=10]Getestet habe ich das alles auf einem Lenovo Thinkpad T61 mit Doppelkernprozessor, 2,2 GHz und 2 GB RAM und auf einem DELL Latitude E6320 mit i5-Prozessor 2,4 GHz und 2 GB RAM - jeweils mit Linux Mint 18 als Hostsystem für dosemu. Auf dem Dell habe ich mit Mint 18 64 bit und dosemu2 getestet. Läuft wunnebar. [/size][size=10] [/size]
[size=10] [/size]
[size=10]
[/size]
Anzahl der Handles
-
Klingt interessant, probiere ich aus.
-
Ein paar Hintergrund-Infos: (Marcus möge mich korrigieren, wenn ich falsch liege)
Die Anzahl der Handles ist intern die Anzahl der Einträge der Handle-Tabelle. Jeder Eintrag ist 8 Byte groß (glaube ich, vielleicht sind es auch 16 Byte). Das bedeutet bei 4096 Handles a 8 Byte einen exakt 32 kByte großen Speicherblock. Der wird vom System in den Hauptspeicher geladen, wenn es auf die Handles zugreifen muss. 32 k sind schon ganz schön viel, das SDK sagt: mach deine Blöcke nicht größer als 8 k. Prinzipiell gehen auch größere Blöcke (ich nutze bei JPEG z.T. 48 k), aber die Chance, das ein großer Block nicht mehr in den freien Speicher passt ist natürlich höher.
Falls ein Handle-Eintrag 16 Byte schluckt ist der Block 64 k groß - dann ist eh Sense.Die magische Grenze liegt also bei 4096 (oder 4095, wenn man die Null mitzählt). Bei 4095 startet GEOS bei mir noch, bei 4096 nicht mehr. Spannend ist, dass GEOS meine 4095 wieder auf 3500 korrigiert, wenn es runterfährt. - Außer Spesen nichts gewesen.
Ich erinnere mich, das wir mit Marcus damals über das Thema gesprochen haben und es nicht so simpel ist, die Tabelle zu vergrößern oder zu teilen.
Hypothese: Wenn ein Handle-Eintrag 8 Byte groß ist könnte hier der gleiche "Bug" zuschlagen, der beim GEOS 2.x damals verhindert hat, dass es installiert wird, wenn mehr als 32MB Platz auf der Platte waren. Der Grund ist, dass der Datentyp "integer" (ganzzahling) in C von -32000 bis + 32000 geht. Zahlen größer als 32767 werden als negativ interpretiert (ja, das ist logisch und auch sinnvoll :-). Wenn dem so ist zeigen Handle-Nummern größer 4095 irgendwo ins Nirvana.
Gruß
Rainer -
Klingt interessant, probiere ich aus.
Hi Bernd.
Schon irgendwelche Erkenntnisse? -
Hi Bernd.
Schon irgendwelche Erkenntnisse?Ja.
- Habe statt der standardmässigen 3500 Handles kurz nach deinem Posting 4000 Handles per Hand in die GEOS.INI eingetragen. Der Wert bleibt seitdem beim Runterfahren erhalten, scheint also dauerhaft nutzbar zu sein.
- Mit Perf werden mir immerhin ca. 200 zusätzliche Handles angezeigt.
- Einen Geschwindigkeitszuwachs habe ich leider nicht bemerkt.
Bernd
-
Handles ebenfalls auf 4000 gesetzt. Geos.ini Viewer: 4000, Process Viewer: 3741, HandleMeter: 3741, GEOS-Modul in den Voreinstellungen: 3500. Prinzipiell bleiben mir die 4000 Handles beim Neustart erhalten; sobald ich aber deren Wert in den Voreinstellungen manuell zu erhöhen versuche und abspeichere, wird GEOS im laufenden Betrieb wieder auf 3500 gesetzt.
Nachtrag: Speed von 1600 auf 1800 gesteigert (1024x768, 64K). -
Nachtrag: Speed von 1600 auf 1800 gesteigert (1024x768, 64K).
Siehste, sag ich doch.
Allerdings habe ich nicht gemessen sondern nur "gefühlt".
sobald ich aber deren Wert in den Voreinstellungen manuell zu erhöhen versuche und abspeichere, wird GEOS im laufenden Betrieb wieder auf 3500 gesetzt.
Das ist bei mir auch so. Ergo: Nach manueller Änderung der Handles in der geos.ini diese in den Voreinstellungen niemals mehr korrigieren.
@Martin:
Wo hast du denn den geos.ini-Viewer her? -
Wo hast du denn den geos.ini-Viewer her?
Habe nachgeschaut: Freeware von Walter Loos. Weiß nicht mehr, wo ich den damals gefunden habe. Hänge ich an.
-
Ergo: Nach manueller Änderung der Handles in der geos.ini diese in den Voreinstellungen niemals mehr korrigieren.
Habe ich auch gemacht, wobei ich einkalkuliere, daß GEOS sich jetzt richtig aufhängen kann - also nicht mal ein KR-09, worauf ich eigentlich einen Anspruch habe.
-
Hallo zusammen
Wer Mut hat, kann sich den Wert 3741 "ein-patchen":
Ordner c:\ensemble\system\pref
Datei prefos.geoIn einem Hex-Editor den Hex-Wert "0D AC" durch "9D 0E" ersetzen (kommt nur einmal vor). Nun kann man im GEOS Voreinstellungs-Modul den Maximalen Wert von 3741 auswählen und auch speichern.
Zur Info:
Dez "3500" = Hex Big Endian "0D AC" = Hex Little Endian "AC 0D"
Dez "3741" = Hex Big Endian "0E 9D" = Hex Little Endian "9D 0E"Ein kurzer Test hat soweit bei mir funktioniert. Einzige Unschönheit ist, dass bei jedem Öffnen des Voreinstellungs-Modul der Wert "3700" angezeigt wird... Die Auswahl wird anscheinend auf 100 Handles genau gemacht. Bei 3740 wird dann 3700 gespeichert. 3741 aber als 3741.
Ich selber konnte aber keinen definitiven Speed-Zuwachs erkennen. Liegt wahrscheinlich daran, dass ich auf einem Notebook arbeite. Da gibt es durch die Stromspartechniken oft grosse Unterschiede (10 - 20%) bei Speed, trotz Netzbetrieb.
Gruss
Andreas -
Funzt; allerdings ist der Geschwindigkeitszuwachs nunmehr ebenfalls eingeschränkt. Ich belasse es bei dem Patch, werde aber manuell 4000 Handles einstellen. Erstaunlich, was die paar Einträge mehr ausmachen.
-
Ist es wirklich mit der manuellen Einstellung auf 4000 schneller als mit 3741 ?
Jedes Tool meldet doch 3741, auch wenn man hoehere Werte verwendet. Waere wirklich interessant, ob da alle Tools einfach einen fixen Oberwert vom System bekommen, obwohl mehr Handles vorhanden sind...
Ansonsten einfach mal den Patch auf den Hex LE Wert von 4000 setzen
-
Ansonsten einfach mal den Patch auf den Hex LE Wert von 4000 setzen
Dieser Wert ist bereits eingetragen. Wenn ich das richtig verstehe, lautet der Dezimalwert "4000" in Little Endian "34 30 30 30" - und das steht jetzt in meiner INI. Der "geos.ini Viewer" sagt ebenfalls "4000", die Voreinstellungen nach Deinem Patch hingegen "3741".
Und ja: GEOS läuft meßbar schneller (Speed bei 3500 = 1600, bei 3700(-41) = 1600/1700, bei 4000 = 1800).
Habe jetzt "4095" eingetragen. Kein Geschwindigkeitszuwachs. Hoffe auf schönere Abstürze. -
Der Dezimalwert 4000 ist in Hexadezimal "FA0". Big Endian "0F A0", Little Endian "A0 0F".
Little Endian "34 30 30 30" wäre nach meiner Rechnung Dezimal 808464436...
Die Umrechnung ist relativ einfach. Dezimalwert in Hexadezimal umrechnen und mit Nullen auf ganzzahlige Anzahl Stellen auffüllen. Das ergibt Big Endian. Danach immer 2 Stellen von rechts nach links nehmen und neu schreiben. Dann hat man Little Endian. Hört sich schwieriger an als es ist.
Noch ein Beispiel:
Dezimal "123456" ist Hexadezimal "1E240". Wir haben 5 Stellen (ungerade), also setzen wir noch eine Null vorne ran was Hexadezimal in Big Endian "01E240" ergibt. Nun immer 2 Stellen zusammen (was ja jeweils ein Byte ist) von rechts nach links neu schreiben und wir erhalten Hexadezimal in Little Endian "40E201".Intel verwendet in den CPUs immer Little Endian. Andere Prozessoren oder zum Beispiel in Netzwerkpaketen verwenden Big Endian.
-
Ich werde es bei dem manuellen Eintrag in der geos.ini belassen (4090), das Rumhacken im Code irgendwelcher geos-Dateien behagt mir nicht so.
Was Abstürze angeht... Bisher habe ich noch keine bemerkt - außer, daß das GEOS-System manchmal nicht komplett herunter fährt. Aber das war vorher auch schon so und Statistiken dazu habe ich nicht geführt. Definitiv kann ich mehr Dateien und Ordner öffnen, ohne daß das System abstürzt.
Was die Geschwindigkeit angeht, ist diese sicherlich vom verwendeten System abhängig. Auf meinem DELL mit i5-Prozessor und zwei (vier) Kernen läuft das alles sehr, sehr fluffig. -
Bei all dem bleibt die Frage unbeantwortet, wieviele Handles von den 4096 das System den einzelnen Anwendungen (oder deren Gesamtheit) zur Verfügung stellt.
-
Was mich völlig verwundert, warum die Anzahl der Handles überhaupt einen Einfluss auf die Geschwindigkeit haben können. So lange man noch nicht am Limit ist, also noch über tausend Handles unbenutzt sind macht es überhaupt keinen Sinn, dass das 500 oder 600 Handles mehr überhaupt irgend etwas ausmachen.
Sehr grüblerisch
Rainer -
Bei all dem bleibt die Frage unbeantwortet, wieviele Handles von den 4096 das System den einzelnen Anwendungen (oder deren Gesamtheit) zur Verfügung stellt.
Hi Martin.
Das kann man sehr schön mit dem Process Viewer sehen. Einfach auf einen der Einträge klicken und schon wird in einem Fenster dargestellt, wieviel Handles zugewiesen sind und welche Speicheradressen belegt werden.
Mich interessiert viel mehr, warum von den 4000 oder auch 4095 immer nur max. 3741 übrig bleiben, die dann wohl auch nur verwendet werden können. -
Das "System" selbst braucht auch Handles. Jede geladene Geode und Library (Kernel, Druckertreiber, Videotreiber ...) braucht Handles. Eines für die Datei selbst und für jede Code- oder UI-Resource auch mindestens eins. Da kommt ne ganze Menge zusammen.
Rainer -
Was mich völlig verwundert, warum die Anzahl der Handles überhaupt einen Einfluss auf die Geschwindigkeit haben können. So lange man noch nicht am Limit ist, also noch über tausend Handles unbenutzt sind macht es überhaupt keinen Sinn, dass das 500 oder 600 Handles mehr überhaupt irgend etwas ausmachen.
Sehr grüblerisch
RainerBevor das hier so stehen bleibt, habe ich den Speed bei 3500, 3700 und 3741 (4095) gemessen. Zuvor habe ich jeweils alles im Host abgeschaltet, was irgendwie stressen könnte (Netz und dergleichen). Ergebnis: tatsächlich war das System unter allen Voraussetzungen gleich schnell.
Keinerlei Gewinn. 
Aber vielleicht knackigere Abstürze, weil die von Rainer erwähnten Systemreserven jetzt nur noch 354 Handles ausmachen? 
