29.04.2020, 00:00
(Dieser Beitrag wurde zuletzt bearbeitet: 29.04.2020, 08:04 von Jules Dreki.)
Hier doch schon mal das Ergebnis für ein var16x16. Es ist zwar etwas im Telegrammstil geschrieben, aber ich denke dennoch aussagefähig:
1. var16x16
============
Rechner: 10 Cores; 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.
Standalone
-----------
--> der komplette Simulator läuft auf einem Prozessor
leere Region und Avatar fliegt --> CPU Auslastung >> 100%
PS: Zu der Zeit als ich den Standalone Mode testete, kannte ich noch nicht die Möglichkeit den Programmen definierte CPUs zuweisen zu können. Es war also die Standardeinstellung und so das Programm für alle Cores freigegeben. Daher wurden sicher mehr als ein Core benutzt, aber mindestens ein Core war zu 100% ausgelastet.
Grid Mode mit MariaDB
---------------------------
==> Unterteilung in mehrere Prozesse auf eigenen Cores.
1xCore MariaDB
1xCore Opensim.exe
1xCore Robust.exe
3xCore Firestorm (sehr schnell auf 100% --> 3Core)
In der Konfiguration upload der OARs. Nach Neustart der kompletten Umgebung:
4x4 OARs = 16 Parzellen (16x16 = 256 Parzellen; Faktor 16)
110.000 Prims
4800 Skripte
12GB RAM --> 16x12GB = 192GB (hochgerechnet)
In Ruhe 50-55% Core Auslastung
Avatar fliegt 60% Core Auslastung
--> 1xCore MariaDB --> kleine Auslastung (schlecht abzulesen)
--> 3xCore Opensim.exe --> kleine Auslastung (schlecht abzulesen)
--> 1xCore Robust.exe --> kleine Auslastung (schlecht abzulesen)
--> 3xCore Firestorm
==> CPU_ges. 80% und RAM Verbrauch durch Simulator und Datenbank kein Flaschenhals
Flaschenhals ist der Viewer trotz 3xCore und später 5xCore gab es dennoch immer ein Prozess
der mindestens kurzzeitig einen Core zu 100% auslastete.
Ergebnis:
Hin- und herlaufen kein Problem. Teleportieren kein Problem. Fliegen mit dem Avatar geht auch, allerdings mit kurzen Aussetzern. Also nicht wirklich flüssig, und das bereits ohne ein Auto oder Flugzeug. Daran änderte sich auch nichts entscheidend als für alle Programme alle Prozessoren wieder zugelassen wurden. Der Simulator lastete die Hardware bei Zuweisung genügender Ressourcen diese nicht aus, war aber mit z.B. einer Gesamtauslastung der CPU mit 80% schon recht hoch. Der Viewer geriet dagegen immer wieder kurzzeitig an seine Grenzen.
Vermutlich liegt es an der grundsätzlichen Implementierung der Viewer. Starte ich ein modernes 3D Spiel wird der PC insgesamt lauter, was vorallem an den hochdrehenden Ventilatoren der Grafikkarte liegt. Er pustet dann vernehmlich. Das blieb in der Testumgebung aus. Daher meine Vermutung, daß der Viewer noch vieles selbst mit der CPU berechnet, und weniger Aufgaben als ein modernes Spiel an die Grafikkarte zur Berechnung übergibt.
Fazit:
Ein var16x16 macht für eine Flugplatz Region nicht wirklich Spass.
Es wird ein weiterer Versuch mit einer var8x8 durchgeführt.
Später wäre auch ein Test mit aus kleineren Regionen zusammengesetzter grösseren Map denkbar.
1. var16x16
============
Rechner: 10 Cores; 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.
Standalone
-----------
--> der komplette Simulator läuft auf einem Prozessor
leere Region und Avatar fliegt --> CPU Auslastung >> 100%
PS: Zu der Zeit als ich den Standalone Mode testete, kannte ich noch nicht die Möglichkeit den Programmen definierte CPUs zuweisen zu können. Es war also die Standardeinstellung und so das Programm für alle Cores freigegeben. Daher wurden sicher mehr als ein Core benutzt, aber mindestens ein Core war zu 100% ausgelastet.
Grid Mode mit MariaDB
---------------------------
==> Unterteilung in mehrere Prozesse auf eigenen Cores.
1xCore MariaDB
1xCore Opensim.exe
1xCore Robust.exe
3xCore Firestorm (sehr schnell auf 100% --> 3Core)
In der Konfiguration upload der OARs. Nach Neustart der kompletten Umgebung:
4x4 OARs = 16 Parzellen (16x16 = 256 Parzellen; Faktor 16)
110.000 Prims
4800 Skripte
12GB RAM --> 16x12GB = 192GB (hochgerechnet)
In Ruhe 50-55% Core Auslastung
Avatar fliegt 60% Core Auslastung
--> 1xCore MariaDB --> kleine Auslastung (schlecht abzulesen)
--> 3xCore Opensim.exe --> kleine Auslastung (schlecht abzulesen)
--> 1xCore Robust.exe --> kleine Auslastung (schlecht abzulesen)
--> 3xCore Firestorm
==> CPU_ges. 80% und RAM Verbrauch durch Simulator und Datenbank kein Flaschenhals
Flaschenhals ist der Viewer trotz 3xCore und später 5xCore gab es dennoch immer ein Prozess
der mindestens kurzzeitig einen Core zu 100% auslastete.
Ergebnis:
Hin- und herlaufen kein Problem. Teleportieren kein Problem. Fliegen mit dem Avatar geht auch, allerdings mit kurzen Aussetzern. Also nicht wirklich flüssig, und das bereits ohne ein Auto oder Flugzeug. Daran änderte sich auch nichts entscheidend als für alle Programme alle Prozessoren wieder zugelassen wurden. Der Simulator lastete die Hardware bei Zuweisung genügender Ressourcen diese nicht aus, war aber mit z.B. einer Gesamtauslastung der CPU mit 80% schon recht hoch. Der Viewer geriet dagegen immer wieder kurzzeitig an seine Grenzen.
Vermutlich liegt es an der grundsätzlichen Implementierung der Viewer. Starte ich ein modernes 3D Spiel wird der PC insgesamt lauter, was vorallem an den hochdrehenden Ventilatoren der Grafikkarte liegt. Er pustet dann vernehmlich. Das blieb in der Testumgebung aus. Daher meine Vermutung, daß der Viewer noch vieles selbst mit der CPU berechnet, und weniger Aufgaben als ein modernes Spiel an die Grafikkarte zur Berechnung übergibt.
Fazit:
Ein var16x16 macht für eine Flugplatz Region nicht wirklich Spass.
Es wird ein weiterer Versuch mit einer var8x8 durchgeführt.
Später wäre auch ein Test mit aus kleineren Regionen zusammengesetzter grösseren Map denkbar.