• Bitte schaltet eure Ad Blocker aus. SLinfo kann nur betrieben werden, wenn es durch Werbung Einnahmen erzielt. Vielen Dank!!
  • Wir freuen uns, wenn du dich in unserem Forum anmeldest. Bitte beachte, dass die Freigabe per Hand durchgeführt wird (Schutz vor Spammer). Damit kann die Freigabe bis zu 24 Stunden dauern.
  • Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Sie geben Einwilligung zu unseren Cookies, wenn Sie unsere Webseite weiterhin nutzen.

Plattenzugriff=Performanceproblem erster Güte

argus Portal

Freund/in des Forums
Hallo

Es gibt eine Reihe Threads zu Performanceproblemen. Aber hier geht es mir speziell darum, das bei Plattenzugriffen der Viewer mitunter sekundenlang einfriert.

Hier eine grössere Testregion (setzt sich aus mehrere Regionen zusammen).

http://maps.secondlife.com/secondlife/Babbage Square/136/206/106

Die FPS-Rate geht dort, bei 120 Metern Sichtweite, von 18 bis 60. Also wirklich gut.

Aber: Wenn ich umhergehe oder fliege, bleibt der Rechner immer wieder sekundenlang stehen. Wenn nämlich nachgeladen werden muss.

Diesen Effekt kann ich etwas mildern, wenn ich das autom. Cacheleeren für JEDEN Viewerstart aktiviere. Je grösser der Cache, und je länger der Cache in Betrieb war (über mehrere Viewerstarts hinweg), desto stärker der Effekt.

Daher habe ich die Cachegrösse auch auf minimum gestellt.


Kennt ihr diesen Effekt ? Muss man damit leben ? Oder kann man per Einstellungen etwas verbessern ?


Meine Systemdaten:


********************** cut ************************

Firestorm 4.4.2 (34167) Jul 1 2013 23:33:25 (Firestorm-Release) mit Havok-Unterstützung
Versionshinweise

Versionshinweise

CPU: AMD Phenom(tm) II X4 965 Processor (3415.73 MHz)
Speicher: 3326 MB
Betriebssystem: Microsoft Windows 7 32-bit Service Pack 1 (Build 7601)
Grafikkarten-Hersteller: NVIDIA Corporation
Grafikkarte: GeForce GTX 460/PCIe/SSE2/3DNOW!

Windows Grafiktreiber-Version: 9.18.0013.0697
OpenGL Version: 4.2.0

RestrainedLove API: (disabled)
libcurl-Version: libcurl/7.21.1 OpenSSL/1.0.0d zlib/1.2.5 c-ares/1.7.1
J2C-Decoderversion: KDU v7.1
Audio-Treiberversion: FMOD version 3.750000
Qt Webkit-Version: 4.7.1 (version number hard-coded)
Voice-Serverversion: Vivox 2.1.3010.6270

Modus: Firestorm
Oberflächendesign: Firestorm (Grey)
Schriftart: Roboto (96)
Draw Distance: 120
Bandbreite: 1400
LOD-Faktor: 2
Darstellungsqualität: Hoch
Kompiliert mit MSVC version 1600
Paketverlust: 944/66.047 (1,4%)
 
Dass die Cache-Größe ein Teil des Problems sein könnte, hast du ja schon selbst erkannt:
Je grösser der Cache, und je länger der Cache in Betrieb war (über mehrere Viewerstarts hinweg), desto stärker der Effekt.

Probier mal, ob es besser wird, wenn du bei den Einstellungen im Viewer sowohl den Cache auf minimum lässt - und dazu die Bandbreite (auf etwa 512) verkleinerst.
 
Dieses Einfrierproblem hatte ich zuletzt so um 2010/2011 herum mit dem Imprudence Viewer.
Die Zeitspanne des Einfrierens lag dabei teils über dem Client-Ping was mich natürlich ausloggte.
Damals behalf ich mir mit einer Ramdisk von 1GB, worauf ich den Cache packte.
Damit bekam ich das Einfrieren, was immer noch da war, auf erträgliche 3-8 Sekunden.
Den Cache selbst hielt ich wie eight schon sagte, recht klein (ca 300MB)

Heute habe ich den Cache entgegen jeder Empfehlung auf einer SSD-Disk.
Das läuft nun schon über ein Jahr und ich kann keine Beschädigung der SSD ausmachen (Schreibzyklen auf SSD sind begrenzt)
 
Ich kenne das Phänomen auch, insbesondere seit dem letzten oder vorletzten Firestorm update. Allerdings lange nicht so ausgeprägt wie wohl bei dir. Mein Viewer friert auch manchmal mehrere Sekunden ein wenn aus dem Cache geladen wird, nicht immer aber manchmal kanns lange dauern.
Allerdings habe ich aufgrund meiner schmalen Bandbreite einen sehr großen Cache (3,5GB), den ich nur leere wenn´s unbedingt nötig ist, sprich er ist auch großteils ausgelastet. Aber auch hier es noch im tolerablen Bereich.
Als Grund der das Problem verschlimmert kann ich mir eine hohe Festplattenfragmentierung vorstellen, und/oder eine riesige Partition. Da muss das Ding halt einfach lange suchen bis er die verschiedenen kleinen Bits zusammen hat von der Platte.
 
