Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
View Testumgebung: flash Performance schlecht
View Testumgebung: flash Performance schlecht
Hallo,
in der Testumgebung laufen flash Videos (youtube) nur sehr ruckelnd. Läuft da auf jeden Fall was schief oder kann das auch normal sein?? Bin grad etwas in ner Sackgasse gelandet.
Win7 64bit VM. VMware optimazion script wurde ausgeführt. (VMware View Optimization Guide for Windows 7)
Adobe FlashPlayer installiert.
3d Rendering ist auf dem Pool aktiv. es sind 128mb Video Ram eingestellt. PCoIP wird verwendet.
Die VM läuft auf einem ESXi 5.0 host mit 2x Xeon E5335 @2GHz und hat zwei vCPUs und 2GB vRAM bekommen.
Die flash Performance ist von Mobilen Android Geräten und dicken Windows FatClients gleich(mies). Fenster und Programme öffnen sich fix und ohne merkliche Verzögerung.
Bin für jeden Hinweis froh!
Gruß,
Conne
in der Testumgebung laufen flash Videos (youtube) nur sehr ruckelnd. Läuft da auf jeden Fall was schief oder kann das auch normal sein?? Bin grad etwas in ner Sackgasse gelandet.
Win7 64bit VM. VMware optimazion script wurde ausgeführt. (VMware View Optimization Guide for Windows 7)
Adobe FlashPlayer installiert.
3d Rendering ist auf dem Pool aktiv. es sind 128mb Video Ram eingestellt. PCoIP wird verwendet.
Die VM läuft auf einem ESXi 5.0 host mit 2x Xeon E5335 @2GHz und hat zwei vCPUs und 2GB vRAM bekommen.
Die flash Performance ist von Mobilen Android Geräten und dicken Windows FatClients gleich(mies). Fenster und Programme öffnen sich fix und ohne merkliche Verzögerung.
Bin für jeden Hinweis froh!
Gruß,
Conne
-
- King of the Hill
- Beiträge: 13561
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Alle mir bekannten aktuellen GPUs unterstützen Flash in HW. Wenn das von der GPU nicht unterstützt wird, wie es in einer VM zu erwarten ist, muß die CPU die Aufgabe komplett übernehmen und dann sind hochgetaktete CPUs im Voteil. Ich würde als erste Maßnahme trotzdem den Grafik-RAM auf 256MB erweitern.
Falls das nichts bringt oder nicht ausreicht, würde ich aufgrund des schlechten Skalierens deiner FSB1333-Quadcores testweise die VM fest auf eine Hälfte einer deiner Quads binden und die restlichen auf diesem ESXi laufenden VMs von diesen gebunden Kernen ebenfalls fernhalten. Das ist natürlich komplett widersinning für eine gleichmäßige CPU-Auslastung des Gesamtsystems und wirft der ESXi-Verwaltung gehörige Brocken in den Weg. Aber anders bekommst du aufgrund des internen CPU-Aufbaus die bremsende Wirkung des FSB sowohl zwischen beiden Dualcore-Hälften deiner Quad-CPU als auch zwischen beiden CPU-Sockeln nicht in den Griff.
Falls das nichts bringt oder nicht ausreicht, würde ich aufgrund des schlechten Skalierens deiner FSB1333-Quadcores testweise die VM fest auf eine Hälfte einer deiner Quads binden und die restlichen auf diesem ESXi laufenden VMs von diesen gebunden Kernen ebenfalls fernhalten. Das ist natürlich komplett widersinning für eine gleichmäßige CPU-Auslastung des Gesamtsystems und wirft der ESXi-Verwaltung gehörige Brocken in den Weg. Aber anders bekommst du aufgrund des internen CPU-Aufbaus die bremsende Wirkung des FSB sowohl zwischen beiden Dualcore-Hälften deiner Quad-CPU als auch zwischen beiden CPU-Sockeln nicht in den Griff.
Hallo,
vielen Dank für die Info. Dann wliegt das nicht an einer Konfig sondern schlicht an der Hardware? tstststs... die Xeon CPUs sind jetzt wirklich nicht der Brülller, aber das hätte ich nicht erwartet.
Na, mal sehen, in der Firma steht noch ein ähnliches Modell mit zwei X5560 Xeons aus altem Kundenbestand.
Ich werde die VM mal dort hin rüber verschieben.
Soweit ich weiß, ist bei ESXi5.0 bei 128mb VideoRAM für den Gast schluss.
Ich probiere mal 4 vCPUs und volle Reservierungen. Danach binde ich Kerne an die VM, wie von dir beschrieben.
Gruß,
Conne
vielen Dank für die Info. Dann wliegt das nicht an einer Konfig sondern schlicht an der Hardware? tstststs... die Xeon CPUs sind jetzt wirklich nicht der Brülller, aber das hätte ich nicht erwartet.
Na, mal sehen, in der Firma steht noch ein ähnliches Modell mit zwei X5560 Xeons aus altem Kundenbestand.
Ich werde die VM mal dort hin rüber verschieben.
Soweit ich weiß, ist bei ESXi5.0 bei 128mb VideoRAM für den Gast schluss.
Ich probiere mal 4 vCPUs und volle Reservierungen. Danach binde ich Kerne an die VM, wie von dir beschrieben.
Gruß,
Conne
-
- King of the Hill
- Beiträge: 13561
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Je nach Browser helfen dir viele CPU-Kerne nicht weiter. Einige Browser laufen trotz vieler geöffneter Tabs hauptsächlich auf einem Kern, während andere die Tabs möglichst gleichmäßig auf die vorhandenen Kerne verteilen. Ich hab allerdings keine Ahnung, wie die Browser mit mehreren Fenstern skalieren...
Virtualisierung ist hinsichtlich Grafikleistung aber allgemein wenig performant. Das jede laufende VM nur im Rahmen von RR an die Reihe kommt und zudem auch nicht vollständig auf die HW zugreifen kann, sorgt für weitere Verluste in der Grafikleistung.
Testweise könntest du ja mal eine X5560-CPU rausnehmen. Dann läuft die VM definitiv immer auf einer CPU und wird auch nicht über den QPI-Link mit 6,4 GT/s · 20 Bit/T = 128 GBit/s bzw 16 GByte/s Bruttobandbreite zwischen den Sockeln hin- und hergeschoben.
Virtualisierung ist hinsichtlich Grafikleistung aber allgemein wenig performant. Das jede laufende VM nur im Rahmen von RR an die Reihe kommt und zudem auch nicht vollständig auf die HW zugreifen kann, sorgt für weitere Verluste in der Grafikleistung.
Testweise könntest du ja mal eine X5560-CPU rausnehmen. Dann läuft die VM definitiv immer auf einer CPU und wird auch nicht über den QPI-Link mit 6,4 GT/s · 20 Bit/T = 128 GBit/s bzw 16 GByte/s Bruttobandbreite zwischen den Sockeln hin- und hergeschoben.
-
- Member
- Beiträge: 360
- Registriert: 13.07.2011, 15:33
bla!zilla hat geschrieben:Dayworker hat geschrieben:Dann läuft die VM definitiv immer auf einer CPU und wird auch nicht über den QPI-Link mit 6,4 GT/s · 20 Bit/T = 128 GBit/s bzw 16 GByte/s Bruttobandbreite zwischen den Sockeln hin- und hergeschoben.
Warum sollte die VM herumgeschoben werden?
der vmkernel Scheduler kennt seit 3.5 oder 4.0 NUMA. Also eigentlich sollte nie was über den QPI Link gehen
Angesichts der Tatsache, dass diese Einstellungen keine merkliche Besserung gebracht haben, wird es auf dieser Hardware wohl einfach nciht besser laufen
Es sei denn, ich habe etwas falsch eingestellt oder etwas nciht berücksichtigt - aber ich denke, da hätte jemand von euch schon nachgefragt, und drauf hingewiesen, wenn da noch eine Möglichkeit bestünde.
Mich würde trotzdem noch interessieren, wie das System ansonsten angedacht ist. Firmen die View einsetzen, werden, denke ich, keine ruckelnden Flash Videos haben wollen. Was wäre der offizielle Weg, um diesen Service ordentlich zur Verfügung zu stellen?
Kann mir kaum vorstellen, dass es auf physikalische Workstations mit View Agent hinausläuft...
Gruß,
Conne
Es sei denn, ich habe etwas falsch eingestellt oder etwas nciht berücksichtigt - aber ich denke, da hätte jemand von euch schon nachgefragt, und drauf hingewiesen, wenn da noch eine Möglichkeit bestünde.
Mich würde trotzdem noch interessieren, wie das System ansonsten angedacht ist. Firmen die View einsetzen, werden, denke ich, keine ruckelnden Flash Videos haben wollen. Was wäre der offizielle Weg, um diesen Service ordentlich zur Verfügung zu stellen?
Kann mir kaum vorstellen, dass es auf physikalische Workstations mit View Agent hinausläuft...
Gruß,
Conne
-
- King of the Hill
- Beiträge: 13561
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
MarcelMertens hat geschrieben:bla!zilla hat geschrieben:Dayworker hat geschrieben:Dann läuft die VM definitiv immer auf einer CPU und wird auch nicht über den QPI-Link mit 6,4 GT/s · 20 Bit/T = 128 GBit/s bzw 16 GByte/s Bruttobandbreite zwischen den Sockeln hin- und hergeschoben.
Warum sollte die VM herumgeschoben werden?
der vmkernel Scheduler kennt seit 3.5 oder 4.0 NUMA. Also eigentlich sollte nie was über den QPI Link gehenbla!zilla hat geschrieben:Korrekt, so sehe ich das auch. Der Scheduler schaut schon, dass eine VM auf einem NUMA Node bleibt,
Danke für den NUMA-Hinweis, daran hatte ich nicht gedacht, da der OP ja nur FSB-Xeons hat und es dort NUMA noch nicht gibt. Wenn also selbst eine NUMA-fähige CPU keine Verbesserung bringt und VMware hoffentlich keine Implementierungsfehler gemacht hat, helfen wirklich nur viele Gigaherz und ein möglichst nur geringfügig ausgelasteter Host weiter.
Hallo,
für mich schaut es so aus als wenn deine CPU im Server nicht genügend Leistung bereitstellen kann.
Wir setzen HP Blade Server mit je 2 Xeon X5675 ein. Als Endgeräte setzen wir auf Igel Tc und neuerdings auf LG Zeroclients.Speziele Einstellungen wurden für Flash Videos nicht vorgenommen. Host laufen mit 30 - 40 Prozent Last. Alles unter View 5.01.
Damit ist eine flüssige Video Wiedergabe ( Youtube ) in der Standart Fenster Ansicht mit 720p problemlos möglich. Vollbild geht auch, ist aber weit entfernt von flüssig....
Schaut man sich die CPU Performance des virtuellen Desktops an so sieht man deutlich das mit abspielen des Videos jede Menge Rechen Leistung benötigt wird ( bei mir 75 - 90 % ).
Gruß
Jürgen
für mich schaut es so aus als wenn deine CPU im Server nicht genügend Leistung bereitstellen kann.
Wir setzen HP Blade Server mit je 2 Xeon X5675 ein. Als Endgeräte setzen wir auf Igel Tc und neuerdings auf LG Zeroclients.Speziele Einstellungen wurden für Flash Videos nicht vorgenommen. Host laufen mit 30 - 40 Prozent Last. Alles unter View 5.01.
Damit ist eine flüssige Video Wiedergabe ( Youtube ) in der Standart Fenster Ansicht mit 720p problemlos möglich. Vollbild geht auch, ist aber weit entfernt von flüssig....
Schaut man sich die CPU Performance des virtuellen Desktops an so sieht man deutlich das mit abspielen des Videos jede Menge Rechen Leistung benötigt wird ( bei mir 75 - 90 % ).
Gruß
Jürgen
OK. Auf dem etwas neueren Host (leider waren es nicht wie erwartet, X-Xeons, sondern leider nur E5440), läuft flash innnerhalb der VM deutlich besser, fast ruckelfrei.
Ich kann mir jetzt gut vorstellen, dass mit Xeons der X-Reihe oder aktuellen CPUs ein flash Video ruckelfrei abzubilden ist.
Eine Misskonfiguration scheint es daher erst mal nicht zu geben
Grüße,
Conne
Ich kann mir jetzt gut vorstellen, dass mit Xeons der X-Reihe oder aktuellen CPUs ein flash Video ruckelfrei abzubilden ist.
Eine Misskonfiguration scheint es daher erst mal nicht zu geben
Grüße,
Conne
- Tschoergez
- Moderator
- Beiträge: 3476
- Registriert: 23.02.2005, 09:14
- Wohnort: Burgberg im Allgäu
- Kontaktdaten:
Denkt auch dran, dass PCoIP automatisch Flash optimiert, sobald man mit der Maus ueber das Video faehrt... http://myvirtualcloud.net/?p=2479
Gruesse,
Joerg
Gruesse,
Joerg
huhu,
wir haben eine ähnliche Testumgebung:
Win7 Pro /1 socket mit 2 Kernen (Xeon X5450) / 2GB RAM / Teradici Audio Drivers
Pool Settings: 3D-Render Software 512MB / 1 Display / Flash Qualität mittel / Flash Drossel deaktiviert
Allerdings läuft Flash z.B. Youtube in 720p Fullscreen nicht flüssig. In der Large-View haben wir ab und an ein paar Aussetzer.
Gibt es um 720p in Fullscreen Referenzwerte für
PColPlmagingMinimumlmageQuality GPO / PColPlmagingMaximumlnitiallmageQualitv GPO / PCoIP.maximum_frame_rate / PColPMaxLinkRate GPO
Danke
grüße
wir haben eine ähnliche Testumgebung:
Win7 Pro /1 socket mit 2 Kernen (Xeon X5450) / 2GB RAM / Teradici Audio Drivers
Pool Settings: 3D-Render Software 512MB / 1 Display / Flash Qualität mittel / Flash Drossel deaktiviert
Allerdings läuft Flash z.B. Youtube in 720p Fullscreen nicht flüssig. In der Large-View haben wir ab und an ein paar Aussetzer.
Gibt es um 720p in Fullscreen Referenzwerte für
PColPlmagingMinimumlmageQuality GPO / PColPlmagingMaximumlnitiallmageQualitv GPO / PCoIP.maximum_frame_rate / PColPMaxLinkRate GPO
Danke
grüße
Zurück zu „View / Horizon View“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste