29.04.2020, 15:15
2. var8x8
============
Rechner: 10 Cores mit 20 logischen Prozessoren; 64GB RAM
Viewer: Firestorm 6.0.2.56680
Viewer: Singularity 1.8.9 (8324)
Die Viewer unterschieden sich nicht signifikant.
Rein lokaler Test um Upload als Flaschenhals zu umgehen.
Aufgrund der Testergebnisse mit der Var16x16 wird auf einen Test im Standalonemode verzichtet.
Grid Mode mit MariaDB
----------------------
1xCore MariaDB
3xCore Opensim.exe
1xCore Robust.exe
3xCore Firestorm
4x4 OARs = 16 Parzellen (8x8 = 64 Parzellen; Faktor 4)
110.000 Prims
4800 Skripte
11GB RAM --> 4x11GB = 44GB (hochgerechnet)
In Ruhe 50% CPU Auslastung
Avatar fliegt 50% CPU Auslastung
==> CPU_ges. 80%
Ergebnis:
Flaschenhals ist der Viewer trotz 3xCore und später 5xCore gab es dennoch immer ein Prozess der mindestens kurzzeitig einen Core zu 100% auslastete. Das Ergebnis unterscheidet sich zunächst also nicht sehr von dem var16x16 Test. Leichtes Ruckeln wenn der Ava fliegt.
Wenn man aber für den Firestorm zur Windows Standardeinstellung zurückkehrt, das heisst, der Viewer ist für alle Cores freigegeben. Gibt es keinen Core mehr der zu 100% ausgelastet ist. Es ist nach wie vor eine hohe Auslastung aber keine 100%ige. Dieser kleine Unterschied bewirkt das man mit einer Sichtweite von 256m mit dem Avatar flüssig fliegen kann. Wahrscheinlich fällt mein Ergebnis im Gegensatz zu Pius seinem Test nicht so deutlich aus, da ich nicht auf einem Server sondern auf meinen Lokalen PC testete, und da lief noch etwas mehr als der Opensimulatortest.
Fazit:
Auf einen echten Server sollte der Opensimulator mit einer var8x8 problemlos laufen. Vor allem wenn dann der Viewer abgesehen von den ganzen Hintergrundprogrammen die einzigste Anwendung auf dem PC ist. Eine var8x8 sollte also bei sparsamer Bebauung, Zurückhaltung bei den Skripten und einer Sichtweite von 256m schon Spass machen.
Die Frage, die es noch zu klären gilt, ist, lässt sich die Belastung des Viewers verringern, in dem die Map in Teile zerlegt wird? Bringt es also etwas, dem Beispiel Christophs mit seiner Segelregion zu folgen, und kleinere Regionen zu einer Grösseren aneinanderzudocken?
============
Rechner: 10 Cores mit 20 logischen Prozessoren; 64GB RAM
Viewer: Firestorm 6.0.2.56680
Viewer: Singularity 1.8.9 (8324)
Die Viewer unterschieden sich nicht signifikant.
Rein lokaler Test um Upload als Flaschenhals zu umgehen.
Aufgrund der Testergebnisse mit der Var16x16 wird auf einen Test im Standalonemode verzichtet.
Grid Mode mit MariaDB
----------------------
1xCore MariaDB
3xCore Opensim.exe
1xCore Robust.exe
3xCore Firestorm
4x4 OARs = 16 Parzellen (8x8 = 64 Parzellen; Faktor 4)
110.000 Prims
4800 Skripte
11GB RAM --> 4x11GB = 44GB (hochgerechnet)
In Ruhe 50% CPU Auslastung
Avatar fliegt 50% CPU Auslastung
==> CPU_ges. 80%
Ergebnis:
Flaschenhals ist der Viewer trotz 3xCore und später 5xCore gab es dennoch immer ein Prozess der mindestens kurzzeitig einen Core zu 100% auslastete. Das Ergebnis unterscheidet sich zunächst also nicht sehr von dem var16x16 Test. Leichtes Ruckeln wenn der Ava fliegt.
Wenn man aber für den Firestorm zur Windows Standardeinstellung zurückkehrt, das heisst, der Viewer ist für alle Cores freigegeben. Gibt es keinen Core mehr der zu 100% ausgelastet ist. Es ist nach wie vor eine hohe Auslastung aber keine 100%ige. Dieser kleine Unterschied bewirkt das man mit einer Sichtweite von 256m mit dem Avatar flüssig fliegen kann. Wahrscheinlich fällt mein Ergebnis im Gegensatz zu Pius seinem Test nicht so deutlich aus, da ich nicht auf einem Server sondern auf meinen Lokalen PC testete, und da lief noch etwas mehr als der Opensimulatortest.
Fazit:
Auf einen echten Server sollte der Opensimulator mit einer var8x8 problemlos laufen. Vor allem wenn dann der Viewer abgesehen von den ganzen Hintergrundprogrammen die einzigste Anwendung auf dem PC ist. Eine var8x8 sollte also bei sparsamer Bebauung, Zurückhaltung bei den Skripten und einer Sichtweite von 256m schon Spass machen.
Die Frage, die es noch zu klären gilt, ist, lässt sich die Belastung des Viewers verringern, in dem die Map in Teile zerlegt wird? Bringt es also etwas, dem Beispiel Christophs mit seiner Segelregion zu folgen, und kleinere Regionen zu einer Grösseren aneinanderzudocken?