Heute habe ich den Cache entgegen jeder Empfehlung auf einer SSD-Disk.
Das läuft nun schon über ein Jahr und ich kann keine Beschädigung der SSD ausmachen (Schreibzyklen auf SSD sind begrenzt)

Jetzt habe ich eine blöde Frage: Warum kann das die SSD schädigen? Bei vielen modernen Laptops sind doch Betriebsystem und die Programme, die permanent auf die Platte zugreifen, auf einer SSD-Disk. Und eigentlich sollte die Beschreibung der SSD so geregelt sein, daß alle Zellen gleichmäßig belastet werden und damit die Haltbarkeit der SSD mindestens die einer konventionellen Festplatte erreicht - oder liege ich da falsch?
 
Zuletzt bearbeitet:
Zur Bandbreite: Damit habe ich schon experimentiert. Die Auswirkung ist kaum messbar.

Ich will den Cache testweise auf eine recht kleine Partition verlagern (10 GB). Vielleicht hilft das. Gegenwärtig nutze ich eine Partition mit 300 GB.
 
Zuletzt bearbeitet:
Ich will den Cache testweise auf eine recht kleine Partition verlagern (10 GB). Vielleicht hilft das. Gegenwärtig nutze ich eine Partition mit 300 GB.

300GB Cache? Wow.
Bei mir sind die Cache-Ordner (pro Viewer etwa 500MB) auf der selben Partiton wo auch die Viewer sind, und die Bandbreite bei 512, und ich hab das Einfrieren nicht.
Naja eigentlich schon :oops:, aber zumindest nicht aus diesem Grund - bei mir ist der einzige Grund eine Überhitzung von CPU und/oder Graka wegen zu viel Staub im Gehäuse, wird aber nächsten Monat erledigt.
 
Nur falls ich mich missverständlich ausdrückte: Die Partition, auf welcher der Cache liegt, ist 300 GB gross. Nicht der Cache selbst ;-)
 
Also, wenn ich Texture Compression bei meiner AMD HD 5450 aktiviere, rödelt das Ding auch wie verrückt rum und alles zuckt, liegts daran vllt? Denn das klingt irgendwie gleich.
 
Ich habe den Cache derzeit in einer (beim Shutdown auf HDD gesicherten...) Ramdisk, ohne Probleme und Denkpausen. Wenn ich den Cache auf eine 10000 rpm Workstation Platte (Velociraptor) hier lege, dann läuft das auch alles ohne Probleme, auch wenn da fast 8GB im Cache voll sind (und das Ding auf der Platte locker mal 14GB belegt wegen gespeicherten Soundfiles usw.). Allerdings kommt die Platte bei den Transferraten auch schon nah an eine SSD ran. (120MB/s bis 130MB/s schreiben, 200MB/s peak lesen,5 bis 6ms Zugriffszeit), und wenn ich damit gerade keinen Film umkodiere oder was kompiliere, dann ist die nur 250GB große Platte auch relativ leer. So dass es kein Problem mit Fragmentierung gibt.

Bei einer langsameren (z.B. 5400 rpm) Platte mit nur kleinem Cache an einer Sata 1.0 Schnittstelle, die dazu noch ziemlich voll ist kann ich mir aber schon vorstellen, dass die zu Gedenkminuten führt. Die hat dann nicht nur längere Zugriffszeiten (locker über 20ms) sondern auch deutlich geringere Datenraten, mehr als 50MB/s bis 70MB/s schaffen viele dieser Platten auch im Peak leider nicht. Und oft können die nur um die 30MB/s bis 40MB/s aus einem Cache wie dem SL-Cache mit vielen kleinen Dateien liefern. (Dafür kriegt man so eine 250GB Platte schon für unter 40€; eine gleichgroße, aber wesentlich schnellere Workstation-HDD kostet locker mal das doppelte, d.h. um die 80€ bis 100€ für eine 250GB Platte.)

Den Cache dann nur auf eine andere Partition auf der selben Platte zu legen bringt aber eventuell nicht sonderlich viel, vor allem wenn es eine eher langsame Platte ist. Die HDD muss ja weiterhin auch noch die Daten aus den anderen Partitionen liefern. Da bringt es wohl mehr den SL cache auf eine eigene Platte zu legen und dort dann die Auslagerungsdatei für diese Platte auch noch zu deaktivieren, so dass die HDD wirklich nichts als den SL-Cache verarbeiten muss.
 
Guten Morgen,

nun muss ich als Techniklaie auch noch meinen Senf dazu geben. Also ich habe, aufgrund von Tipps hier(ich glaube sogar Shirley war es) den SL Cache und den Firestorm selber aus meinem Gdata Virenscanner rausgenommen. Werden die permanent wechselnden Daten im Cache jedesmal erst vom Virenscanner überprüft kostet es halt viel Zeit.

Hoffe ich habe es richtig erklärt...:)
 
Ja. Das ist eine wichtige Massnahme, die ich allerdings schon ergriffen hatte.

Ich habe den Cache jetzt erst einmal auf eine kleine Partition verlagert.

Gibt es eigentlich die Möglichkeit, ähnlich wie bei der Auslagerungsdatei unter Windows, den Viewercache auf eine feststehende Datei von fester Grösse einzustellen ? Damit könnte ich dem Partitionierungsproblem begegnen. In dem Fall würde sich auch der Kauf einer weiteren Platte lohnen, die ich dann nat. nicht nur für den Viewercache verwenden würde.
 
Ja. Das ist eine wichtige Massnahme, die ich allerdings schon ergriffen hatte.

Ich habe den Cache jetzt erst einmal auf eine kleine Partition verlagert.

Gibt es eigentlich die Möglichkeit, ähnlich wie bei der Auslagerungsdatei unter Windows, den Viewercache auf eine feststehende Datei von fester Grösse einzustellen ? Damit könnte ich dem Partitionierungsproblem begegnen. In dem Fall würde sich auch der Kauf einer weiteren Platte lohnen, die ich dann nat. nicht nur für den Viewercache verwenden würde.

Nein, man kann beim ViewerCache keine feste, sondern nur eine maximale Größe einstellen, der Viewercache wächst ja erst nach und nach durch die Benutzung, wenn Texturen, Meshes usw. vom Server geladen werden. Erreicht der Cache dann die maximale Größe fängt die cache-Verwaltung dann an die ältesten Texturen und items wieder raus zu werfen um Platz für neue Texturen zu machen. Nur der Rechenaufwand (die CPU Last) des Viewers kann mit größerem Cache bisschen größer werden. Und natürlich hat ein kleinerer Cache auch kleinere Zugriffszeiten als ein großer Cache, wobei bei einem langsamen Internet selbst ein 8GB Cache Sinn machen kann. Einfach weil dann immer noch schneller aus dem Cache geladen wird als vom Sever.

Den Cache in einer eigenen, kleinen Platte laufen zu lassen kann aber durchaus Sinn machen, da diese eigene Platte dann ja nicht auch noch viele andere Dateioperationen nebenher machen muss. Gerade billige, langsame HDD haben wie gesagt durchaus mal mittlere Zugriffszeiten von z.B. 20ms und mehr und niedrige Transferraten - und Windows schreibt eben ständig irgendwas in der C:\ Partition bzw. über die Platte, auf der auch die C: Partition ist, womit auch eine D:partition auf der selben Platte auch bisschen ausgebremst wird (Kann man über den Ressourcen-Monitor von Win7 wunderbar sehen ).

D.h. mit zwei (oder mehr.. je nach dem was man mit dem PC so alles macht) Platten kann das Windows-System ungestört weiterhin auf der einen Platte vor sich hin rödeln, während auf der anderen Platte dann gleichzeitig eben die Cache-Daten gelesen werden. Über einen modernen SATA-Bus ist das alles kein Problem, mit einem SataII, den die meisten Rechner mittlerweile mindestens haben, kann man 300MB/s über den Bus schaufeln. Das ist mehr als zwei normale HDD üblicherweise bringen. (Und mit Sata III sind es sogar 600MB/s, die der Bus kann...).
 
Die Cache-Partition liegt auf einer anderen Festplatte als das Betriebssystem. Windows kann zumindest mit seinen Angelegenheiten nur begrenzt stören.
 
Was haben Festplattenzugriffe mit der Grafik zu tun ? Kanns nicht auch sein das bei Festpattenzugriffen die Spannung einknickt und die Grafikkarte "stehen bleibt" ?
 
Einen Spannungseinbruch quittiert dein Rechner irgendwo zwischen Komplettabschaltung (initiiert entweder vom Netzteil oder der BIOS Überwachung) und einem Bluescreen (Windows), respektive CPU-Halt (Frozen Desktop) (alle Systeme)

Eine Grafikkarte "läuft" auch nicht (im Sinne eines Betriebssystems), sie ist eher vergleichbar mit einem Endgerät im Postjargon oder moderner gesprochen einer Black Box (tu was rein, dann kommt was raus)

durchaus interessante Aspekte, die wir aber Ausschließen dürften
 
NEIN - sorry wenn ich wiederspreche aber bei mir war es so - ich flog über eine SIM die Platten fingen an zu rödeln und als die GK wieder "lief" war ich schon ein par SIMs weiter. Neues dickeres Netzteil und der Fehler war weg.
 
interessant,
klingt aber nicht nach Spannungseinbruch, sondern ebenjener Cachereorganisation, die den Viewer ein paar Sekunden bis Minuten in klinischen Tiefschlaf versetzt (du erinnerst dich bestimmt an das berühmte "Über Wasser laufen")

aber du sagst selbst, ein Netzteilwechsel hat das beendet.
technisch kaum vorstellbar.
- eine Grafikkarte verbruzelt je nach Art und Beanspruchung bis zu 200 Watt elektrische Leistung (das ist sche... viel)
- eine Festplatte, etwa 10 Watt (quasi nix)
 

Users who are viewing this thread

Zurück
Oben Unten