43
Kurioses vCore to Core Mapping beim Hyper-V 2022
Moin Zusammen,
ich bin soeben bei einem Kunden über ein meiner Ansicht nach sehr gravierendes Problem gestolpert. Und zwar hat sich der entsprechende Kunde seit der Umstellung seines Hyper-V Clusters von 2019 auf 2022 immer wieder beschwert, dass die CPU Last seiner 2012R2 RDS Session Hosts zu hoch währe und das es dadurch im Produktivbetrieb öfters zu spürbaren Verzögerungen bei diversen Applikationen führen würde, die auf diesen RDS Servern bereitgestellt werden.
Heute Abend habe ich mir die Sache mal genauer angesehen und habe dabei festgestellt, dass der Core Scheduler des Hyper-V 2022er einen kompletten Humbug beim mappen der vCores der 2012R2 VM macht. 😭
Und zwar sind jeder der entsprechenden RDS VM 8 vCores zugewiesen.
Testweise wurde die CPU Architektur dieser VM’s sogar soweit umkonfiguriert, dass die VM’s selbst ohne Hyperthreading Kerne laufen.
Demzufolge sollte die Last dieser VM eigentlich nur noch über die physikalischen Kerne des Hyper-V Nodes abgetragen werden und nicht mehr auch über dessen Hyperthreading Kerne, weil es aus diversesten Gründen alles andere als Lustig ist, einen Hyperthreading Kern genau so anzusprechen wie einen physikalischen Kern.
Die älteren von uns erinnern sich diesbezüglich vielleicht noch an ein paar gruselige Geschichten, als die ersten CPU’s mit Hyperthreading rauskamen und die Betriebssysteme diese nicht korrekt ansprechen/unterscheiden konnten. Na ja das ganze war so vor etwa 20 Jahren. 🙃
Umso erstaunter war ich, als ich auf einer dieser RDS Session Host VM’s einen CPU-Stresstoll habe laufen lassen um die Kerne der VM’s auf Volllast zu bringen, um dadurch besser sehen zu können über welche Kerne des Hyper-V Nodes diese tatsächlich auch abgetragen wird.
Und zwar sah das ganze im Taskmanager des Hyper-V Nodes dann folgend aus …
Die mit einem grünen Pfeil markierten Spalten stellen die Auslastung der physikalischen Kerne dar und die mit einem roten Pfeil markierten Spalten, stellen die Auslastung deren Hyperthreading Kerne dar. Und die rot umrandeten, sind die Kerne auf denen die Last der angesprochenen VM abgetragen wurde.
Wie ihr erkennen könnt, wurde in 7 von 8 Fällen, die CPU Last eines vCores der explizit als NICHT HT-Kern konfiguriert wurde, über einen HT-Kern des Hyper-V Nodes abgetragen. 🤢🤮
Wer jetzt das folgende denkt … 😱😖😵💫😭 … korrekt, so geht es mir gerade auch.
Bin ich nun irgendwie nur in einem falschen Film gelandet und wenn ja, wie komme ich aus diesem wieder raus oder drehen diese Microsoftianer nun vollkommen durch?
Beste Grüsse aus BaWü
Alex
ich bin soeben bei einem Kunden über ein meiner Ansicht nach sehr gravierendes Problem gestolpert. Und zwar hat sich der entsprechende Kunde seit der Umstellung seines Hyper-V Clusters von 2019 auf 2022 immer wieder beschwert, dass die CPU Last seiner 2012R2 RDS Session Hosts zu hoch währe und das es dadurch im Produktivbetrieb öfters zu spürbaren Verzögerungen bei diversen Applikationen führen würde, die auf diesen RDS Servern bereitgestellt werden.
Heute Abend habe ich mir die Sache mal genauer angesehen und habe dabei festgestellt, dass der Core Scheduler des Hyper-V 2022er einen kompletten Humbug beim mappen der vCores der 2012R2 VM macht. 😭
Und zwar sind jeder der entsprechenden RDS VM 8 vCores zugewiesen.
Testweise wurde die CPU Architektur dieser VM’s sogar soweit umkonfiguriert, dass die VM’s selbst ohne Hyperthreading Kerne laufen.
Demzufolge sollte die Last dieser VM eigentlich nur noch über die physikalischen Kerne des Hyper-V Nodes abgetragen werden und nicht mehr auch über dessen Hyperthreading Kerne, weil es aus diversesten Gründen alles andere als Lustig ist, einen Hyperthreading Kern genau so anzusprechen wie einen physikalischen Kern.
Die älteren von uns erinnern sich diesbezüglich vielleicht noch an ein paar gruselige Geschichten, als die ersten CPU’s mit Hyperthreading rauskamen und die Betriebssysteme diese nicht korrekt ansprechen/unterscheiden konnten. Na ja das ganze war so vor etwa 20 Jahren. 🙃
Umso erstaunter war ich, als ich auf einer dieser RDS Session Host VM’s einen CPU-Stresstoll habe laufen lassen um die Kerne der VM’s auf Volllast zu bringen, um dadurch besser sehen zu können über welche Kerne des Hyper-V Nodes diese tatsächlich auch abgetragen wird.
Und zwar sah das ganze im Taskmanager des Hyper-V Nodes dann folgend aus …
Die mit einem grünen Pfeil markierten Spalten stellen die Auslastung der physikalischen Kerne dar und die mit einem roten Pfeil markierten Spalten, stellen die Auslastung deren Hyperthreading Kerne dar. Und die rot umrandeten, sind die Kerne auf denen die Last der angesprochenen VM abgetragen wurde.
Wie ihr erkennen könnt, wurde in 7 von 8 Fällen, die CPU Last eines vCores der explizit als NICHT HT-Kern konfiguriert wurde, über einen HT-Kern des Hyper-V Nodes abgetragen. 🤢🤮
Wer jetzt das folgende denkt … 😱😖😵💫😭 … korrekt, so geht es mir gerade auch.
Bin ich nun irgendwie nur in einem falschen Film gelandet und wenn ja, wie komme ich aus diesem wieder raus oder drehen diese Microsoftianer nun vollkommen durch?
Beste Grüsse aus BaWü
Alex
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6904232499
Url: https://administrator.de/contentid/6904232499
Ausgedruckt am: 06.10.2024 um 06:10 Uhr
43 Kommentare
Neuester Kommentar
Moin Zusammen,
kleiner Nachtrag.
Beim Bild des Taskmanagers im Hauptpost sind lediglich 7 Kerne rot umrandet, das sind die Kerne der VM die auf einen HT-Kern des Hyper-V Nodes gemappt wurden.
Im folgenden Screenshot habe ich noch zusätzlich (grün umrandet) den einzigen physikalischen Kern markiert, auf den einer der acht vCores der VM, meiner Ansicht nach, dann doch korrekt gemappt wurde.
Beste Grüsse aus BaWü
Alex
kleiner Nachtrag.
Beim Bild des Taskmanagers im Hauptpost sind lediglich 7 Kerne rot umrandet, das sind die Kerne der VM die auf einen HT-Kern des Hyper-V Nodes gemappt wurden.
Im folgenden Screenshot habe ich noch zusätzlich (grün umrandet) den einzigen physikalischen Kern markiert, auf den einer der acht vCores der VM, meiner Ansicht nach, dann doch korrekt gemappt wurde.
Beste Grüsse aus BaWü
Alex
1
Testweise wurde die CPU Architektur dieser VM’s sogar soweit umkonfiguriert, dass die VM’s selbst ohne Hyperthreading Kerne laufen.
Meines Erachtens liegt hier ein Denkfehler vor. Du stellst hier die Threads per Core ein, ob physisch oder logisch definierst du nicht.
Wenn du da z.B. 2 einstellst, und der VM 2 CPUs zuweist, wirst du in der VM 2 Cores und 4 Threads haben, die aber nicht unbedingt auf 4 Cores des Hosts laufen. Dazwischen wird nochmal abstrahiert.
Hier habe ich auf einer VM 4 cores voll belastet. Du siehst wie die Belastung auf dem Host nicht immer auf den gleichen Cores liegt.
-Thomas
1
@MysticFoxDE:
Hallo.
Und die Kiste (der Host) hat physisch 32 Kerne?
Wieviele RDS-VMs im Einsatz? Und jede hat 8 vCores?
Das muß mit dem HT-Oder-Nicht-Problem gar nicht zwingend was zu tun haben.
Klingt mir schwer nach Wartezyklen. Den VMs sind zuviele vCores zugeordnet. Jeder virtuelle Rechenoperation braucht eine physische Rechenoperation, also ein freies Plätzchen auf den echten, physischen CPUs. Gibt's bspw. 32 physische Kerne, aber 10 VMs (Beispiel) haben jede 8 virt. Kerne zugeordnet (=80), heißt es warten. Je mehr vCPUs, desto länger die Wartezyklen. CPU-Overprovisioning funktioniert bei VMware (keine Ahnung, wie die das machen), nicht jedoch bei Microsoft-Hyper-V.
Viele Grüße
von
departure69
Hallo.
und das es dadurch im Produktivbetrieb öfters zu spürbaren Verzögerungen bei diversen Applikationen
Und zwar sind jeder der entsprechenden RDS VM 8 vCores zugewiesen.
Und die Kiste (der Host) hat physisch 32 Kerne?
Wieviele RDS-VMs im Einsatz? Und jede hat 8 vCores?
Das muß mit dem HT-Oder-Nicht-Problem gar nicht zwingend was zu tun haben.
Klingt mir schwer nach Wartezyklen. Den VMs sind zuviele vCores zugeordnet. Jeder virtuelle Rechenoperation braucht eine physische Rechenoperation, also ein freies Plätzchen auf den echten, physischen CPUs. Gibt's bspw. 32 physische Kerne, aber 10 VMs (Beispiel) haben jede 8 virt. Kerne zugeordnet (=80), heißt es warten. Je mehr vCPUs, desto länger die Wartezyklen. CPU-Overprovisioning funktioniert bei VMware (keine Ahnung, wie die das machen), nicht jedoch bei Microsoft-Hyper-V.
Viele Grüße
von
departure69
Moin @3063370895,
glaub mir Thomas, das wäre mir als Lösung am liebsten.
Das stimmt so nicht ganz, der erste ist immer ein "physikalischer" Kern und die nachfolgenden sind dann dessen HT-Kerne.
Mit dem folgenden Befehl kannst du die CPU-Konfig der VM ganz einfach überprüfen.
Nein nicht ganz, in diesem Fall hast du in der VM nur zwei Cores, einen physikalischen vCore und einen HT-vCore.
Schau mal, bei der folgenden VM, sieht die CPU-Config im Hyper-V folgend aus.
Der Wert 0 bei "Hardwarethreads pro Kern" bedeutet übrigens, das die HT Architektur des darüberliegenden Hyper-V Nodes, 1:1 übernommen werden soll. In diesem Fall hat der darunterliegende Hyper-V eine CPU mit eingeschaltetem HT und einem HT-Kern pro physikalischem Kern und daher wird hier auch korrekt (im oberen Bereich des Bildes zu sehen), automatisch 2 Hardwarethreads pro Kern gewählt.
In der VM sieht das ganze dann folgend aus.
Doch, das muss eigentlich so sein.
Und bei dir läuft das anscheinend auch genau so wie ich es mir wünschen würde!
Schau mal genau hin, bei dir werden die Kerne der VM immer paarweise gemappt, was bei eingeschaltetem HT auch vollkommen richtig ist.
In meinem Fall bekommt der Core Scheduler des Hyper-V 2022, aber nicht mal das auf die Reihe. 😔
Beste Grüsse aus BaWü
Alex
Meines Erachtens liegt hier ein Denkfehler vor.
glaub mir Thomas, das wäre mir als Lösung am liebsten.
Du stellst hier die Threads per Core ein, ob physisch oder logisch definierst du nicht.
Das stimmt so nicht ganz, der erste ist immer ein "physikalischer" Kern und die nachfolgenden sind dann dessen HT-Kerne.
Mit dem folgenden Befehl kannst du die CPU-Konfig der VM ganz einfach überprüfen.
wmic cpu get NumberOfCores, NumberOfLogicalProcessors/Format:ListWenn du da z.B. 2 einstellst, und der VM 2 CPUs zuweist, wirst du in der VM 2 Cores und 4 Threads haben
Nein nicht ganz, in diesem Fall hast du in der VM nur zwei Cores, einen physikalischen vCore und einen HT-vCore.
Schau mal, bei der folgenden VM, sieht die CPU-Config im Hyper-V folgend aus.
Der Wert 0 bei "Hardwarethreads pro Kern" bedeutet übrigens, das die HT Architektur des darüberliegenden Hyper-V Nodes, 1:1 übernommen werden soll. In diesem Fall hat der darunterliegende Hyper-V eine CPU mit eingeschaltetem HT und einem HT-Kern pro physikalischem Kern und daher wird hier auch korrekt (im oberen Bereich des Bildes zu sehen), automatisch 2 Hardwarethreads pro Kern gewählt.
In der VM sieht das ganze dann folgend aus.
die aber nicht unbedingt auf 4 Cores des Hosts laufen. Dazwischen wird nochmal abstrahiert.
Doch, das muss eigentlich so sein.
Hier habe ich auf einer VM 4 cores voll belastet. Du siehst wie die Belastung auf dem Host nicht immer auf den gleichen Cores liegt.
Und bei dir läuft das anscheinend auch genau so wie ich es mir wünschen würde!
Schau mal genau hin, bei dir werden die Kerne der VM immer paarweise gemappt, was bei eingeschaltetem HT auch vollkommen richtig ist.
In meinem Fall bekommt der Core Scheduler des Hyper-V 2022, aber nicht mal das auf die Reihe. 😔
Beste Grüsse aus BaWü
Alex
Ich glaube, hier liegt das Missverständnis:
https://petri.com/customize-non-uniform-memory-access-numa-configuration ...
https://www.datacenter-insider.de/was-ist-numa-a-ede6fc3e6dfa2bad71f899d ...
Viele Grüße, commodity
Zitat von @MysticFoxDE:
Schau mal, bei der folgenden VM, sieht die CPU-Config im Hyper-V folgend aus.
Der Wert 0 bei "Hardwarethreads pro Kern" bedeutet übrigens, das die HT Architektur des darüberliegenden Hyper-V Nodes, 1:1 übernommen werden soll. In diesem Fall hat der darunterliegende Hyper-V eine CPU mit eingeschaltetem HT und einem HT-Kern pro physikalischem Kern und daher wird hier auch korrekt (im oberen Bereich des Bildes zu sehen), automatisch 2 Hardwarethreads pro Kern gewählt.
Die von Dir im ersten Bild oben rot umrandete Einstellung "Hardwarethreads pro Kern" ist von MS missverständlich (schlampig) bezeichnet. Sie hat imo nichts mit HT-Cores zu tun, sondern betrifft die Anzahl der zur Verfügung gestellten NUMA Nodes.Schau mal, bei der folgenden VM, sieht die CPU-Config im Hyper-V folgend aus.
Der Wert 0 bei "Hardwarethreads pro Kern" bedeutet übrigens, das die HT Architektur des darüberliegenden Hyper-V Nodes, 1:1 übernommen werden soll. In diesem Fall hat der darunterliegende Hyper-V eine CPU mit eingeschaltetem HT und einem HT-Kern pro physikalischem Kern und daher wird hier auch korrekt (im oberen Bereich des Bildes zu sehen), automatisch 2 Hardwarethreads pro Kern gewählt.
https://petri.com/customize-non-uniform-memory-access-numa-configuration ...
https://www.datacenter-insider.de/was-ist-numa-a-ede6fc3e6dfa2bad71f899d ...
Viele Grüße, commodity
Jetzt mit Hardwarethreads pro Kern: 1
Ist auch Windows Server 2022. Tatsächlich werden nur die jeweils ersten Cores belastet.
VM: ubuntu 22.04 4 vCPUs
-Thomas
Ist auch Windows Server 2022. Tatsächlich werden nur die jeweils ersten Cores belastet.
VM: ubuntu 22.04 4 vCPUs
stress --cpu 4-Thomas
1
Moin @departure69,
jup.
Auf diesem Node laufen aktuell so 5-6.
Glaub mir, das hat Problem hat mit Overprovisioning nicht wirklich etwas zu tun.
Wie ich schon geschrieben habe, gibt es diverseste Gründe, warum ein nicht HT-vCore undbedingt auch auf einen nicht HT-Core gemappt werden sollte.
Einer davon ist z.B. RSS (und somit zwagsweise auch VMQ und oder SR-IOV) welches es auch in einer VM gibt und RSS darf "konstruktionsbedingt" niemals über einen HT-Kern laufen. Aber genau das geschieht, wenn der Core Scheduler des Hyper-V 2022 hergeht und einen nicht HT-vCore auf einen HT-Core mappt. 😔
Beste Grüsse aus BaWü
Alex
Und die Kiste (der Host) hat physisch 32 Kerne?
jup.
Wieviele RDS-VMs im Einsatz? Und jede hat 8 vCores?
Auf diesem Node laufen aktuell so 5-6.
Das muß mit dem HT-Oder-Nicht-Problem gar nicht zwingend was zu tun haben.
Klingt mir schwer nach Wartezyklen. Den VMs sind zuviele vCores zugeordnet. Jeder virtuelle Rechenoperation braucht eine physische Rechenoperation, also ein freies Plätzchen auf den echten, physischen CPUs. Gibt's bspw. 32 physische Kerne, aber 10 VMs (Beispiel) haben jede 8 virt. Kerne zugeordnet (=80), heißt es warten. Je mehr vCPUs, desto länger die Wartezyklen. CPU-Overprovisioning funktioniert bei VMware (keine Ahnung, wie die das machen), nicht jedoch bei Microsoft-Hyper-V.
Klingt mir schwer nach Wartezyklen. Den VMs sind zuviele vCores zugeordnet. Jeder virtuelle Rechenoperation braucht eine physische Rechenoperation, also ein freies Plätzchen auf den echten, physischen CPUs. Gibt's bspw. 32 physische Kerne, aber 10 VMs (Beispiel) haben jede 8 virt. Kerne zugeordnet (=80), heißt es warten. Je mehr vCPUs, desto länger die Wartezyklen. CPU-Overprovisioning funktioniert bei VMware (keine Ahnung, wie die das machen), nicht jedoch bei Microsoft-Hyper-V.
Glaub mir, das hat Problem hat mit Overprovisioning nicht wirklich etwas zu tun.
Wie ich schon geschrieben habe, gibt es diverseste Gründe, warum ein nicht HT-vCore undbedingt auch auf einen nicht HT-Core gemappt werden sollte.
Einer davon ist z.B. RSS (und somit zwagsweise auch VMQ und oder SR-IOV) welches es auch in einer VM gibt und RSS darf "konstruktionsbedingt" niemals über einen HT-Kern laufen. Aber genau das geschieht, wenn der Core Scheduler des Hyper-V 2022 hergeht und einen nicht HT-vCore auf einen HT-Core mappt. 😔
Beste Grüsse aus BaWü
Alex
Moin @commodity,
das ist so nicht korrekt, diese Einstellung hat mit den NUMA-Nodes innerhalb der VM genaugenommen überhaupt nicht zu tun, eher die folgende, grün Markiert Option. 😉
Bei diesem Post geht das um "Uniform Memory Access", respektive "Non-Uniform Memory Access", das ist nochmals ein anderes Thema.
Zudem hat sich der Schreiber des Artikels hat sich bei seinem Tipp entweder schlichtweg vertan oder die Konfig und deren Auswirkung, war beim Hyper-V 2012 R2 noch etwas anders.
Den um einen "Uniform Memory Access" sicherzustellen, muss man bei der Hyper-V (2016-2022) Konfiguration, lediglich den folgenden Hacken rausnehmen. 😉
Wie gesagt, auch das worüber dieser Schreiber hier meckert, lässt sich mit dem oben beschriebenen Schritt, sehr einfach deaktivieren.
Beste Grüsse aus BaWü
Alex
Die von Dir im ersten Bild oben rot umrandete Einstellung "Hardwarethreads pro Kern" ist von MS missverständlich (schlampig) bezeichnet. Sie hat imo nichts mit HT-Cores zu tun, sondern betrifft die Anzahl der zur Verfügung gestellten NUMA Nodes.
das ist so nicht korrekt, diese Einstellung hat mit den NUMA-Nodes innerhalb der VM genaugenommen überhaupt nicht zu tun, eher die folgende, grün Markiert Option. 😉
Bei diesem Post geht das um "Uniform Memory Access", respektive "Non-Uniform Memory Access", das ist nochmals ein anderes Thema.
Zudem hat sich der Schreiber des Artikels hat sich bei seinem Tipp entweder schlichtweg vertan oder die Konfig und deren Auswirkung, war beim Hyper-V 2012 R2 noch etwas anders.
Den um einen "Uniform Memory Access" sicherzustellen, muss man bei der Hyper-V (2016-2022) Konfiguration, lediglich den folgenden Hacken rausnehmen. 😉
Wie gesagt, auch das worüber dieser Schreiber hier meckert, lässt sich mit dem oben beschriebenen Schritt, sehr einfach deaktivieren.
Beste Grüsse aus BaWü
Alex
das ist so nicht korrekt,
Du hast recht. Bin in der Zeile verrutscht.Viele Grüße, commodity
Moin @3063370895,
danke für die wertvolle Info.
Ich behaupte ja auch nicht, dass das generell der Fall ist, in dieser Konstellation so wie es bei meinem diesem Kunden läuft, ist es aber so, sprich Murks.
Nun kann es gut sein, dass z.B. einer der folgenden Gründe dafür verantwortlich sein könnte.
- Der Hyper-V Core Scheduler kommt mit der in den Hyper-V Nodes verbauten und etwas älteren Xeon E5-2697A v4 CPU's nicht mehr gut zurecht.
- Der Hyper-V Core Scheduler kommt mit der 2012R2 VM an sich nicht mehr zurecht.
- Die Konfig der VM könnte z.B. durch die Versionsmigration zerschossen sein.
u.s.w. 😬
Noch habe ich aufgrund von Zeitmangel die naheliegendsten Verdächtigen noch nicht ausschliessen können, werde das nach und nach jedoch tun und hoffe dabei ehrlich gesagt auch etwas auf die Unterstützung durch die Comunity. 🙏
Beste Grüsse aus BaWü
Alex
Jetzt mit Hardwarethreads pro Kern: 1
Ist auch Windows Server 2022. Tatsächlich werden nur die jeweils ersten Cores belastet.
VM: ubuntu 22.04 4 vCPUs
Ist auch Windows Server 2022. Tatsächlich werden nur die jeweils ersten Cores belastet.
VM: ubuntu 22.04 4 vCPUs
stress --cpu 4danke für die wertvolle Info.
Ich behaupte ja auch nicht, dass das generell der Fall ist, in dieser Konstellation so wie es bei meinem diesem Kunden läuft, ist es aber so, sprich Murks.
Nun kann es gut sein, dass z.B. einer der folgenden Gründe dafür verantwortlich sein könnte.
- Der Hyper-V Core Scheduler kommt mit der in den Hyper-V Nodes verbauten und etwas älteren Xeon E5-2697A v4 CPU's nicht mehr gut zurecht.
- Der Hyper-V Core Scheduler kommt mit der 2012R2 VM an sich nicht mehr zurecht.
- Die Konfig der VM könnte z.B. durch die Versionsmigration zerschossen sein.
u.s.w. 😬
Noch habe ich aufgrund von Zeitmangel die naheliegendsten Verdächtigen noch nicht ausschliessen können, werde das nach und nach jedoch tun und hoffe dabei ehrlich gesagt auch etwas auf die Unterstützung durch die Comunity. 🙏
Beste Grüsse aus BaWü
Alex
- Der Hyper-V Core Scheduler kommt mit der 2012R2 VM an sich nicht mehr zurecht.
Diesen Punkt kann man von der Liste der möglichen Gründe gleich wieder streichen.
Habe soeben denselben Test auf einer 2022er VM gemacht und mit dieser passiert derselbe Murks. 😭
Hallo zusammen,
mag sein, dass ich gleich völligen Quatsch von mir gebe, aber ich hatte das bisher so verstanden:
Seit dem Server 2016 gibt es den "klassischen" Hyper-V- Scheduler und den Kernplaner.
Die Einstellung "HW Threads per Core" = 1 wirkt sich mWn auf das SMT Verhalten aus:
0 -> erben vom Hypervisor
1 -> kein SMT
2 -> SMT
[Quelle: https://learn.microsoft.com/de-de/windows-server/virtualization/hyper-v/ ...]
Somit ist bei der Einstellung 1 doch lediglich gesagt, dass auf einem Kern (also der Kombi aus dem "echten" und dem HT Kern) zu einem Zeitpunkt nur 1 Thread einer VM laufen darf.
Es wird verhindert, dass auf den beiden Teilen eines Kerns Threads von 2 unterschiedlichen VMs laufen.
Auf dem "anderen" Teil des Kerns kann also nur Workload des Hypervisors laufen.
Es ist aber nicht garantiert, dass die workload einer VM nicht auf dem HT Kern läuft.
Das deckt sich ja auch mit den Bildern die im ersten Beitrag zu sehen sind.
Meinem Verständnis nach also bei HWThreads per Core = 1:
- Workloads von unterschiedlichen VMs laufen nie auf dem selben Kern
- Es ist nicht garantiert, dass die Workload auf dem physikalischen Kern läuft, die kann auch auf dem HT Kern sein
Um das zu verhindern müsstest Du HT für den Prozessor deaktivieren.
Wie gesagt so ist mein Verständnis der Sache..ich lass mich aber gerne korrigieren.
Achso: Wenn du jeweils 8 Kerne für einen RDSH hast und mehr als 4 RDSH hast die Kerne ja überprovisioniert und dann bekommt eine VM doch nur dann CPU-Kappa, wenn 8 Kerne frei sind.
Und da der Core-Scheduler eben verhindert, dass mehrere VMs auf einem Kern laufen muss eine der VMs quasi im Idle sein, damit die, die CPU-Kappa braucht drankommt, oder hab ich da nen Denkfehler.
S.
uichen
mag sein, dass ich gleich völligen Quatsch von mir gebe, aber ich hatte das bisher so verstanden:
Seit dem Server 2016 gibt es den "klassischen" Hyper-V- Scheduler und den Kernplaner.
Die Einstellung "HW Threads per Core" = 1 wirkt sich mWn auf das SMT Verhalten aus:
0 -> erben vom Hypervisor
1 -> kein SMT
2 -> SMT
[Quelle: https://learn.microsoft.com/de-de/windows-server/virtualization/hyper-v/ ...]
Somit ist bei der Einstellung 1 doch lediglich gesagt, dass auf einem Kern (also der Kombi aus dem "echten" und dem HT Kern) zu einem Zeitpunkt nur 1 Thread einer VM laufen darf.
Es wird verhindert, dass auf den beiden Teilen eines Kerns Threads von 2 unterschiedlichen VMs laufen.
Auf dem "anderen" Teil des Kerns kann also nur Workload des Hypervisors laufen.
Es ist aber nicht garantiert, dass die workload einer VM nicht auf dem HT Kern läuft.
Das deckt sich ja auch mit den Bildern die im ersten Beitrag zu sehen sind.
Meinem Verständnis nach also bei HWThreads per Core = 1:
- Workloads von unterschiedlichen VMs laufen nie auf dem selben Kern
- Es ist nicht garantiert, dass die Workload auf dem physikalischen Kern läuft, die kann auch auf dem HT Kern sein
Um das zu verhindern müsstest Du HT für den Prozessor deaktivieren.
Wie gesagt so ist mein Verständnis der Sache..ich lass mich aber gerne korrigieren.
Achso: Wenn du jeweils 8 Kerne für einen RDSH hast und mehr als 4 RDSH hast die Kerne ja überprovisioniert und dann bekommt eine VM doch nur dann CPU-Kappa, wenn 8 Kerne frei sind.
Und da der Core-Scheduler eben verhindert, dass mehrere VMs auf einem Kern laufen muss eine der VMs quasi im Idle sein, damit die, die CPU-Kappa braucht drankommt, oder hab ich da nen Denkfehler.
S.
uichen
RDS workloads beschleunigt das Hyperthreading kein Stücken... ich hatte neulich mal einen Test automatisiert, auf einem 8 Core / 16 Threads Xeon Prozessor. Ein RDP-Workflow hatte pro Session 100% CPU Last über ca. eine Stunde, eine CAD Anwendung und Word/Excel. Acht davon liefen parallel mit geringen Schwankungen in der Laufzeit. HyperV meldet mir 50% Last am Host, VMware 100%
Als ich mit aktivem Hypterthreading einen neunten RDP Client und einen neunten Workflow gestartet hatte, lief einer der 9 dann doppelt so lang, ab dem 10. wurde der Terminalserver dann instabil. Egal welcher Hypervisor. Das Problem ist daß der Scheduler im Gast am Ende die Threads nicht in Zeitscheiben fair verteilt sondern die Threads alle 5 Sekunden von einem zum anderen Core shiftet, und das ist seit Server 2012R2 so. Bis 2008R2 teilten sich zwei Prozesse brüderlich einen Core... für Multithreading ist der 2012 R2 Ansatz zwar effektiver für Einzelsitzungen, aber eine große Masse an UserSitzungen wird unfairer mit Rechenleistung bedient.
Ist auch Feedback vieler Kunden, die auf HyperV 2022 migriert haben.
Weil man auf Intel-Cores ziemlich viele nicht teilbare Ressourcen hat, die nur ein Thread nutzen kann, so Sachen wie FPU, SSE3, MMX, Kryptographie... läuft ein Workload auf einem 2. Thread dann tut der das nur dann, wenn keine unteilbaren Ressourcen im Spiel sind.
VMware bildet das z.B. auch korrekt ab aber HyperV basiert bei der Core-Konfiguration auf der irrigen Annahme, daß man damit noch mehr rausholen kann. Aus der Praxis mit Office-RDPs ist es besser, Core-Overcommitment zu machen wie auf Hyperthreading zu vertrauen.
Als ich mit aktivem Hypterthreading einen neunten RDP Client und einen neunten Workflow gestartet hatte, lief einer der 9 dann doppelt so lang, ab dem 10. wurde der Terminalserver dann instabil. Egal welcher Hypervisor. Das Problem ist daß der Scheduler im Gast am Ende die Threads nicht in Zeitscheiben fair verteilt sondern die Threads alle 5 Sekunden von einem zum anderen Core shiftet, und das ist seit Server 2012R2 so. Bis 2008R2 teilten sich zwei Prozesse brüderlich einen Core... für Multithreading ist der 2012 R2 Ansatz zwar effektiver für Einzelsitzungen, aber eine große Masse an UserSitzungen wird unfairer mit Rechenleistung bedient.
Ist auch Feedback vieler Kunden, die auf HyperV 2022 migriert haben.
Weil man auf Intel-Cores ziemlich viele nicht teilbare Ressourcen hat, die nur ein Thread nutzen kann, so Sachen wie FPU, SSE3, MMX, Kryptographie... läuft ein Workload auf einem 2. Thread dann tut der das nur dann, wenn keine unteilbaren Ressourcen im Spiel sind.
VMware bildet das z.B. auch korrekt ab aber HyperV basiert bei der Core-Konfiguration auf der irrigen Annahme, daß man damit noch mehr rausholen kann. Aus der Praxis mit Office-RDPs ist es besser, Core-Overcommitment zu machen wie auf Hyperthreading zu vertrauen.
Moin @SvenTej,
ja und dieser wurde nur beim Server 2016 verwendet.
Ab Server 2019 läuft per default der "Core" Core-Scheduler.
https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/ ...
Nein nix Kombi, 1 bedeutet dass der Hyper-V in der VM einen physikalischen Kern ohne Hyperthreading, sprich, ohne SMT-Fähigkeit, sprich, mit nur einer Ausführungseinheit "emuliert".
Und wenn du 2 auswählst, dann wird ein physikalischer Kern mit 2 Ausführungseinheiten "emuliert".
Ferner macht das ganze HT Geraffel nur dann Sinn, wenn auf der 1 und der 2 Ausführungseinheit desselben physikalischen Kerns, ein und dieselbe Anwendung mit 2 Threads läuft, die wiederum beide möglichst auf dieselben Speicherbereiche zugreifen. 😉
Das sollte eh niemals so sein, das auf der einen Ausführungseinheit desselben physikalischen Kerns, ein Threads von z.B. der VM-A abgearbeitet wird und "gleichzeitig" auf der zweiten ein Thread von der VM-B, weil das insbesondere leitungsmässig nur einen Nachteil bringen würde. 😉
Also wenn ich in einer VM einstelle, dass diese eine CPU "emuliert" soll, die nur physikalische Kerne, sprich, nur eine Ausführungseinheit pro vKern hat, dann erwarte ich, dass der Core-Scheduler diese Kerne auch ausschliesslich auf die erste Ausführungseinheit eines echten physikalischen Kerns des Hypervisors mappt und nicht auf die zweite, wie es in meinem Beispiel, leider der Fall ist.
Das muss auch so sein, weil es diverse Dinge wie z.B. RSS gibt, welches wie ich schon geschrieben habe, nur auf der ersten Ausführungseinheit eines physikalischen Kerns laufen dürfen, auch bei einer VM.
Nicht gleichzeitig, jedoch sehr wohl ganz schnell nacheinander. 😉
Ich glaube du solltest dich noch etwas genauer darüber informieren, wie HT wirklich funktioniert und insbesondere wann es genau Sinn macht und wann nicht, ich sehe da noch einige Lücken.
Das ist jedoch auf der anderen Seite einfacher gesagt wie getan, den die meisten Seiten die ich jetzt auf die Schnelle gefunden habe, beschreiben die Technologie leider viel zu oberflächlich. 😔
Wenn ich diesbezüglich was brauchbares gefunden habe, dann poste ich es nach.
Ich habe pro RDS VM 8 Logische Kerne (4 "physikalische", +je ein HT) und der entsprechende Hyper-V Node hat in Summe 64 Logische Kerne (32 "physikalische", +je ein HT).
Sprich, auf diesem Node kann man von diesen RDS-VM's locker 8 gleichzeitig ausführen, ohne dabei die CPU's dieses Nodes auch nur ansatzweise zu überprovisionieren. 😉
Denkfehler. HT befähigt einen Kern lediglich dazu zwei Befehle gleichzeitig anzunehmen, nicht jedoch dazu diese auch gleichzeitig auszuführen. 😉
Beste Grüsse aus BaWü
Alex
Seit dem Server 2016 gibt es den "klassischen" Hyper-V- Scheduler und den Kernplaner.
ja und dieser wurde nur beim Server 2016 verwendet.
Ab Server 2019 läuft per default der "Core" Core-Scheduler.
https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/ ...
Die Einstellung "HW Threads per Core" = 1 wirkt sich mWn auf das SMT Verhalten aus:
0 -> erben vom Hypervisor
1 -> kein SMT
2 -> SMT
[Quelle: https://learn.microsoft.com/de-de/windows-server/virtualization/hyper-v/ ...]
Somit ist bei der Einstellung 1 doch lediglich gesagt, dass auf einem Kern (also der Kombi aus dem "echten" und dem HT Kern) zu einem Zeitpunkt nur 1 Thread einer VM laufen darf.
0 -> erben vom Hypervisor
1 -> kein SMT
2 -> SMT
[Quelle: https://learn.microsoft.com/de-de/windows-server/virtualization/hyper-v/ ...]
Somit ist bei der Einstellung 1 doch lediglich gesagt, dass auf einem Kern (also der Kombi aus dem "echten" und dem HT Kern) zu einem Zeitpunkt nur 1 Thread einer VM laufen darf.
Nein nix Kombi, 1 bedeutet dass der Hyper-V in der VM einen physikalischen Kern ohne Hyperthreading, sprich, ohne SMT-Fähigkeit, sprich, mit nur einer Ausführungseinheit "emuliert".
Und wenn du 2 auswählst, dann wird ein physikalischer Kern mit 2 Ausführungseinheiten "emuliert".
Ferner macht das ganze HT Geraffel nur dann Sinn, wenn auf der 1 und der 2 Ausführungseinheit desselben physikalischen Kerns, ein und dieselbe Anwendung mit 2 Threads läuft, die wiederum beide möglichst auf dieselben Speicherbereiche zugreifen. 😉
Es wird verhindert, dass auf den beiden Teilen eines Kerns Threads von 2 unterschiedlichen VMs laufen.
Auf dem "anderen" Teil des Kerns kann also nur Workload des Hypervisors laufen.
Auf dem "anderen" Teil des Kerns kann also nur Workload des Hypervisors laufen.
Das sollte eh niemals so sein, das auf der einen Ausführungseinheit desselben physikalischen Kerns, ein Threads von z.B. der VM-A abgearbeitet wird und "gleichzeitig" auf der zweiten ein Thread von der VM-B, weil das insbesondere leitungsmässig nur einen Nachteil bringen würde. 😉
Es ist aber nicht garantiert, dass die workload einer VM nicht auf dem HT Kern läuft.
Also wenn ich in einer VM einstelle, dass diese eine CPU "emuliert" soll, die nur physikalische Kerne, sprich, nur eine Ausführungseinheit pro vKern hat, dann erwarte ich, dass der Core-Scheduler diese Kerne auch ausschliesslich auf die erste Ausführungseinheit eines echten physikalischen Kerns des Hypervisors mappt und nicht auf die zweite, wie es in meinem Beispiel, leider der Fall ist.
Das muss auch so sein, weil es diverse Dinge wie z.B. RSS gibt, welches wie ich schon geschrieben habe, nur auf der ersten Ausführungseinheit eines physikalischen Kerns laufen dürfen, auch bei einer VM.
- Workloads von unterschiedlichen VMs laufen nie auf dem selben Kern
Nicht gleichzeitig, jedoch sehr wohl ganz schnell nacheinander. 😉
- Es ist nicht garantiert, dass die Workload auf dem physikalischen Kern läuft, die kann auch auf dem HT Kern sein
Ich glaube du solltest dich noch etwas genauer darüber informieren, wie HT wirklich funktioniert und insbesondere wann es genau Sinn macht und wann nicht, ich sehe da noch einige Lücken.
Das ist jedoch auf der anderen Seite einfacher gesagt wie getan, den die meisten Seiten die ich jetzt auf die Schnelle gefunden habe, beschreiben die Technologie leider viel zu oberflächlich. 😔
Wenn ich diesbezüglich was brauchbares gefunden habe, dann poste ich es nach.
Achso: Wenn du jeweils 8 Kerne für einen RDSH hast und mehr als 4 RDSH hast die Kerne ja überprovisioniert und dann bekommt eine VM doch nur dann CPU-Kappa, wenn 8 Kerne frei sind.
Ich habe pro RDS VM 8 Logische Kerne (4 "physikalische", +je ein HT) und der entsprechende Hyper-V Node hat in Summe 64 Logische Kerne (32 "physikalische", +je ein HT).
Sprich, auf diesem Node kann man von diesen RDS-VM's locker 8 gleichzeitig ausführen, ohne dabei die CPU's dieses Nodes auch nur ansatzweise zu überprovisionieren. 😉
Und da der Core-Scheduler eben verhindert, dass mehrere VMs auf einem Kern laufen muss eine der VMs quasi im Idle sein, damit die, die CPU-Kappa braucht drankommt, oder hab ich da nen Denkfehler.
Denkfehler. HT befähigt einen Kern lediglich dazu zwei Befehle gleichzeitig anzunehmen, nicht jedoch dazu diese auch gleichzeitig auszuführen. 😉
Beste Grüsse aus BaWü
Alex
Moin @GrueneSosseMitSpeck,
Das ist so nicht ganz richtig. Wenn auf den RDS-Sessionhosts eine Software läuft die für HT optimiert wurde und der Core-Scheduler die vCores auch korrekt auf die Cores mappen würde, dann würdest du sehr wohl einen Unterschied bei mit oder ohne HT sehen.
Wenn man jedoch eine Software hat die nicht für HT optimiert wurde und den Murks des Core Schedulers den ich hier anspreche mit dazu packt, dann kommt +- genau das raus was du beschreibst. 😔
Beste Grüsse aus BaWü
Alex
RDS workloads beschleunigt das Hyperthreading kein Stücken...
Das ist so nicht ganz richtig. Wenn auf den RDS-Sessionhosts eine Software läuft die für HT optimiert wurde und der Core-Scheduler die vCores auch korrekt auf die Cores mappen würde, dann würdest du sehr wohl einen Unterschied bei mit oder ohne HT sehen.
Wenn man jedoch eine Software hat die nicht für HT optimiert wurde und den Murks des Core Schedulers den ich hier anspreche mit dazu packt, dann kommt +- genau das raus was du beschreibst. 😔
Beste Grüsse aus BaWü
Alex
- Der Hyper-V Core Scheduler kommt mit der in den Hyper-V Nodes verbauten und etwas älteren Xeon E5-2697A v4 CPU's nicht mehr gut zurecht.
Verflixt, diesen möglichen Grund können wir auch streichen.
Habe heute Nachmittag einen Test auf einem Hyper-V Node, der mit zwei Xeon Gold 6254 bestückt ist gemacht ... leider selber Murks. 🤢🤮😭
Hallo,
Wie definierst Du "Hardware-Kerne" und "Hyperthreading-Kerne"? Wenn Hyperthreading aktiviert ist, gibt es an sich nur "Hyperthreading-Kerne". Steht auch darüber: "Logische Prozessoren"
Nein, das Setting sperrt die Zuweisung von zweien der 8 Threads einer VM mit 8 vCPUs an die beiden logischen Kerne desselben physikalischen Kerns.
Vgl. dazu die Abbildung von 8 vCPUs in der VM: Mit der Einstellung 0 auf einer Hyperthreading-Platform gibt die WMI-Abfrage in der VM 8 logische, aber nur 4 physikalische Kerne an. Dabei handelt es sich um den Worst-Case im Hypervisor-Scheduling, denn in der Regel werden die 8 Threads auf mehr als vier physische Cores verteilt werden können. Deshalb spricht der Taskmanager nur von 8 "virtuellen Prozessoren". Hingegen mit der Einstellung 1 wird dies erzwungen, und in der VM werden daher 8 logische und 8 physische Kerne angegeben.
Alle 8 Threads liegen auf unterschiedlichen physikalischen Kernen, wie erwartet.
Grüße
Richard
Die mit einem grünen Pfeil markierten Spalten stellen die Auslastung der physikalischen Kerne dar und die mit einem roten Pfeil markierten Spalten, stellen die Auslastung deren Hyperthreading Kerne dar. Und die rot umrandeten, sind die Kerne auf denen die Last der angesprochenen VM abgetragen wurde.
Wie definierst Du "Hardware-Kerne" und "Hyperthreading-Kerne"? Wenn Hyperthreading aktiviert ist, gibt es an sich nur "Hyperthreading-Kerne". Steht auch darüber: "Logische Prozessoren"
Demzufolge sollte die Last dieser VM eigentlich nur noch über die physikalischen Kerne des Hyper-V Nodes abgetragen werden und nicht mehr auch über dessen Hyperthreading Kerne
Nein, das Setting sperrt die Zuweisung von zweien der 8 Threads einer VM mit 8 vCPUs an die beiden logischen Kerne desselben physikalischen Kerns.
Vgl. dazu die Abbildung von 8 vCPUs in der VM: Mit der Einstellung 0 auf einer Hyperthreading-Platform gibt die WMI-Abfrage in der VM 8 logische, aber nur 4 physikalische Kerne an. Dabei handelt es sich um den Worst-Case im Hypervisor-Scheduling, denn in der Regel werden die 8 Threads auf mehr als vier physische Cores verteilt werden können. Deshalb spricht der Taskmanager nur von 8 "virtuellen Prozessoren". Hingegen mit der Einstellung 1 wird dies erzwungen, und in der VM werden daher 8 logische und 8 physische Kerne angegeben.
Wie ihr erkennen könnt, wurde in 7 von 8 Fällen, die CPU Last eines vCores der explizit als NICHT HT-Kern konfiguriert wurde, über einen HT-Kern des Hyper-V Nodes abgetragen.
Alle 8 Threads liegen auf unterschiedlichen physikalischen Kernen, wie erwartet.
Grüße
Richard
Moin @c.r.s.,
na ja, das mit Hardware-Kerne und Hyperthreading-Kerne ist meinerseits etwas ungeschickt ausgedrückt.
Den in Wahrheit ist es ein und derselbe Kern, der in Falle von ohne Hyperthreading, vereinfacht ausgedrückt nur eine aktive (primäre) Befehlswarteschlange hat und mit Hyperthreading, bekommt jeder Kern noch eine weitere (sekundäre) Befehlswarteschlange freigeschaltet. Beide Warteschlangen arbeiten ihre Befehle jedoch über ein und dieselbe Recheneinheit ab, und zwar nacheinander und nicht gleichzeitig.
Und die primäre Warteschlange eines physikalischen Kerns mit aktiviertem HT, bezeichne ich als Hardware-Kern und die sekundäre als "Hyperthreading-Kern" oder auch "Fake-Kern", weil diesem nicht wirklich eine eigenständige Recheneinheit zur Verfügung steht.
Nein, das ist eine Fehlinterpretation, die durch die ungeschickte anzeige im Taskmanager auch noch weiter angeschürt wird, weil dieser in einer VM nur noch stur virtuelle Prozessoren anzeigt, und zwar egal ob HT aktiviert ist oder nicht.
Wenn du jedoch in der VM den folgenden Befehl eingibst ...
dann siehst du genau, wie sich diese virtuelle Prozessoren "zusammensetzen".
Folgend ein Beispiel von einer VM mit 8 Kernen und aktiviertem HT(SMT).
Wie du sehen kannst, wird für diese VM eine CPU Emuliert, die nur 4 "physikalische" Kerne hat, auf die sich 8 logische Kerne verteilen, sprich, ist selbe wie auch bei realer Hardware, 4 physikalische Kerne, plus 4 Fake-Kerne. 😉
Und warum, den genau das sollte es eigentlich nicht tun.
Der Core Scheduler sollte diese eigentlich immer paarweise ummappen, so wie es im Bild des folgenden Posts von @3063370895 zu sehen ist.
Kurioses vCore to Core Mapping beim Hyper-V 2022
By the Way, ich habe den Grund für das Problem heute Nacht schon gefunden, dazu komme ich aber etwas später. 😁
Das ist auch vollkommen richtig und ein Hardwarerechner mit einer 4 Kern CPU und aktiviertem HT würde dir an dieser stelle exakt dasselbe ausspucken. 😉
Ähm, alle logischen Kerne einer VM werden von der Anzahl her immer 1:1 auf die logischen Kerne des Hypervisors umgehabt.
Mit der Einstellung 1 erzwingst du lediglich, dass der Hyper-V der VM eine 8-Kern vCPU ohne HT vorgaukelt, sprich eine CPU die nur physikalische Kerne und keine Fake-Kerne hat, daher entspricht auch die Anzahl der logischen Kerne der der physikalischen Kerne.
Ja, aber auf den falschen Kernen (Fake-Kernen) und selbst wenn ich auf dieser VM SMT aktiviere, wird die Last der 8 Kerne nicht paarweise auf die Kerne des Hypervisors verteilt, sondern über seiner 8 physikalische Kerne verteilt, was ein kompletter Humbug ist.
Gedulde dich noch ein bisschen, ich habe wie schon vorher erwähnt den Übeltäter gefunden. 😁
Wenn alles gut geht, dann poste ich heute Nachmittag ein bisschen mehr dazu.
Beste Grüsse aus BaWü
Alex
Wie definierst Du "Hardware-Kerne" und "Hyperthreading-Kerne"?
na ja, das mit Hardware-Kerne und Hyperthreading-Kerne ist meinerseits etwas ungeschickt ausgedrückt.
Den in Wahrheit ist es ein und derselbe Kern, der in Falle von ohne Hyperthreading, vereinfacht ausgedrückt nur eine aktive (primäre) Befehlswarteschlange hat und mit Hyperthreading, bekommt jeder Kern noch eine weitere (sekundäre) Befehlswarteschlange freigeschaltet. Beide Warteschlangen arbeiten ihre Befehle jedoch über ein und dieselbe Recheneinheit ab, und zwar nacheinander und nicht gleichzeitig.
Und die primäre Warteschlange eines physikalischen Kerns mit aktiviertem HT, bezeichne ich als Hardware-Kern und die sekundäre als "Hyperthreading-Kern" oder auch "Fake-Kern", weil diesem nicht wirklich eine eigenständige Recheneinheit zur Verfügung steht.
Wenn Hyperthreading aktiviert ist, gibt es an sich nur "Hyperthreading-Kerne". Steht auch darüber: "Logische Prozessoren"
Nein, das ist eine Fehlinterpretation, die durch die ungeschickte anzeige im Taskmanager auch noch weiter angeschürt wird, weil dieser in einer VM nur noch stur virtuelle Prozessoren anzeigt, und zwar egal ob HT aktiviert ist oder nicht.
Wenn du jedoch in der VM den folgenden Befehl eingibst ...
wmic cpu get NumberOfCores, NumberOfLogicalProcessors/Format:Listdann siehst du genau, wie sich diese virtuelle Prozessoren "zusammensetzen".
Folgend ein Beispiel von einer VM mit 8 Kernen und aktiviertem HT(SMT).
Wie du sehen kannst, wird für diese VM eine CPU Emuliert, die nur 4 "physikalische" Kerne hat, auf die sich 8 logische Kerne verteilen, sprich, ist selbe wie auch bei realer Hardware, 4 physikalische Kerne, plus 4 Fake-Kerne. 😉
Nein, das Setting sperrt die Zuweisung von zweien der 8 Threads einer VM mit 8 vCPUs an die beiden logischen Kerne desselben physikalischen Kerns.
Und warum, den genau das sollte es eigentlich nicht tun.
Der Core Scheduler sollte diese eigentlich immer paarweise ummappen, so wie es im Bild des folgenden Posts von @3063370895 zu sehen ist.
Kurioses vCore to Core Mapping beim Hyper-V 2022
By the Way, ich habe den Grund für das Problem heute Nacht schon gefunden, dazu komme ich aber etwas später. 😁
Vgl. dazu die Abbildung von 8 vCPUs in der VM: Mit der Einstellung 0 auf einer Hyperthreading-Platform gibt die WMI-Abfrage in der VM 8 logische, aber nur 4 physikalische Kerne an.
Das ist auch vollkommen richtig und ein Hardwarerechner mit einer 4 Kern CPU und aktiviertem HT würde dir an dieser stelle exakt dasselbe ausspucken. 😉
Dabei handelt es sich um den Worst-Case im Hypervisor-Scheduling, denn in der Regel werden die 8 Threads auf mehr als vier physische Cores verteilt werden können.
Ähm, alle logischen Kerne einer VM werden von der Anzahl her immer 1:1 auf die logischen Kerne des Hypervisors umgehabt.
Deshalb spricht der Taskmanager nur von 8 "virtuellen Prozessoren". Hingegen mit der Einstellung 1 wird dies erzwungen, und in der VM werden daher 8 logische und 8 physische Kerne angegeben.
Mit der Einstellung 1 erzwingst du lediglich, dass der Hyper-V der VM eine 8-Kern vCPU ohne HT vorgaukelt, sprich eine CPU die nur physikalische Kerne und keine Fake-Kerne hat, daher entspricht auch die Anzahl der logischen Kerne der der physikalischen Kerne.
Alle 8 Threads liegen auf unterschiedlichen physikalischen Kernen, wie erwartet.
Ja, aber auf den falschen Kernen (Fake-Kernen) und selbst wenn ich auf dieser VM SMT aktiviere, wird die Last der 8 Kerne nicht paarweise auf die Kerne des Hypervisors verteilt, sondern über seiner 8 physikalische Kerne verteilt, was ein kompletter Humbug ist.
Gedulde dich noch ein bisschen, ich habe wie schon vorher erwähnt den Übeltäter gefunden. 😁
Wenn alles gut geht, dann poste ich heute Nachmittag ein bisschen mehr dazu.
Beste Grüsse aus BaWü
Alex
@alex
okay dann bin ich raus, wenn mein Verständnis des MS Artikels so grundsätzlich falsch ist und deiner Meinung nach alles was ich da lese ganz anders ist.
Und dass ich bezüglich HT nochmal was lernen muss:
Danke für den netten Hinweis dass ich nichts weiß.
Wie gesagt:
Sorry für den angeblichen Quatsch und Nonsens den ich von mir gegeben habe und Info an die, die das später lesen:
Ignoriert einfach was da von mir steht, Alex hat bestimmt recht, und der MS Artikel ist auch falsch.
Und @Richard:
Komisch, dass Du offenbar genauso falsch liegst wie ich .... denn du erklärst Alex irgendwie dasselbe wie ich - nur eben in anderen Worten....
SMT=1 --> 8 vCPUs der VM erden vom Hypervisor auf 8 pCPUs gemappt
Und da der Hypervisor die "echten" und "´Fake" Kerne eben nicht trennt ,macht er es doch richtig....
Dass hier dann KEINE Überprovisionierung vorliegt kann ich nicht ganz nachvollziehen (8x5 = 40. 40>32....ich habs aber eben nochmal von meinem Neffen in der 2 Klasse nachrechnen lassen um zu verhindern, dass ich in Algebra noch Nacholbedarf habe)
S.
PS:
Wer Sarkasmus findet darf ihn behalten
okay dann bin ich raus, wenn mein Verständnis des MS Artikels so grundsätzlich falsch ist und deiner Meinung nach alles was ich da lese ganz anders ist.
Und dass ich bezüglich HT nochmal was lernen muss:
Danke für den netten Hinweis dass ich nichts weiß.
Wie gesagt:
Sorry für den angeblichen Quatsch und Nonsens den ich von mir gegeben habe und Info an die, die das später lesen:
Ignoriert einfach was da von mir steht, Alex hat bestimmt recht, und der MS Artikel ist auch falsch.
Und @Richard:
Komisch, dass Du offenbar genauso falsch liegst wie ich .... denn du erklärst Alex irgendwie dasselbe wie ich - nur eben in anderen Worten....
SMT=1 --> 8 vCPUs der VM erden vom Hypervisor auf 8 pCPUs gemappt
Und da der Hypervisor die "echten" und "´Fake" Kerne eben nicht trennt ,macht er es doch richtig....
Dass hier dann KEINE Überprovisionierung vorliegt kann ich nicht ganz nachvollziehen (8x5 = 40. 40>32....ich habs aber eben nochmal von meinem Neffen in der 2 Klasse nachrechnen lassen um zu verhindern, dass ich in Algebra noch Nacholbedarf habe)
S.
PS:
Wer Sarkasmus findet darf ihn behalten
Moin @SvenTej,
ich habe dir lediglich gesagt, dass dein Verständnis von HT noch nicht ganz korrekt ist und dass du dieses noch etwas erweitert solltest. Dass du überhaupt nichts davon verstehst, habe ich hingegen nirgends geschrieben.
Und ja, ich bin manchmal etwas direkt, aber daran muss du dich bei mir gewöhnen und dir das unnötige Herumgezicke wiederum etwas abgewöhnen.
und was genau meinst du nun mit einem pCPU?
Wie kommst du jetzt bitte auf die Idee , dass der Hypervisor nicht zwischen den Echten-Kernen und den Fake-Kernen unterscheiden kann?
Erkläre mir mal bitte wie du auf 8x5 kommst, dann erkläre ich dir auch wo dein Neffe sich verrechnet hat.
Danke, habe selbst genug davon, aber noch hast du mich nicht soweit, dass ich diesen Vorrat meinerseits auch anzapfen muss.
Beste Grüsse aus BaWü
Alex
okay dann bin ich raus, wenn mein Verständnis des MS Artikels so grundsätzlich falsch ist und deiner Meinung nach alles was ich da lese ganz anders ist.
Und dass ich bezüglich HT nochmal was lernen muss:
Danke für den netten Hinweis dass ich nichts weiß.
Danke für den netten Hinweis dass ich nichts weiß.
ich habe dir lediglich gesagt, dass dein Verständnis von HT noch nicht ganz korrekt ist und dass du dieses noch etwas erweitert solltest. Dass du überhaupt nichts davon verstehst, habe ich hingegen nirgends geschrieben.
Und ja, ich bin manchmal etwas direkt, aber daran muss du dich bei mir gewöhnen und dir das unnötige Herumgezicke wiederum etwas abgewöhnen.
SMT=1 --> 8 vCPUs der VM erden vom Hypervisor auf 8 pCPUs gemappt
und was genau meinst du nun mit einem pCPU?
Und da der Hypervisor die "echten" und "´Fake" Kerne eben nicht trennt ,macht er es doch richtig....
Wie kommst du jetzt bitte auf die Idee , dass der Hypervisor nicht zwischen den Echten-Kernen und den Fake-Kernen unterscheiden kann?
Dass hier dann KEINE Überprovisionierung vorliegt kann ich nicht ganz nachvollziehen (8x5 = 40. 40>32....ich habs aber eben nochmal von meinem Neffen in der 2 Klasse nachrechnen lassen um zu verhindern, dass ich in Algebra noch Nacholbedarf habe)
Erkläre mir mal bitte wie du auf 8x5 kommst, dann erkläre ich dir auch wo dein Neffe sich verrechnet hat.
Wer Sarkasmus findet darf ihn behalten
Danke, habe selbst genug davon, aber noch hast du mich nicht soweit, dass ich diesen Vorrat meinerseits auch anzapfen muss.
Beste Grüsse aus BaWü
Alex
Moin @SvenTej,
schau mal, dieses Schaubild von Intel welches von einem Techniker erstellt wurde. Dieses stellt die funktionsweise von HT vollkommen richtig dar.
Sprich, mit HT kann der entsprechende Kern quasi 2 Befehle gleichzeitig annehmen, tut diese aber der reihe nach verarbeiten.
Dieses Schaubild welches ebenfalls von Intel stammt, wurde jedoch nicht von einem Techniker erstellt, sondern von einem Marketingmitarbeiter mit etwas technischem Verständnis.
Und daher suggeriert dieses, nämlich das man mit HT zwei Dinge parallel verarbeiten kann, auch einen absoluten Humbug. 😉
Beste Grüsse aus BaWü
Alex
schau mal, dieses Schaubild von Intel welches von einem Techniker erstellt wurde. Dieses stellt die funktionsweise von HT vollkommen richtig dar.
Sprich, mit HT kann der entsprechende Kern quasi 2 Befehle gleichzeitig annehmen, tut diese aber der reihe nach verarbeiten.
Dieses Schaubild welches ebenfalls von Intel stammt, wurde jedoch nicht von einem Techniker erstellt, sondern von einem Marketingmitarbeiter mit etwas technischem Verständnis.
Und daher suggeriert dieses, nämlich das man mit HT zwei Dinge parallel verarbeiten kann, auch einen absoluten Humbug. 😉
Beste Grüsse aus BaWü
Alex
Zitat von @MysticFoxDE:
Und die primäre Warteschlange eines physikalischen Kerns mit aktiviertem HT, bezeichne ich als Hardware-Kern und die sekundäre als "Hyperthreading-Kern" oder auch "Fake-Kern", weil diesem nicht wirklich eine eigenständige Recheneinheit zur Verfügung steht.
Und die primäre Warteschlange eines physikalischen Kerns mit aktiviertem HT, bezeichne ich als Hardware-Kern und die sekundäre als "Hyperthreading-Kern" oder auch "Fake-Kern", weil diesem nicht wirklich eine eigenständige Recheneinheit zur Verfügung steht.
Es gibt aber keine Hierarchie zwischen dem "primären" und "sekundären" Hyperthreading-Kern, die es rechtfertigen würde, in den Taskmanager Spalten einzuzeichnen und zu erwarten, dass für vier saturierende Threads genau die logischen Kerne 0, 2, 4, 6, und nicht 1, 3, 5, 7, oder auch 0, 3, 5, 6 verwendet würden. Begründe das doch mal.
Nein, das ist eine Fehlinterpretation, die durch die ungeschickte anzeige im Taskmanager auch noch weiter angeschürt wird, weil dieser in einer VM nur noch stur virtuelle Prozessoren anzeigt, und zwar egal ob HT aktiviert ist oder nicht.
Ich meinte hier auf dem Host. Der Taskmanager zeigt vollkommen richtig an, was das OS bzw. ein Hypervisor sieht: n logische Kerne, zusammen mit der Information, dass diese paarweise n/2 physischen Kernen zugeordnet sind. Diese Information ist relevant; aber über welchen logischen Kern ein physischer Kern belastet wird, ist egal.
Wie du sehen kannst, wird für diese VM eine CPU Emuliert, die nur 4 "physikalische" Kerne hat, auf die sich 8 logische Kerne verteilen, sprich, ist selbe wie auch bei realer Hardware, 4 physikalische Kerne, plus 4 Fake-Kerne. 😉
Nein, es wird in dem Sinne keine CPU "emuliert", das wäre viel zu aufwändig. Auch die VM unterscheidet nicht die tollen pysikalischen Kerne und niedere Fake-Kerne, sondern eben n logische Kerne mit der Info Hyperthreading ja/nein. Wenn Hyperthreading "durchgereicht" wird, teilt die Ausgabe der WMI-Abfrage n durch zwei und zeigt das Ergebnis als physische Kerne an, weil sie für den Umstand der virtuellen Ausführung nicht angepasst ist.
Das ist irreführend, und deshalb macht es der Taskmanager anders. Auch der Taskmanager zeigt bekanntlich auf physischer Hardware logische und physische Kerne an. In der VM sind "virtuelle Kerne" (bzw. "Prozessoren", wie dort Kerne generell genannt werden) aber präziser: Da es hierbei keine "Emulation" von n/2 physischen Kernen gibt, gibt es für die VM mit n vCPUs auf Hyperthreading keinerlei Garantie durch den Hypervisor, dass ihre Hypervisor-Threads auf höchstens n/2 physischen Kernen ausgeführt werden. Im Gegenteil, ein solches restriktives Verhalten wäre nicht sinnvoll und wird vom Scheduler grundsätzlich vermieden. In der Regel ist es effizienter, die Threads einer VM im Hyperthreading durch die einer anderen VM unterbrechen zu lassen; oder auch durch Scheduling anstatt durch Hyperthreading, dazu gleich. Diese Vermeidungsstrategie lässt sich durch die Limitierung der "Threads pro Hardware-Kern" auf 1 auch erzwingen.
Andererseits lässt sich Hyper-V durch Aktivieren von Core-Scheduling auch zwingen, zwei VMs nicht gleichzeitig auf demselben physischen Kern auszuführen; seit 2019 ist das Standard. Dann ist die Aktivierung von SMT durch 0 oder 2 essenziell, um im Ergebnis noch Hyperthreading zu nutzen. Auch Core-Scheduling sorgt aber nicht für eine Begrenzung der eingesetzten physischen Kerne auf die fiktive, in der VM aus der Zahl der virtuellen Kerne abgeleitete Zahl, wie die Screenshots von wohl Hyper-V 2022 ja belegen. Es verhindert nur, dass der Hyper-V eine Konkurrenz von Threads unterschiedlicher VMs im Hyperthreading zuließe, fängt diese also durch Scheduling ab.
Gedulde dich noch ein bisschen, ich habe wie schon vorher erwähnt den Übeltäter gefunden. 😁
Wenn alles gut geht, dann poste ich heute Nachmittag ein bisschen mehr dazu.
Wenn alles gut geht, dann poste ich heute Nachmittag ein bisschen mehr dazu.
Da bin ich gespannt.
Moin @c.r.s.,
sei mir nicht böse, wenn ich nicht sofort auf alles eingehe, bin gerade echt Land unter. 😬😭
Aber gerne, wie ich schon mehrfach erwähnt habe, ist z.B. RSS eine der Anwendungsmöglichkeiten, die unbedingt auf dem "primären/physikalischen" Kern laufen muss.
Und RSS gibt es nicht nur auf Hardware, sondern auch in der VM und insbesondere bei 10G und darüber musst du es verwenden und dann sollte es technisch auch korrekt gemappt sein, damit du auch innerhalb der VM noch Freude mit deinen 10G vNIC haben kannst. 😉
Und genau das ist eben nicht egal, daher laufen, zum xten Mal, z.B. RSS und diverse andere Treiber oder Applikationen, auch nicht über die HT Kerne. Daher werden auch die logischen Kerne nicht querbeet über die physikalischen Kerne und deren HT-Kerne gemappt, sondern in einer vorgeschriebenen Reihenfolge.
Bitte erzähle nicht so einen Käse, nachdem ich hier schon zwei Mal den Befehl gepostet habe, mit dem du das was du da erzählen möchtest, selbst absurdum führen kannst.
Und zum xxxten Mal in einer VM gilt RSS technisch dasselbe wie bei einer Hardwarekiste, sprich dass dieses nur auf den physikalischen vCores läuft und nicht auf deren HT-vCores.
Fahre einfach mal eine VM ohne HT hoch und führe auf dieser Get-NetadapterRSS aus und merke was unter "RssProcessorArray" steht und dann starte dieselbe VM mit HT und führe denselben Befehl aus und dann siehst du sehr wohl, das das RSS in einer VM durchaus zwischen vCores und vHT-Cores unterscheiden kann.
Warte auf meine Auflösung des Problems dann siehst du, das das was du da sagst nicht ganz korrekt ist.
Behauptet bitte niemals wieder, dass zwei VM's auf einem und demselben Kern "gleichzeitig" ausgeführt werden, das ist Unsinn und war so auch noch nie der Fall, weder beim Hyper-V noch bei VMware oder einem anderen Hypervisor!
Schnell nacheinander ja, aber niemals gleichzeitig.
😁, so, jetzt kommen wir schon eher zueinander und ja, das ist richtig.
Ähm, die Screenshots stammen übrigens von einem Hyper-V 2022, der in diesem Augenblick mit einem "classic" Core-Scheduler gelaufen ist. 😉
Da bin ich gespannt.
Ich mach vielleicht sogar ein paar kurze Videos damit es etwas verständlicher wird.
Beste Grüsse aus BaWü
Alex
sei mir nicht böse, wenn ich nicht sofort auf alles eingehe, bin gerade echt Land unter. 😬😭
Es gibt aber keine Hierarchie zwischen dem "primären" und "sekundären" Hyperthreading-Kern, die es rechtfertigen würde, in den Taskmanager Spalten einzuzeichnen und zu erwarten, dass für vier saturierende Threads genau die logischen Kerne 0, 2, 4, 6, und nicht 1, 3, 5, 7, oder auch 0, 3, 5, 6 verwendet würden. Begründe das doch mal.
Aber gerne, wie ich schon mehrfach erwähnt habe, ist z.B. RSS eine der Anwendungsmöglichkeiten, die unbedingt auf dem "primären/physikalischen" Kern laufen muss.
Und RSS gibt es nicht nur auf Hardware, sondern auch in der VM und insbesondere bei 10G und darüber musst du es verwenden und dann sollte es technisch auch korrekt gemappt sein, damit du auch innerhalb der VM noch Freude mit deinen 10G vNIC haben kannst. 😉
Diese Information ist relevant; aber über welchen logischen Kern ein physischer Kern belastet wird, ist egal.
Und genau das ist eben nicht egal, daher laufen, zum xten Mal, z.B. RSS und diverse andere Treiber oder Applikationen, auch nicht über die HT Kerne. Daher werden auch die logischen Kerne nicht querbeet über die physikalischen Kerne und deren HT-Kerne gemappt, sondern in einer vorgeschriebenen Reihenfolge.
Wie du sehen kannst, wird für diese VM eine CPU Emuliert, die nur 4 "physikalische" Kerne hat, auf die sich 8 logische Kerne verteilen, sprich, ist selbe wie auch bei realer Hardware, 4 physikalische Kerne, plus 4 Fake-Kerne. 😉
Auch die VM unterscheidet nicht die tollen pysikalischen Kerne und niedere Fake-Kerne, sondern eben n logische Kerne mit der Info Hyperthreading ja/nein.
Wenn Hyperthreading "durchgereicht" wird, teilt die Ausgabe der WMI-Abfrage n durch zwei und zeigt das Ergebnis als physische Kerne an, weil sie für den Umstand der virtuellen Ausführung nicht angepasst ist.
Wenn Hyperthreading "durchgereicht" wird, teilt die Ausgabe der WMI-Abfrage n durch zwei und zeigt das Ergebnis als physische Kerne an, weil sie für den Umstand der virtuellen Ausführung nicht angepasst ist.
Bitte erzähle nicht so einen Käse, nachdem ich hier schon zwei Mal den Befehl gepostet habe, mit dem du das was du da erzählen möchtest, selbst absurdum führen kannst.
Und zum xxxten Mal in einer VM gilt RSS technisch dasselbe wie bei einer Hardwarekiste, sprich dass dieses nur auf den physikalischen vCores läuft und nicht auf deren HT-vCores.
Fahre einfach mal eine VM ohne HT hoch und führe auf dieser Get-NetadapterRSS aus und merke was unter "RssProcessorArray" steht und dann starte dieselbe VM mit HT und führe denselben Befehl aus und dann siehst du sehr wohl, das das RSS in einer VM durchaus zwischen vCores und vHT-Cores unterscheiden kann.
Da es hierbei keine "Emulation" von n/2 physischen Kernen gibt, gibt es für die VM mit n vCPUs auf Hyperthreading keinerlei Garantie durch den Hypervisor, dass ihre Hypervisor-Threads auf höchstens n/2 physischen Kernen ausgeführt werden. Im Gegenteil, ein solches restriktives Verhalten wäre nicht sinnvoll und wird vom Scheduler grundsätzlich vermieden. In der Regel ist es effizienter, die Threads einer VM im Hyperthreading durch die einer anderen VM unterbrechen zu lassen; oder auch durch Scheduling anstatt durch Hyperthreading, dazu gleich. Diese Vermeidungsstrategie lässt sich durch die Limitierung der "Threads pro Hardware-Kern" auf 1 auch erzwingen.
Warte auf meine Auflösung des Problems dann siehst du, das das was du da sagst nicht ganz korrekt ist.
Andererseits lässt sich Hyper-V durch Aktivieren von Core-Scheduling auch zwingen, zwei VMs nicht gleichzeitig auf demselben physischen Kern auszuführen;
Behauptet bitte niemals wieder, dass zwei VM's auf einem und demselben Kern "gleichzeitig" ausgeführt werden, das ist Unsinn und war so auch noch nie der Fall, weder beim Hyper-V noch bei VMware oder einem anderen Hypervisor!
Schnell nacheinander ja, aber niemals gleichzeitig.
seit 2019 ist das Standard. Dann ist die Aktivierung von SMT durch 0 oder 2 essenziell, um im Ergebnis noch Hyperthreading zu nutzen.
😁, so, jetzt kommen wir schon eher zueinander und ja, das ist richtig.
Auch Core-Scheduling sorgt aber nicht für eine Begrenzung der eingesetzten physischen Kerne auf die fiktive, in der VM aus der Zahl der virtuellen Kerne abgeleitete Zahl, wie die Screenshots von wohl Hyper-V 2022 ja belegen. Es verhindert nur, dass der Hyper-V eine Konkurrenz von Threads unterschiedlicher VMs im Hyperthreading zuließe, fängt diese also durch Scheduling ab.
Ähm, die Screenshots stammen übrigens von einem Hyper-V 2022, der in diesem Augenblick mit einem "classic" Core-Scheduler gelaufen ist. 😉
Gedulde dich noch ein bisschen, ich habe wie schon vorher erwähnt den Übeltäter gefunden. 😁
Wenn alles gut geht, dann poste ich heute Nachmittag ein bisschen mehr dazu.
Wenn alles gut geht, dann poste ich heute Nachmittag ein bisschen mehr dazu.
Da bin ich gespannt.
Ich mach vielleicht sogar ein paar kurze Videos damit es etwas verständlicher wird.
Beste Grüsse aus BaWü
Alex
Hallo Alex,
nunja du scheinst ja keine andere Meinung außer der Deinen zu glauben und in sofern ist es echt schwer mit Dir auf sachlicher Ebene zu diskutieren.
MIch dann als Zicke zu bezeichnen...Du das kann ich ab.
Aber zurück zum Thema:
Ich habe mir jetzt mal den Spaß gemacht und 2 Kollegen von mir (einer Softwareentwickler von Multithreading Applikationen und Verantwortlich für einen von uns vertriebenen Hypervisor für Automotive Multiprozessor und Multicoresysteme, der andere ist aus unsere IT und verantwortlich für unsere Virtualisierungsserver - wir haben vierstellig V;s bei uns unter HyperV laufen...der sollte also bisschen AHnung haben) gefragt.
Außerdem 2 externe die sich ebenfalls mit Multithreading und Hypervisor auskennen müssen, da sie hierfür ebenfalls verantwortlich sind.
Alle 4 haben ein übereinstimmendes Bild widergegeben, das ich Dir hier gerne weiztergebe.
Grundannahme:
- 1 physikalischer Prozessor mit 32 Cores und HT aktiv
- Hyper V
- jede VM hat 8 vCPUs (virtuelle CPUs)
- Du hast selbst gesagt, dass du 5-6 VMs auf der Node laufen hast
- EInstellung im Hypervisor HW Threads per Core = 1
- Windows Server >=2019 --> Core Schreduler
Klären wir erst mal Begriffe:
- vCPU --> virtuelle CPU innerhalb einer VM
- pCPU --> physikalische CPU auf Ebene des Hypervisors, aka "logischer Prozessor"
Klärung Hyperthreading:
Auf einem physikalischen Core können 2 Threads ausgeführt werden.
Diese beiden Threads teilen sich den cache (L1 und L2).
Diese beiden Thread laufen natürlicvh nicht gleichzeitig, aber können wir uns auf "parallel" einigen?
Sind wir uns bis hierher einig?
Was sieht der Hypervisor:
Der Hypervisor sieht wegen Hyperthreading jeden seiner echten Kerne doppelt, sieht also 64 logische Prozessoren. also 64 pCPUs.
Diese 64 pCPUs sind diese 32 Siliziumteile auf dem Die und auf jedem können eben 2 Threads laufen.
Nennen wir die der Einfachheit halber mal CPU0-31 und weil eben 2 Threads laufen geben wir jeweils ein a der b dazu.
Also CPU0_a, CPU0_b....usw.
Soweit immer noch okay?
Der Hypervisor sieht also 64 pCPUs, kennt aber die Paare, dass also die CPUx_a und CPUx_b irgendwie zusammengehören.
Nun sagst Du in deiner VM "ich brauche 8 vCPUs, richtig ?
Der Hypervisor hat aber den CoreScheduler und weiß:
Ich darf auf einem CPUx_a/b Pärchen keine Workloads von unterschiedlichen VMs laufen lassen.
Wenn er auf eine CPUx_a/b Kombination Workload von verschiedenen VMs laufen lassen möchte, muss er vorher die geteilten CacheSpeicher löschen, da sonst auf Speicherfragmente der andern VM zugegriffen werden könnte aber das nur am Rande.
Durch die Einstellung HW Threads per Core = 1 sagst Du aber dem Hypervisor:
"Kollege, jeder Core kann nur einen Thread einer VM ausführen"
Auf welchem Teil der CPUx, also auf a oder b die Worklload platziert wird, ist nicht definierbar.
Und das ist genau das was Du siehst:
Du lastest eine VM aus und dadurch werden 8 Deiner Kerne (aber eben immer nur a ODER b) mit Workload belastet.
Auf dem anderen DARF keine andere VM laufen und eben durch die o.g EInstellung nicht einmal Workload der selben VM.
Tut mir leid, wenn ich das so länglich dargestellt habe, aber das ist eben das, was bereits meine Meinung warf und mir jetzt von 4 Leuten unabhängig voneinander bestätigt wurde.
Sorry....
Und Overprovisioning:
Wenn du selbst sagst, du hast 5-6 VMs mit jeweils 8 vCPUs, dann komm ich da auf 40-48 angeforderte Kerne oder nicht?
Und eben weil durch den Core Scheduler VMs an den Kerngrenzen isoliert und du sagst "je Kern bitte nur ein Thread einer VM" ist das aus meiner Sicht überbelegt.
Soviel von mir
S.
nunja du scheinst ja keine andere Meinung außer der Deinen zu glauben und in sofern ist es echt schwer mit Dir auf sachlicher Ebene zu diskutieren.
MIch dann als Zicke zu bezeichnen...Du das kann ich ab.
Aber zurück zum Thema:
Ich habe mir jetzt mal den Spaß gemacht und 2 Kollegen von mir (einer Softwareentwickler von Multithreading Applikationen und Verantwortlich für einen von uns vertriebenen Hypervisor für Automotive Multiprozessor und Multicoresysteme, der andere ist aus unsere IT und verantwortlich für unsere Virtualisierungsserver - wir haben vierstellig V;s bei uns unter HyperV laufen...der sollte also bisschen AHnung haben) gefragt.
Außerdem 2 externe die sich ebenfalls mit Multithreading und Hypervisor auskennen müssen, da sie hierfür ebenfalls verantwortlich sind.
Alle 4 haben ein übereinstimmendes Bild widergegeben, das ich Dir hier gerne weiztergebe.
Grundannahme:
- 1 physikalischer Prozessor mit 32 Cores und HT aktiv
- Hyper V
- jede VM hat 8 vCPUs (virtuelle CPUs)
- Du hast selbst gesagt, dass du 5-6 VMs auf der Node laufen hast
- EInstellung im Hypervisor HW Threads per Core = 1
- Windows Server >=2019 --> Core Schreduler
Klären wir erst mal Begriffe:
- vCPU --> virtuelle CPU innerhalb einer VM
- pCPU --> physikalische CPU auf Ebene des Hypervisors, aka "logischer Prozessor"
Klärung Hyperthreading:
Auf einem physikalischen Core können 2 Threads ausgeführt werden.
Diese beiden Threads teilen sich den cache (L1 und L2).
Diese beiden Thread laufen natürlicvh nicht gleichzeitig, aber können wir uns auf "parallel" einigen?
Sind wir uns bis hierher einig?
Was sieht der Hypervisor:
Der Hypervisor sieht wegen Hyperthreading jeden seiner echten Kerne doppelt, sieht also 64 logische Prozessoren. also 64 pCPUs.
Diese 64 pCPUs sind diese 32 Siliziumteile auf dem Die und auf jedem können eben 2 Threads laufen.
Nennen wir die der Einfachheit halber mal CPU0-31 und weil eben 2 Threads laufen geben wir jeweils ein a der b dazu.
Also CPU0_a, CPU0_b....usw.
Soweit immer noch okay?
Der Hypervisor sieht also 64 pCPUs, kennt aber die Paare, dass also die CPUx_a und CPUx_b irgendwie zusammengehören.
Nun sagst Du in deiner VM "ich brauche 8 vCPUs, richtig ?
Der Hypervisor hat aber den CoreScheduler und weiß:
Ich darf auf einem CPUx_a/b Pärchen keine Workloads von unterschiedlichen VMs laufen lassen.
Wenn er auf eine CPUx_a/b Kombination Workload von verschiedenen VMs laufen lassen möchte, muss er vorher die geteilten CacheSpeicher löschen, da sonst auf Speicherfragmente der andern VM zugegriffen werden könnte aber das nur am Rande.
Durch die Einstellung HW Threads per Core = 1 sagst Du aber dem Hypervisor:
"Kollege, jeder Core kann nur einen Thread einer VM ausführen"
Auf welchem Teil der CPUx, also auf a oder b die Worklload platziert wird, ist nicht definierbar.
Und das ist genau das was Du siehst:
Du lastest eine VM aus und dadurch werden 8 Deiner Kerne (aber eben immer nur a ODER b) mit Workload belastet.
Auf dem anderen DARF keine andere VM laufen und eben durch die o.g EInstellung nicht einmal Workload der selben VM.
Tut mir leid, wenn ich das so länglich dargestellt habe, aber das ist eben das, was bereits meine Meinung warf und mir jetzt von 4 Leuten unabhängig voneinander bestätigt wurde.
Sorry....
Und Overprovisioning:
Wenn du selbst sagst, du hast 5-6 VMs mit jeweils 8 vCPUs, dann komm ich da auf 40-48 angeforderte Kerne oder nicht?
Und eben weil durch den Core Scheduler VMs an den Kerngrenzen isoliert und du sagst "je Kern bitte nur ein Thread einer VM" ist das aus meiner Sicht überbelegt.
Soviel von mir
S.
Moin Zusammen,
folgend wie besprochen der aktuelle Stand den ich gestern Nacht und heute Abend erarbeitet habe.
Der Schuldige für das wilde Core-Mapping scheint wie es nun aussieht aussieht der Classic Core Scheduler zu sein, der auf den entsprechenden Hyper-V 2022er Nodes gelaufen ist.
Sorry, hätte vielleicht in meiner Einleitung schon erwähnen sollen, dass die Hyper-V Nodes an dieser stelle vom Default etwas abweichen. 😬
Ich habe gestern Nacht nach Absprache mit dem Kunden testweise seinen HV-Test-Singel-Node von "Classic" wieder auf "Core" umgestellt, und schon sah die Sache wieder um einiges Besser aus.
Als ich danach bei einer der VM, bei der 8 vCPU ohne HT konfiguriert sind, deren vCores etwas gestresst habe, ist das folgende auf den Cores HV-Seitig geschehen ...
Wie ihr sehen könnt, wurde wie es auch sein sollte, die Last der 8 vCores (ohne HT) sauber auf die "physikalischen" Kerne des entsprechenden Hyper-V Nodes verteilt. 😁
Das einzige Negative was ich an der Stelle feststellen konnte war die Tatsache, das der Hypervisor grundlos die Last jede Sekunde, wild auf andere "physikalische" Kerne verschoben hat. 😔
Als nächstes habe ich dann einen Test mit einer VM gemacht, die ebenfalls 8vCores zugewiesen hat, jedoch mit aktiviertem HT, sprich 4 PH-vCores und 4 HT-vCores.
Und so sah dann das Ergebnis aus, als ich die vCores dieser VM vollständig zur Weissglut gebracht habe.
Wie man sehen kann, wird nun auch in diesem Fall die Last der VM, paarweise und somit absolut sauber verteilt. 😁
Dann habe ich als nächstes einen Test gemacht, bei dem ich nur den Core 0, 2, 4, 6 der VM, sprich deren PH-vCores belastet habe und so sah das Ergebnis davon aus.
Und auch hier hat es der Core Core-Scheduler geschafft, die Last der PH-vCores sauber auf die PH-Cores des HV-Hosts zu verteilen ... zumindest in > 95% der Fälle. (😁)
Hin und wieder konnte ich bei diesem Test jedoch beobachten, dass der Core Core-Scheduler die Last eines der PH-vCores der VM, kurzzeitig auf einen HT-Core des Nodes zugeordnet hat. Das sollte wiederum eigentlich nicht geschehen. 😬
Dann habe ich noch einen Test gemacht, bei dem ich nur die HT-vCores der VM auf Volllast gejagt habe.
Ja, mir ist schon klar, dass dieses Szenario eher unrealistisch ist ... egal, ich wollte es trotzdem mal kurz durchtesten. 🤪
Und hier hat der Core Core-Scheduler wieder etwas geschlampt und hat die Last der meisten HT-vCores der VM, auf die PH-Cores des HV-Nodes geschoben.
Da dieses Lastszenario in der Realität jedoch nur durch absolute Inkompetenz eines Entwicklers hervorgerufen werden kann, halte ich mein Meckern diesbezüglich nun auch etwas in Grenzen. 🙃
Zwischenstand:
Der Core Core-Scheduler scheint beim HV 2022 das Mapping der PH-vCores und HT-vCores zu den PH-Cores und HT-Cores des entsprechenden HV-Nodes, auf jeden Fall um Welten besser und sauberer hinzubekommen als der Classic Core-Scheduler.
Darüber bin ich ehrlich gesagt jetzt aber nicht wirklich begeistert, weil der Core Core-Scheduler im Vergleich zum Classic Core-Scheduler, selbst viel mehr Ressourcen verbraucht, sprich, einen höheren Overhead hat. 😔
Warum der Classic Core-Scheduler beim HV 2022 so rumspinnt, kann ich mir momentan absolut nicht erklären und bin mir zu 99% sicher, dass dieser auf dem HV 2016, wo dieser der Standard war, keinen solchen Murks veranstaltet hat.
Um genaueres herauszufinden werde ich demnächst unseren eigenen Test-HV mal wieder mit einem Server 2016 beglücken und danach auf diesem die Tests wiederholen.
Das kann aber locker ein paar Wochen dauern, da ich dafür aktuell schlichtweg keine Zeit habe.
Beste Grüsse aus BaWü
Alex
folgend wie besprochen der aktuelle Stand den ich gestern Nacht und heute Abend erarbeitet habe.
Der Schuldige für das wilde Core-Mapping scheint wie es nun aussieht aussieht der Classic Core Scheduler zu sein, der auf den entsprechenden Hyper-V 2022er Nodes gelaufen ist.
Sorry, hätte vielleicht in meiner Einleitung schon erwähnen sollen, dass die Hyper-V Nodes an dieser stelle vom Default etwas abweichen. 😬
Ich habe gestern Nacht nach Absprache mit dem Kunden testweise seinen HV-Test-Singel-Node von "Classic" wieder auf "Core" umgestellt, und schon sah die Sache wieder um einiges Besser aus.
Als ich danach bei einer der VM, bei der 8 vCPU ohne HT konfiguriert sind, deren vCores etwas gestresst habe, ist das folgende auf den Cores HV-Seitig geschehen ...
Wie ihr sehen könnt, wurde wie es auch sein sollte, die Last der 8 vCores (ohne HT) sauber auf die "physikalischen" Kerne des entsprechenden Hyper-V Nodes verteilt. 😁
Das einzige Negative was ich an der Stelle feststellen konnte war die Tatsache, das der Hypervisor grundlos die Last jede Sekunde, wild auf andere "physikalische" Kerne verschoben hat. 😔
Als nächstes habe ich dann einen Test mit einer VM gemacht, die ebenfalls 8vCores zugewiesen hat, jedoch mit aktiviertem HT, sprich 4 PH-vCores und 4 HT-vCores.
Und so sah dann das Ergebnis aus, als ich die vCores dieser VM vollständig zur Weissglut gebracht habe.
Wie man sehen kann, wird nun auch in diesem Fall die Last der VM, paarweise und somit absolut sauber verteilt. 😁
Dann habe ich als nächstes einen Test gemacht, bei dem ich nur den Core 0, 2, 4, 6 der VM, sprich deren PH-vCores belastet habe und so sah das Ergebnis davon aus.
Und auch hier hat es der Core Core-Scheduler geschafft, die Last der PH-vCores sauber auf die PH-Cores des HV-Hosts zu verteilen ... zumindest in > 95% der Fälle. (😁)
Hin und wieder konnte ich bei diesem Test jedoch beobachten, dass der Core Core-Scheduler die Last eines der PH-vCores der VM, kurzzeitig auf einen HT-Core des Nodes zugeordnet hat. Das sollte wiederum eigentlich nicht geschehen. 😬
Dann habe ich noch einen Test gemacht, bei dem ich nur die HT-vCores der VM auf Volllast gejagt habe.
Ja, mir ist schon klar, dass dieses Szenario eher unrealistisch ist ... egal, ich wollte es trotzdem mal kurz durchtesten. 🤪
Und hier hat der Core Core-Scheduler wieder etwas geschlampt und hat die Last der meisten HT-vCores der VM, auf die PH-Cores des HV-Nodes geschoben.
Da dieses Lastszenario in der Realität jedoch nur durch absolute Inkompetenz eines Entwicklers hervorgerufen werden kann, halte ich mein Meckern diesbezüglich nun auch etwas in Grenzen. 🙃
Zwischenstand:
Der Core Core-Scheduler scheint beim HV 2022 das Mapping der PH-vCores und HT-vCores zu den PH-Cores und HT-Cores des entsprechenden HV-Nodes, auf jeden Fall um Welten besser und sauberer hinzubekommen als der Classic Core-Scheduler.
Darüber bin ich ehrlich gesagt jetzt aber nicht wirklich begeistert, weil der Core Core-Scheduler im Vergleich zum Classic Core-Scheduler, selbst viel mehr Ressourcen verbraucht, sprich, einen höheren Overhead hat. 😔
Warum der Classic Core-Scheduler beim HV 2022 so rumspinnt, kann ich mir momentan absolut nicht erklären und bin mir zu 99% sicher, dass dieser auf dem HV 2016, wo dieser der Standard war, keinen solchen Murks veranstaltet hat.
Um genaueres herauszufinden werde ich demnächst unseren eigenen Test-HV mal wieder mit einem Server 2016 beglücken und danach auf diesem die Tests wiederholen.
Das kann aber locker ein paar Wochen dauern, da ich dafür aktuell schlichtweg keine Zeit habe.
Beste Grüsse aus BaWü
Alex
Zitat von @MysticFoxDE:
Aber gerne, wie ich schon mehrfach erwähnt habe, ist z.B. RSS eine der Anwendungsmöglichkeiten, die unbedingt auf dem "primären/physikalischen" Kern laufen muss.
Aber gerne, wie ich schon mehrfach erwähnt habe, ist z.B. RSS eine der Anwendungsmöglichkeiten, die unbedingt auf dem "primären/physikalischen" Kern laufen muss.
Nein, sie sollte nur mit einem Thread pro Kern ausgeführt werden. Ob das erreicht wird, indem man logische Kerne von 0 an gerade oder von 1 an ungerade hochzählt, ist technisch egal - in Bezug auf die CPU-Architektur. Eine Software-Implementierung wird sich für eines davon entscheiden.
Fahre einfach mal eine VM ohne HT hoch und führe auf dieser Get-NetadapterRSS aus und merke was unter "RssProcessorArray" steht und dann starte dieselbe VM mit HT und führe denselben Befehl aus und dann siehst du sehr wohl, das das RSS in einer VM durchaus zwischen vCores und vHT-Cores unterscheiden kann.
Das sieht man da wirklich nur, wenn man es sehen will.
Behauptet bitte niemals wieder, dass zwei VM's auf einem und demselben Kern "gleichzeitig" ausgeführt werden, das ist Unsinn und war so auch noch nie der Fall, weder beim Hyper-V noch bei VMware oder einem anderen Hypervisor!
Tut mir Leid, das ist der Stand der CPU-Entwicklung. Wofür wohl das S in SMT steht?
Schnell nacheinander ja, aber niemals gleichzeitig.
Doch, gleichzeitig, bezogen auf den Kern. Ich habe Verständnis, dass man das mal in Forendiskussionen so sagt: Ein physischer Kern, ein Thread zu einer Zeit. So kann man sich das vereinfacht vorstellen bzw. seine Erwartungen an etwas wie Hyperthreading moderieren.
Es stimmt aber nicht, da ein Kern nicht monolithisch ist, sondern aus Execution Units besteht. Der Zweck von SMT ist, gleichzeitig, d.h. innerhalb desselben Clock-Cycles, Instruktionen zweier Threads auf demselben physischen Kern auszuführen. Daraus ergibt sich ein Effizienzgewinn, weil die in einem Zyklus verfügbaren Instruktionen eines einzelnen Threads die Execution Units eines Kerns typischerweise nicht auslasten. Angenommen werden die Instruktionen der Threads nur sequenziell, das ist ein Funken Wahrheit in der vereinfachten Vorstellung.
Ähm, die Screenshots stammen übrigens von einem Hyper-V 2022, der in diesem Augenblick mit einem "classic" Core-Scheduler gelaufen ist. 😉
Gut, dann sind sie natürlich kein Beleg meiner Aussage. Ändert aber den Sachverhalt nicht.
Moin @SvenTej,
doch, aber das muss man sich bei einem alten IT-Fuchs auch erstmal anständig "verdienen".
Du bist aber, vor allem durch den letzten Post auf einem guten Weg dahin. 😉
(Mein Profilbild ist schon etwas älter, sprich die Harre sind mittlerweile viel grauer. 🙃)
😁, mach dir kein Kopf muss sich mein Hausdrachen auch sehr oft anhören.
Der reagiert darauf jedoch meist nicht ganz so defensiv wie du jetzt. 👍👍👍
😲, das ist ja ein ganzer Zoo an IT-Experten den ihr da habt und dann alle gegen einen IT-Fuchs ... 🤔 ist zwar etwas unfair verteilt ... aber kein Problem, Herausforderung angenommen. 😉
mit 32 physikalischen Kernen oder 32 logischen Kernen?
Der letzte Node mit dem ich getestet habe, hatte übrigens 2 CPU's mit a 18 physikalischen Kernen, plus HT.
Sprich, in Summe 72 logische Kerne.
Testweise ja, ansonsten ist 0 Eingestellt.
Die Nodes des entsprechenden Kunden bei dem ich die letzten Tage das Ganze durchexerziert habe, laufen alle auf HV 2022 mit dem Classic Core-Scheduler.
Klären wir erst mal Begriffe:
- vCPU --> virtuelle CPU innerhalb einer VM
- pCPU --> physikalische CPU auf Ebene des Hypervisors, aka "logischer Prozessor"
ich wäre eher für.
Core --> Logischer Kern einer CPU eines HV-Hosts
PH-Core --> Physikalischer Kern einer CPU eines HV-Hosts Falls HT auf dieser aktiv ist. (0.0, 0.2, 0.4 ...)
HT-Core --> Fake Kern einer CPU eines HV-Hosts Falls HT auf dieser aktiv ist. (0.1, 0.3, 0.5 ...)
vCore --> Logischer Kern einer VM (mit aktivierten HT auf VM & Host)
PH-vCore --> Physikalischer Kern einer VM (mit aktivierten HT auf VM & Host) (0.0, 0.2, 0.4 ...)
HT-vCore --> Fake Kern einer VM (mit aktivierten HT auf VM & Host) (0.1, 0.3, 0.5 ...)
Wenn auf dem HV-Host kein HT aktiviert ist, dann kann auf der VM auch kein HT bereitgestellt werden.
Klärung Hyperthreading:
Auf einem physikalischen Core können 2 Threads ausgeführt werden.
Diese beiden Threads teilen sich den cache (L1 und L2).
Diese beiden Thread laufen natürlicvh nicht gleichzeitig, aber können wir uns auf "parallel" einigen?
Sind wir uns bis hierher einig?
Ja, die beiden teilen sich den Cache, was so gesehen eigentlich ein Vorteil von HT ist, zumindest dann
wenn der Entwickler der entsprechenden Software, diesen auch richtig auslegt.
Jedoch Teilen sich diese Threads nicht nur den Cache sondern auch die Recheneinheit des entsprechenden physikalischen Kerns und auf diese hat entweder nur der eine oder andere Thread gleichzeitig einen Zugriff aber niemals beide zusammen. Daher tue ich mich echt schwer, hierbei dem "parallel" zuzustimmen, weil die Abarbeitung der Threads durch die Recheneinheit tatsächlich eher sequentiell, sprich nacheinander erfolgt.
Das ist mir zu einfach ausgedrückt und suggeriert dadurch zu sehr eine doppelte Rechenleistung.
Meine Sicht ist die Folgende.
Der Hypervisor sieht durchaus, dass dieser nur 32 physikalische Kerne hat und wenn ein HT aktiv ist, dann gibt er diese in form von 32 logischen Kernen an die Treiber/Anwendungen und Co., weiter.
Wenn in dem Fall HT aktiviert wird, dann erkennt der Hypervisor weiterhin 32 physikalische Kerne, durch das aktive HT weiss der Hypervisor jedoch auch, das jeder dieser Kerne eine zweite "Threadwarteschlange/Fake Kern" aktiv hat und gaukelt deshalb den Applikationen anstelle von 32 logischen Kernen auch 64 Logische Kerne vor.
Wir brauchen uns da nichts auszudenken, diese "Matrix" ist bereits "normiert".
NUMA 0 PH-Core 0 --> 0.0
NUMA 0 HT-Core 1 --> 0.1
(Bedes obere Zusammen bildet siliziumtechnisch den ersten physikalischen Kern der ersten CPU mit aktivem HT ab)
NUMA 0 PH-Core 2 --> 0.2
NUMA 0 HT-Core 3 --> 0.3
(Bedes obere Zusammen bildet siliziumtechnisch den zweiten physikalischen Kern der ersten CPU mit aktivem HT ab)
NUMA 0 PH-Core 4 --> 0.4
NUMA 0 HT-Core 5 --> 0.5
(Bedes obere Zusammen bildet siliziumtechnisch den dritten physikalischen Kern der ersten CPU mit aktivem HT ab)
u.s.w.
NUMA 1 PH-Core 0 --> 1.0
NUMA 1 HT-Core 1 --> 1.1
(Bedes obere Zusammen bildet siliziumtechnisch den ersten physikalischen Kern der zweiten CPU mit aktivem HT ab)
NUMA 1 PH-Core 2 --> 1.2
NUMA 1 HT-Core 3 --> 1.3
(Bedes obere Zusammen bildet siliziumtechnisch den zweiten physikalischen Kern der zweiten CPU mit aktivem HT ab)
NUMA 1 PH-Core 4 --> 1.4
NUMA 1 HT-Core 5 --> 1.5
(Bedes obere Zusammen bildet siliziumtechnisch den dritten physikalischen Kern der zweiten CPU mit aktivem HT ab)
u.s.w.
Ja, wie oben beschrieben.
Ja und ich gebe noch mit, dass diese ohne HT sein sollen, weil z.B. die Software auf den RDS (VM) läuft, nicht wirklich gut mit HT zurechtkommt.
Ahm, ja auf 0.0 und 0.1 oder 0.2 und 0.3 sollte der Core-Scheduler weder aus der Sicht der Performance noch aus der Sicht der Sicherheitssicht, Threads von zwei VM's reinkippen, weil er bei jedem Threadwechsel zwischen 0.0 und 0.1 den gemeinsamen Cache löschen und danach mit neuen Daten neu laden muss, und das wiederum ist pures Performancegift.
Ja, aber das mach meines bisherigen Wissens nach nur der Core Core-Scheduler und nicht der Classic.
Daher, und wegen dem häufigeren Threadherumgeschiebe hat dieser ja auch einen grösseren Betriebsoverhead. 😉
Ja, das ist korrekt.
Definierbar nicht, weil das der Core-Scheduler automatisch richtig regeln muss und zwwar nur auf 0.0, 0.2, 0.4 u.s.w. ...
Siehe auch meinen letzten Post, wo der Core Core-Scheduler, genau das auch so macht.
Ich kennen übrigens einen Trick, mit dem man das Mapping durchaus auch Fix erzwingen kann. 😉
Und genau das sollte nicht sein und geschieht auch nur mit dem Classic Core-Scheduler, aber nicht mit dem Core-Core-Scheduler. (Siehe letzten Post)
Mach dir um mein Fell keine Sorgen, das hat schon ganz andere Dinge überstanden.
Ja, logische 40-48 vCores und der HV hat 72 Cores (logische Kerne), daher auch keine Überbuchung.
Du siehst das mit der Isolierung glaube ich viel zu eng.
Die Isolierung bedeutet nur, dass der HV bei einem Threadwechsel auf demselben Core von z.B. einem Thread von VM-A zu einem Thread von z.B. VM-B dafür sorgen muss, dass die Daten die im Cache vom Thread-A eventuell noch rumliegen, sauber gelöscht sind, bevor der entsprechende Kern mit dem abarbeiten des Threads-B der VM beginnt.
An dieser Stelle möchte ich der Vollständigkeit halber jedoch auch gerne erwähnen, dass ein derartiger "Seitenkanalattacke" mit dem die Daten aus dem Cache herausgepikst wurden, meines bisherigen Wissens nach in der freien Wildbahn noch nie gesehen wurde, weil diese Schwachstelle zwar theoretisch existiert, deren Ausnutzung praktisch jedoch viel zu aufwendig ist. 😉
Beste Grüsse aus BaWü
Alex
nunja du scheinst ja keine andere Meinung außer der Deinen zu glauben und in sofern ist es echt schwer mit Dir auf sachlicher Ebene zu diskutieren.
doch, aber das muss man sich bei einem alten IT-Fuchs auch erstmal anständig "verdienen".
Du bist aber, vor allem durch den letzten Post auf einem guten Weg dahin. 😉
(Mein Profilbild ist schon etwas älter, sprich die Harre sind mittlerweile viel grauer. 🙃)
MIch dann als Zicke zu bezeichnen...Du das kann ich ab.
😁, mach dir kein Kopf muss sich mein Hausdrachen auch sehr oft anhören.
Der reagiert darauf jedoch meist nicht ganz so defensiv wie du jetzt. 👍👍👍
Aber zurück zum Thema:
Ich habe mir jetzt mal den Spaß gemacht und 2 Kollegen von mir (einer Softwareentwickler von Multithreading Applikationen und Verantwortlich für einen von uns vertriebenen Hypervisor für Automotive Multiprozessor und Multicoresysteme, der andere ist aus unsere IT und verantwortlich für unsere Virtualisierungsserver - wir haben vierstellig V;s bei uns unter HyperV laufen...der sollte also bisschen AHnung haben) gefragt.
Außerdem 2 externe die sich ebenfalls mit Multithreading und Hypervisor auskennen müssen, da sie hierfür ebenfalls verantwortlich sind.
Ich habe mir jetzt mal den Spaß gemacht und 2 Kollegen von mir (einer Softwareentwickler von Multithreading Applikationen und Verantwortlich für einen von uns vertriebenen Hypervisor für Automotive Multiprozessor und Multicoresysteme, der andere ist aus unsere IT und verantwortlich für unsere Virtualisierungsserver - wir haben vierstellig V;s bei uns unter HyperV laufen...der sollte also bisschen AHnung haben) gefragt.
Außerdem 2 externe die sich ebenfalls mit Multithreading und Hypervisor auskennen müssen, da sie hierfür ebenfalls verantwortlich sind.
😲, das ist ja ein ganzer Zoo an IT-Experten den ihr da habt und dann alle gegen einen IT-Fuchs ... 🤔 ist zwar etwas unfair verteilt ... aber kein Problem, Herausforderung angenommen. 😉
Alle 4 haben ein übereinstimmendes Bild widergegeben, das ich Dir hier gerne weiztergebe.
Grundannahme:
- 1 physikalischer Prozessor mit 32 Cores und HT aktiv
Grundannahme:
- 1 physikalischer Prozessor mit 32 Cores und HT aktiv
mit 32 physikalischen Kernen oder 32 logischen Kernen?
Der letzte Node mit dem ich getestet habe, hatte übrigens 2 CPU's mit a 18 physikalischen Kernen, plus HT.
Sprich, in Summe 72 logische Kerne.
- Hyper V
- jede VM hat 8 vCPUs (virtuelle CPUs)
- Du hast selbst gesagt, dass du 5-6 VMs auf der Node laufen hast
- EInstellung im Hypervisor HW Threads per Core = 1
- jede VM hat 8 vCPUs (virtuelle CPUs)
- Du hast selbst gesagt, dass du 5-6 VMs auf der Node laufen hast
- EInstellung im Hypervisor HW Threads per Core = 1
Testweise ja, ansonsten ist 0 Eingestellt.
- Windows Server >=2019 --> Core Schreduler
Die Nodes des entsprechenden Kunden bei dem ich die letzten Tage das Ganze durchexerziert habe, laufen alle auf HV 2022 mit dem Classic Core-Scheduler.
Klären wir erst mal Begriffe:
- vCPU --> virtuelle CPU innerhalb einer VM
- pCPU --> physikalische CPU auf Ebene des Hypervisors, aka "logischer Prozessor"
ich wäre eher für.
Core --> Logischer Kern einer CPU eines HV-Hosts
PH-Core --> Physikalischer Kern einer CPU eines HV-Hosts Falls HT auf dieser aktiv ist. (0.0, 0.2, 0.4 ...)
HT-Core --> Fake Kern einer CPU eines HV-Hosts Falls HT auf dieser aktiv ist. (0.1, 0.3, 0.5 ...)
vCore --> Logischer Kern einer VM (mit aktivierten HT auf VM & Host)
PH-vCore --> Physikalischer Kern einer VM (mit aktivierten HT auf VM & Host) (0.0, 0.2, 0.4 ...)
HT-vCore --> Fake Kern einer VM (mit aktivierten HT auf VM & Host) (0.1, 0.3, 0.5 ...)
Wenn auf dem HV-Host kein HT aktiviert ist, dann kann auf der VM auch kein HT bereitgestellt werden.
Klärung Hyperthreading:
Auf einem physikalischen Core können 2 Threads ausgeführt werden.
Diese beiden Threads teilen sich den cache (L1 und L2).
Diese beiden Thread laufen natürlicvh nicht gleichzeitig, aber können wir uns auf "parallel" einigen?
Sind wir uns bis hierher einig?
Ja, die beiden teilen sich den Cache, was so gesehen eigentlich ein Vorteil von HT ist, zumindest dann
wenn der Entwickler der entsprechenden Software, diesen auch richtig auslegt.
Jedoch Teilen sich diese Threads nicht nur den Cache sondern auch die Recheneinheit des entsprechenden physikalischen Kerns und auf diese hat entweder nur der eine oder andere Thread gleichzeitig einen Zugriff aber niemals beide zusammen. Daher tue ich mich echt schwer, hierbei dem "parallel" zuzustimmen, weil die Abarbeitung der Threads durch die Recheneinheit tatsächlich eher sequentiell, sprich nacheinander erfolgt.
Was sieht der Hypervisor:
Der Hypervisor sieht wegen Hyperthreading jeden seiner echten Kerne doppelt, sieht also 64 logische Prozessoren. also 64 pCPUs.
Der Hypervisor sieht wegen Hyperthreading jeden seiner echten Kerne doppelt, sieht also 64 logische Prozessoren. also 64 pCPUs.
Das ist mir zu einfach ausgedrückt und suggeriert dadurch zu sehr eine doppelte Rechenleistung.
Meine Sicht ist die Folgende.
Der Hypervisor sieht durchaus, dass dieser nur 32 physikalische Kerne hat und wenn ein HT aktiv ist, dann gibt er diese in form von 32 logischen Kernen an die Treiber/Anwendungen und Co., weiter.
Wenn in dem Fall HT aktiviert wird, dann erkennt der Hypervisor weiterhin 32 physikalische Kerne, durch das aktive HT weiss der Hypervisor jedoch auch, das jeder dieser Kerne eine zweite "Threadwarteschlange/Fake Kern" aktiv hat und gaukelt deshalb den Applikationen anstelle von 32 logischen Kernen auch 64 Logische Kerne vor.
Diese 64 pCPUs sind diese 32 Siliziumteile auf dem Die und auf jedem können eben 2 Threads laufen.
Nennen wir die der Einfachheit halber mal CPU0-31 und weil eben 2 Threads laufen geben wir jeweils ein a der b dazu.
Also CPU0_a, CPU0_b....usw.
Soweit immer noch okay?
Nennen wir die der Einfachheit halber mal CPU0-31 und weil eben 2 Threads laufen geben wir jeweils ein a der b dazu.
Also CPU0_a, CPU0_b....usw.
Soweit immer noch okay?
Wir brauchen uns da nichts auszudenken, diese "Matrix" ist bereits "normiert".
NUMA 0 PH-Core 0 --> 0.0
NUMA 0 HT-Core 1 --> 0.1
(Bedes obere Zusammen bildet siliziumtechnisch den ersten physikalischen Kern der ersten CPU mit aktivem HT ab)
NUMA 0 PH-Core 2 --> 0.2
NUMA 0 HT-Core 3 --> 0.3
(Bedes obere Zusammen bildet siliziumtechnisch den zweiten physikalischen Kern der ersten CPU mit aktivem HT ab)
NUMA 0 PH-Core 4 --> 0.4
NUMA 0 HT-Core 5 --> 0.5
(Bedes obere Zusammen bildet siliziumtechnisch den dritten physikalischen Kern der ersten CPU mit aktivem HT ab)
u.s.w.
NUMA 1 PH-Core 0 --> 1.0
NUMA 1 HT-Core 1 --> 1.1
(Bedes obere Zusammen bildet siliziumtechnisch den ersten physikalischen Kern der zweiten CPU mit aktivem HT ab)
NUMA 1 PH-Core 2 --> 1.2
NUMA 1 HT-Core 3 --> 1.3
(Bedes obere Zusammen bildet siliziumtechnisch den zweiten physikalischen Kern der zweiten CPU mit aktivem HT ab)
NUMA 1 PH-Core 4 --> 1.4
NUMA 1 HT-Core 5 --> 1.5
(Bedes obere Zusammen bildet siliziumtechnisch den dritten physikalischen Kern der zweiten CPU mit aktivem HT ab)
u.s.w.
Der Hypervisor sieht also 64 pCPUs, kennt aber die Paare, dass also die CPUx_a und CPUx_b irgendwie zusammengehören.
Ja, wie oben beschrieben.
Nun sagst Du in deiner VM "ich brauche 8 vCPUs, richtig ?
Ja und ich gebe noch mit, dass diese ohne HT sein sollen, weil z.B. die Software auf den RDS (VM) läuft, nicht wirklich gut mit HT zurechtkommt.
Der Hypervisor hat aber den CoreScheduler und weiß:
Ich darf auf einem CPUx_a/b Pärchen keine Workloads von unterschiedlichen VMs laufen lassen.
Ich darf auf einem CPUx_a/b Pärchen keine Workloads von unterschiedlichen VMs laufen lassen.
Ahm, ja auf 0.0 und 0.1 oder 0.2 und 0.3 sollte der Core-Scheduler weder aus der Sicht der Performance noch aus der Sicht der Sicherheitssicht, Threads von zwei VM's reinkippen, weil er bei jedem Threadwechsel zwischen 0.0 und 0.1 den gemeinsamen Cache löschen und danach mit neuen Daten neu laden muss, und das wiederum ist pures Performancegift.
Wenn er auf eine CPUx_a/b Kombination Workload von verschiedenen VMs laufen lassen möchte, muss er vorher die geteilten CacheSpeicher löschen, da sonst auf Speicherfragmente der andern VM zugegriffen werden könnte aber das nur am Rande.
Ja, aber das mach meines bisherigen Wissens nach nur der Core Core-Scheduler und nicht der Classic.
Daher, und wegen dem häufigeren Threadherumgeschiebe hat dieser ja auch einen grösseren Betriebsoverhead. 😉
Durch die Einstellung HW Threads per Core = 1 sagst Du aber dem Hypervisor:
"Kollege, jeder Core kann nur einen Thread einer VM ausführen"
"Kollege, jeder Core kann nur einen Thread einer VM ausführen"
Ja, das ist korrekt.
Auf welchem Teil der CPUx, also auf a oder b die Worklload platziert wird, ist nicht definierbar.
Definierbar nicht, weil das der Core-Scheduler automatisch richtig regeln muss und zwwar nur auf 0.0, 0.2, 0.4 u.s.w. ...
Siehe auch meinen letzten Post, wo der Core Core-Scheduler, genau das auch so macht.
Ich kennen übrigens einen Trick, mit dem man das Mapping durchaus auch Fix erzwingen kann. 😉
Und das ist genau das was Du siehst:
Du lastest eine VM aus und dadurch werden 8 Deiner Kerne (aber eben immer nur a ODER b) mit Workload belastet.
Du lastest eine VM aus und dadurch werden 8 Deiner Kerne (aber eben immer nur a ODER b) mit Workload belastet.
Und genau das sollte nicht sein und geschieht auch nur mit dem Classic Core-Scheduler, aber nicht mit dem Core-Core-Scheduler. (Siehe letzten Post)
Tut mir leid, wenn ich das so länglich dargestellt habe, aber das ist eben das, was bereits meine Meinung warf und mir jetzt von 4 Leuten unabhängig voneinander bestätigt wurde.
Sorry....
Sorry....
Mach dir um mein Fell keine Sorgen, das hat schon ganz andere Dinge überstanden.
Und Overprovisioning:
Wenn du selbst sagst, du hast 5-6 VMs mit jeweils 8 vCPUs, dann komm ich da auf 40-48 angeforderte Kerne oder nicht?
Wenn du selbst sagst, du hast 5-6 VMs mit jeweils 8 vCPUs, dann komm ich da auf 40-48 angeforderte Kerne oder nicht?
Ja, logische 40-48 vCores und der HV hat 72 Cores (logische Kerne), daher auch keine Überbuchung.
Und eben weil durch den Core Scheduler VMs an den Kerngrenzen isoliert und du sagst "je Kern bitte nur ein Thread einer VM" ist das aus meiner Sicht überbelegt.
Du siehst das mit der Isolierung glaube ich viel zu eng.
Die Isolierung bedeutet nur, dass der HV bei einem Threadwechsel auf demselben Core von z.B. einem Thread von VM-A zu einem Thread von z.B. VM-B dafür sorgen muss, dass die Daten die im Cache vom Thread-A eventuell noch rumliegen, sauber gelöscht sind, bevor der entsprechende Kern mit dem abarbeiten des Threads-B der VM beginnt.
An dieser Stelle möchte ich der Vollständigkeit halber jedoch auch gerne erwähnen, dass ein derartiger "Seitenkanalattacke" mit dem die Daten aus dem Cache herausgepikst wurden, meines bisherigen Wissens nach in der freien Wildbahn noch nie gesehen wurde, weil diese Schwachstelle zwar theoretisch existiert, deren Ausnutzung praktisch jedoch viel zu aufwendig ist. 😉
Beste Grüsse aus BaWü
Alex
Moin @c.r.s.,
Nein, sie sollte nur mit einem Thread pro Kern ausgeführt werden.
Ich sage aber weiterhin doch, weil dadurch sichergestellt wird, dass die RSS-Queues jeweils immer auf einem anderen Core oder vCore laufen und zwar am liebsten auf dem PH-Core, respektive PH-vCore, während dessen Nachbar/Genosse der HT-Core/HT-vCore am besten nichts anderes macht, sprich dem RSS nicht dazwischen pfuscht. 😉
Nein, auch eine Softwareimplementierung von RSS verwendet bei aktiviertem HT immer (0.0, 0.2, 0.4, u.s.w.)
Das sieht man da wirklich nur, wenn man es sehen will.
Aha ... na dann lasse ich das jetzt auch einfach mal so stehen, vielleicht denkst selber über deinen Satz mal nochmals nach. 😉
Tut mir Leid, das ist der Stand der CPU-Entwicklung. Wofür wohl das S in SMT steht?
Nein, das ist nur der Stand des Marketings dem du auf den Leim gegangen bist und nicht der Stand der Technik.
Doch, gleichzeitig, bezogen auf den Kern. Ich habe Verständnis, dass man das mal in Forendiskussionen so sagt: Ein physischer Kern, ein Thread zu einer Zeit. So kann man sich das vereinfacht vorstellen bzw. seine Erwartungen an etwas wie Hyperthreading moderieren.
"Ein physischer Kern, ein Thread zu einer Zeit" ja, aber "Ein physischer Kern, zwei Threads zu einer Zeit" definitiv NEIN auch nicht mit HT/SMT, da ein physikalischer Kern schlichtweg nur eine Recheneinheit hat, welches entweder den einen oder den anderen Thread abarbeiten kann, aber niemals beide gleichzeitig!
Und welche Execution Units hat ein CPU Kern den bitte doppelt verbaut?
Kannst du bitte eine externe Quelle zu dieser Aussage liefern, danke.
🙃 ... auch über diesen Satz solltest du selbst mal in Ruhe nochmals nachdenken.
Beste Grüsse aus BaWü
Alex
Aber gerne, wie ich schon mehrfach erwähnt habe, ist z.B. RSS eine der Anwendungsmöglichkeiten, die unbedingt auf dem "primären/physikalischen" Kern laufen muss.
Nein, sie sollte nur mit einem Thread pro Kern ausgeführt werden.
Ich sage aber weiterhin doch, weil dadurch sichergestellt wird, dass die RSS-Queues jeweils immer auf einem anderen Core oder vCore laufen und zwar am liebsten auf dem PH-Core, respektive PH-vCore, während dessen Nachbar/Genosse der HT-Core/HT-vCore am besten nichts anderes macht, sprich dem RSS nicht dazwischen pfuscht. 😉
Eine Software-Implementierung wird sich für eines davon entscheiden.
Nein, auch eine Softwareimplementierung von RSS verwendet bei aktiviertem HT immer (0.0, 0.2, 0.4, u.s.w.)
Fahre einfach mal eine VM ohne HT hoch und führe auf dieser Get-NetadapterRSS aus und merke was unter "RssProcessorArray" steht und dann starte dieselbe VM mit HT und führe denselben Befehl aus und dann siehst du sehr wohl, das das RSS in einer VM durchaus zwischen vCores und vHT-Cores unterscheiden kann.
Das sieht man da wirklich nur, wenn man es sehen will.
Aha ... na dann lasse ich das jetzt auch einfach mal so stehen, vielleicht denkst selber über deinen Satz mal nochmals nach. 😉
Behauptet bitte niemals wieder, dass zwei VM's auf einem und demselben Kern "gleichzeitig" ausgeführt werden, das ist Unsinn und war so auch noch nie der Fall, weder beim Hyper-V noch bei VMware oder einem anderen Hypervisor!
Tut mir Leid, das ist der Stand der CPU-Entwicklung. Wofür wohl das S in SMT steht?
Nein, das ist nur der Stand des Marketings dem du auf den Leim gegangen bist und nicht der Stand der Technik.
Schnell nacheinander ja, aber niemals gleichzeitig.
Doch, gleichzeitig, bezogen auf den Kern. Ich habe Verständnis, dass man das mal in Forendiskussionen so sagt: Ein physischer Kern, ein Thread zu einer Zeit. So kann man sich das vereinfacht vorstellen bzw. seine Erwartungen an etwas wie Hyperthreading moderieren.
"Ein physischer Kern, ein Thread zu einer Zeit" ja, aber "Ein physischer Kern, zwei Threads zu einer Zeit" definitiv NEIN auch nicht mit HT/SMT, da ein physikalischer Kern schlichtweg nur eine Recheneinheit hat, welches entweder den einen oder den anderen Thread abarbeiten kann, aber niemals beide gleichzeitig!
Es stimmt aber nicht, da ein Kern nicht monolithisch ist, sondern aus Execution Units besteht.
Und welche Execution Units hat ein CPU Kern den bitte doppelt verbaut?
Der Zweck von SMT ist, gleichzeitig, d.h. innerhalb desselben Clock-Cycles, Instruktionen zweier Threads auf demselben physischen Kern auszuführen.
Daraus ergibt sich ein Effizienzgewinn, weil die in einem Zyklus verfügbaren Instruktionen eines einzelnen Threads die Execution Units eines Kerns typischerweise nicht auslasten. Angenommen werden die Instruktionen der Threads nur sequenziell, das ist ein Funken Wahrheit in der vereinfachten Vorstellung.
Kannst du bitte eine externe Quelle zu dieser Aussage liefern, danke.
Gut, dann sind sie natürlich kein Beleg meiner Aussage. Ändert aber den Sachverhalt nicht.
🙃 ... auch über diesen Satz solltest du selbst mal in Ruhe nochmals nachdenken.
Beste Grüsse aus BaWü
Alex
Oh Mann, das ist überraschend zwecklos.
Das Thema wirkte auf den ersten Blick interessant, gerade auch wegen der Sicherheitsrelevanz z.B. der tatsächlichen Funktionsweise von SMT. Aber es führt offensichtlich zu keinem Erkenntnisgewinn, sondern nur zu unqualifizierten Angriffen.
Letzte Worte:
Das Thema wirkte auf den ersten Blick interessant, gerade auch wegen der Sicherheitsrelevanz z.B. der tatsächlichen Funktionsweise von SMT. Aber es führt offensichtlich zu keinem Erkenntnisgewinn, sondern nur zu unqualifizierten Angriffen.
Letzte Worte:
- Die Präsentation der beiden logischen Kerne eines physischen Kerns auf Basis von SMT/HT ist im Allgemeinen symmetrisch. Diese aus meinem sicher lücken- und fehlerhaften Wissen getroffene Behauptung ist natürlich durch die Dokumentation einer CPU-Architektur oder durch Fachliteratur widerleglich. Die Ausbreitung von phänomenologischen Banalitäten, etwa dass ein Softwarehersteller für eine notwendige Vorzugsentscheidung zwischen einem Wertepaar grundsätzlich den kleineren Wert nimmt, führt dagegen nicht weiter.
- Wie oft welche Execution Unit pro Kern vorhanden ist, steht üblicherweise im Handbuch der jeweiligen Architektur. ALUs findet man heute in der Regel vier, teils auch fünf (Golden Cove). Wenn nur von Execution Units oder der "Breite" der CPU die Rede ist, bezieht sich das normalerweise auf die ALUs.
- Eine ausführliche Darstellung von Multithreading einschließlich SMT findet sich in Hennessy/Patterson, Computer Architecture, 6. Auflage 2019, Seite 242 ff.
- Das nachzuschlagen, hat mich daran erinnert, dass ich oben besser von Functional Units anstelle von Execution Units gesprochen hätte. Glücklicherweise meint Google, das wäre dasselbe.
Für mich ist das Thema durch.
Du teilst Screenshots und sagst es läuft auf 2019 ohne aber zu sagen, dass die "hier ist es böse" Screenshots mit abweichenden Einstellungen gemacht wurden - zumindest hab ich das jetzt so verstanden.
Aus meiner Sicht konnte ich bisher noch nie fehlerhaftes Verhalten des Schedulers feststellen und von daher bin ich hier raus.
Nur soviel:
Ich habe es deshalb als Überbuchung gesehen, weil du eben - zumindest bei der von mir angenommenen Konfig (Core Scheduler, HWThreadsperCore=1) so definiert hast, dass die Workloads eben an den Kerngrenzen getrennt sind und - wie du richtig sagst - der Scheduler den Cache eben erst mal löschen musst.
Keine Überbuchung hast du bei HWThreads-perCore=2, dann verteilt er die 8 angeforderten Kerne der VM aber auf 4 "echte" (a/b oder in Deiner Nomenklatur 0/1) und das ist dann defintiv nicht die doppelte Rechenleistung.
S.
Du teilst Screenshots und sagst es läuft auf 2019 ohne aber zu sagen, dass die "hier ist es böse" Screenshots mit abweichenden Einstellungen gemacht wurden - zumindest hab ich das jetzt so verstanden.
Aus meiner Sicht konnte ich bisher noch nie fehlerhaftes Verhalten des Schedulers feststellen und von daher bin ich hier raus.
Nur soviel:
Ich habe es deshalb als Überbuchung gesehen, weil du eben - zumindest bei der von mir angenommenen Konfig (Core Scheduler, HWThreadsperCore=1) so definiert hast, dass die Workloads eben an den Kerngrenzen getrennt sind und - wie du richtig sagst - der Scheduler den Cache eben erst mal löschen musst.
Keine Überbuchung hast du bei HWThreads-perCore=2, dann verteilt er die 8 angeforderten Kerne der VM aber auf 4 "echte" (a/b oder in Deiner Nomenklatur 0/1) und das ist dann defintiv nicht die doppelte Rechenleistung.
S.
Core --> Logischer Kern einer CPU eines HV-Hosts
PH-Core --> Physikalischer Kern einer CPU eines HV-Hosts Falls HT auf dieser aktiv ist. (0.0, 0.2, 0.4 ...)
HT-Core --> Fake Kern einer CPU eines HV-Hosts Falls HT auf dieser aktiv ist. (0.1, 0.3, 0.5 ...)
PH-Core --> Physikalischer Kern einer CPU eines HV-Hosts Falls HT auf dieser aktiv ist. (0.0, 0.2, 0.4 ...)
HT-Core --> Fake Kern einer CPU eines HV-Hosts Falls HT auf dieser aktiv ist. (0.1, 0.3, 0.5 ...)
Diese Annahmen sind falsch, denn:
Es gibt nicht "1 physikalischer Kern und 1 Fake-Kern" pro Core.
Für jeden physischem Kern werden dem OS 2 logische Kerne präsentiert, die sich in Leistung nicht unterscheiden.
Dies kann man auch leicht nachweisen, indem man einen Benchmark auf jeweils einen logischen Kern beschränkt und die Leistung vergleicht. Hier ein Vergleich von Core 0 und 1 (logische cores des 1. physischen cores)
Der Benchmark wurde ausgeführt in einer WSL2 Ubuntu-Installation mit
sysbench --threads=1 cpu runPer Taskmanager wurde die VM dem jeweiligem Core zugewiesen.
Noch etwas Grundlegendes zu Hyperthreading, vereinfacht:
ein CPU-Kern hat verschiedene Teile für verschiedenen Aufgaben
Nicht für jede Instruktion, die die CPU verabeiten muss, wird jeder Teil des Kerns benötigt. Und genau da setzt Hyperthreading an, indem es Teile von dem zweiten Thread, die die nicht benötigten Teile des CPU-Kerns benötigt, dazwischenschiebt, so dass pro CPU-Zyklus (möglichst) kein Teil der CPU ungenutzt bleibt. Daher der ~30% Leistungsgewinn bei aktiviertem HT.
Das kann man auch gut auf diesem Bild sehen, welches nicht von der Marketingabteilung kommt
Das Bild zeigt eine Momentaufnahme der Kerne während eines Zyklus, jedes Kästchen stellt eine execution unit eines Kernes dar.
Bei "Superscalar" (1 Kern kein HT) sieht man, dass manche Teile des Kernes benutzt werden (gelb) und andere nicht (grau) und somit hat etwa die Hälfte des Kernes in diesem Zyklus nichts zu tun hat.
"Multiprozessing" zeigt 2 Cores ohne HT
Bei "Hyperthreading" sieht man, wie die nicht benutzten Teile des Kernes im jeweiligen Zyklus mit Aufgaben aus einem anderen Thread aufgefüllt werden, so dass möglichst jeder Teil des Kernes in diesem Zyklus etwas zu tun hat.
Streng genommen muss man daraus schließen dass ein Core ohne HT nur zu etwa 50% effizient ist (variabel nach workload) und erst durch Multithreading an die 90% ran kommt.
-Thomas
Moin @3063370895,
tue dir jetzt bitte selbst einen Gefallen und messe noch einmal die Performance von Core 0 und Core 1 zusammen (gleichzeitig) und dann noch ein Test mit Core 0 und Core 2 und dann siehst du schon selber, wie sehr du mit dem was du zuvor und auch danach geschrieben hast, dem Marketing auf den Leim gegangen bist. 😉
Beste Grüsse aus Siegmaringen
Alex
Dies kann man auch leicht nachweisen, indem man einen Benchmark auf jeweils einen logischen Kern beschränkt und die Leistung vergleicht. Hier ein Vergleich von Core 0 und 1 (logische cores des 1. physischen cores)
Der Benchmark wurde ausgeführt in einer WSL2 Ubuntu-Installation mit
Der Benchmark wurde ausgeführt in einer WSL2 Ubuntu-Installation mit
tue dir jetzt bitte selbst einen Gefallen und messe noch einmal die Performance von Core 0 und Core 1 zusammen (gleichzeitig) und dann noch ein Test mit Core 0 und Core 2 und dann siehst du schon selber, wie sehr du mit dem was du zuvor und auch danach geschrieben hast, dem Marketing auf den Leim gegangen bist. 😉
Beste Grüsse aus Siegmaringen
Alex
Wo genau widerspricht das was du sagst dem was ich sage?
Logisch, dass wenn man 0 und 1 (beides logische Kerne auf dem selben, physischem Core) gleichzeitig belastet, die Leistung nicht 2x dem entspricht, was ein logischer Kern alleine leisten kann.
Das erschließt sich auch aus dem Rest meines Textes.
Fakt ist, was du oben geschrieben hast ist falsch. Es gibt keinen physischen und „fake“ Core. Es gibt nur zwei gleichwertige logische Cores auf einem physischem Core.
Fakt ist auch dein defizitäres Verständnis von der Funktionsweise von Hyperthreading.
Hier kann ich nur die Empfehlung von C.R.S. unterstreichen, damit tust du dir einen Gefallen...
Und nochwas.. ausgerechnet DU kommst mit Marketing-Gelaber, dem ich auf den Leim gegangen wäre. DU hast die vereinfachten Marketing-Slides gepostet. ICH hingegen technische Informationsslides von Intel.
siehe z.B. Hennessy/Patterson, Computer Architecture, 6. Auflage 2019, Seite 245:
Was im wesentlichen mit dem Bild aus der technischen Dokumentation übereinstimmt, welches ich schon vorhin gepostet habe, aber noch tiefer in die Details verschiedener Arten von Multithreading eingeht.
Das schreib sich Sigmaringen 😉
-Thomas
Logisch, dass wenn man 0 und 1 (beides logische Kerne auf dem selben, physischem Core) gleichzeitig belastet, die Leistung nicht 2x dem entspricht, was ein logischer Kern alleine leisten kann.
Das erschließt sich auch aus dem Rest meines Textes.
Fakt ist, was du oben geschrieben hast ist falsch. Es gibt keinen physischen und „fake“ Core. Es gibt nur zwei gleichwertige logische Cores auf einem physischem Core.
Fakt ist auch dein defizitäres Verständnis von der Funktionsweise von Hyperthreading.
Hier kann ich nur die Empfehlung von C.R.S. unterstreichen, damit tust du dir einen Gefallen...
Eine ausführliche Darstellung von Multithreading einschließlich SMT findet sich in Hennessy/Patterson, Computer Architecture, 6. Auflage 2019, Seite 242 ff.
Und nochwas.. ausgerechnet DU kommst mit Marketing-Gelaber, dem ich auf den Leim gegangen wäre. DU hast die vereinfachten Marketing-Slides gepostet. ICH hingegen technische Informationsslides von Intel.
Zitat von @MysticFoxDE:
Und daher suggeriert dieses, nämlich das man mit HT zwei Dinge parallel verarbeiten kann, auch einen absoluten Humbug. 😉
Das ist kein Humbug, das ist die harte Realität. Es werden im selbem Zyklus (Zeiteinheit) Aufgaben aus mehreren Threads GLEICHZEITIG bearbeitet, was dadurch ermöglicht wird, dass nicht jede Aufgabe alle Teile eines Cores benötigt. Die freien Teile werden mit Aufgaben aus anderen Threads beauftragt.Und daher suggeriert dieses, nämlich das man mit HT zwei Dinge parallel verarbeiten kann, auch einen absoluten Humbug. 😉
siehe z.B. Hennessy/Patterson, Computer Architecture, 6. Auflage 2019, Seite 245:
Das schreib sich Sigmaringen 😉
-Thomas
Moin @3063370895,
ich träume mir eben nichts zusammen.
Ist es eigentlich wirklich so schwer noch zwei weitere Tests zu machen?
Wenn ja, kein Problem, sobald ich wieder an meiner Workstation sitze, lasse ich selbst die heisse Luft aus deinem HT wieder raus.
Und übrigens, HT ist am sterben, bei Intel zumindest. 😉😎
Beste Grüsse aus Sigmaringen😁
Alex
Fakt ist auch dein defizitäres Verständnis von der Funktionsweise von Hyperthreading.
ich träume mir eben nichts zusammen.
Ist es eigentlich wirklich so schwer noch zwei weitere Tests zu machen?
Wenn ja, kein Problem, sobald ich wieder an meiner Workstation sitze, lasse ich selbst die heisse Luft aus deinem HT wieder raus.
Und übrigens, HT ist am sterben, bei Intel zumindest. 😉😎
Beste Grüsse aus Sigmaringen😁
Alex
Lies doch mal zu Ende was ich geschrieben habe, oder reicht es bei dir nur für einen Satz?
Wenn ja, kein Problem, sobald ich wieder an meiner Workstation sitze, lasse ich selbst die heisse Luft aus deinem HT wieder raus.
"mein" HT?
Na dann verbrenne dich mal nicht.
Und übrigens, HT ist am sterben, bei Intel zumindest. 😉😎
Das wäre gut für dich - dann wird dein mangelndes Verständnis davon zumindest nicht mehr relevant sein.
Beste Grüsse aus Sigmaringen😁
Na immerhin hat das diesmal geklappt. Auch wenn man "Grüße" nicht "Grüsse" schreibt.
-Thomas
PS: vielleicht klappt es damit für dich besser: 😉😎😁😒
PPS: Mich würde eine Quelle für deine Behauptung interessieren, dass Intel HT abwirft. Aus der aktuellen Generation gibt es keinen i7/i9/Xeon Platinum/Gold ohne HT
Zitat von @3063370895:
Logisch, dass wenn man 0 und 1 (beides logische Kerne auf dem selben, physischem Core) gleichzeitig belastet, die Leistung nicht 2x dem entspricht, was ein logischer Kern alleine leisten kann.
Logisch, dass wenn man 0 und 1 (beides logische Kerne auf dem selben, physischem Core) gleichzeitig belastet, die Leistung nicht 2x dem entspricht, was ein logischer Kern alleine leisten kann.
Zitat von @MysticFoxDE:
Moin @3063370895,
ich träume mir eben nichts zusammen.
Ist es eigentlich wirklich so schwer noch zwei weitere Tests zu machen?
Es ist nicht nötig, da ich das Ergebnis bereits kenne. Wie oben beschrieben.Moin @3063370895,
Fakt ist auch dein defizitäres Verständnis von der Funktionsweise von Hyperthreading.
ich träume mir eben nichts zusammen.
Ist es eigentlich wirklich so schwer noch zwei weitere Tests zu machen?
Wenn ja, kein Problem, sobald ich wieder an meiner Workstation sitze, lasse ich selbst die heisse Luft aus deinem HT wieder raus.
Na dann verbrenne dich mal nicht.
Und übrigens, HT ist am sterben, bei Intel zumindest. 😉😎
Beste Grüsse aus Sigmaringen😁
Alex
-Thomas
PS: vielleicht klappt es damit für dich besser: 😉😎😁😒
PPS: Mich würde eine Quelle für deine Behauptung interessieren, dass Intel HT abwirft. Aus der aktuellen Generation gibt es keinen i7/i9/Xeon Platinum/Gold ohne HT
Moin @3063370895,
und was ist eigentlich so schwer daran zu verstehen, dass lediglich eine zweite Prozesswarteschlange derselben Recheneinheit noch lange kein eigenständiger Core ist.
na ja, laut deinen eigenen Worten sollte dabei aber so zwischen +30% und +100% möglich sein.
Hier nochmals zur Erinnerung.
also komm, zeig, wo?
Und warum hast du es nicht gleich mit gepostet?
Na dann verbrenne dich mal nicht.
Mach dir da keine Sorgen, habe einen kleinen und einen grossen Hausdrachen zuhause, sprich, ich kann mit Feuer gut umgehen. 😉
Nö, sonst bekomme ich von jemand wegen so Sachen wie NDA, wahrscheinlich ordentlich einen auf den Deckel. 😬
Aber einen kleinen Tipp gebe ich dir dennoch. Da gibt es so Dinge wie E-.... und die sind bei MT meistens um Welten effektiver als HT. 😉
Gruss Alex
Lies doch mal zu Ende was ich geschrieben habe, oder reicht es bei dir nur für einen Satz?
und was ist eigentlich so schwer daran zu verstehen, dass lediglich eine zweite Prozesswarteschlange derselben Recheneinheit noch lange kein eigenständiger Core ist.
Logisch, dass wenn man 0 und 1 (beides logische Kerne auf dem selben, physischem Core) gleichzeitig belastet, die Leistung nicht 2x dem entspricht, was ein logischer Kern alleine leisten kann.
na ja, laut deinen eigenen Worten sollte dabei aber so zwischen +30% und +100% möglich sein.
Hier nochmals zur Erinnerung.
Daher der ~30% Leistungsgewinn bei aktiviertem HT.
Streng genommen muss man daraus schließen dass ein Core ohne HT nur zu etwa 50% effizient ist (variabel nach workload) und erst durch Multithreading an die 90% ran kommt.
Streng genommen muss man daraus schließen dass ein Core ohne HT nur zu etwa 50% effizient ist (variabel nach workload) und erst durch Multithreading an die 90% ran kommt.
also komm, zeig, wo?
Es ist nicht nötig, da ich das Ergebnis bereits kenne. Wie oben beschrieben.
Und warum hast du es nicht gleich mit gepostet?
Wenn ja, kein Problem, sobald ich wieder an meiner Workstation sitze, lasse ich selbst die heisse Luft aus deinem HT wieder raus.
"mein" HT?Na dann verbrenne dich mal nicht.
Mach dir da keine Sorgen, habe einen kleinen und einen grossen Hausdrachen zuhause, sprich, ich kann mit Feuer gut umgehen. 😉
PPS: Mich würde eine Quelle für deine Behauptung interessieren, dass Intel HT abwirft. Habe mir gerade stichprobenmäßig ~20 Prozessoren aus dem aktuellen Lineup angesehen (Server sowie Desktop) und keinen ohne HT gefunden.
Nö, sonst bekomme ich von jemand wegen so Sachen wie NDA, wahrscheinlich ordentlich einen auf den Deckel. 😬
Aber einen kleinen Tipp gebe ich dir dennoch. Da gibt es so Dinge wie E-.... und die sind bei MT meistens um Welten effektiver als HT. 😉
Gruss Alex
Zitat von @MysticFoxDE:
Moin @3063370895,
und was ist eigentlich so schwer daran zu verstehen, dass lediglich eine zweite Prozesswarteschlange derselben Recheneinheit noch lange kein eigenständiger Core ist.
Habe ich nie behauptet. Du verstehst es einfach nichtMoin @3063370895,
Lies doch mal zu Ende was ich geschrieben habe, oder reicht es bei dir nur für einen Satz?
und was ist eigentlich so schwer daran zu verstehen, dass lediglich eine zweite Prozesswarteschlange derselben Recheneinheit noch lange kein eigenständiger Core ist.
Logisch, dass wenn man 0 und 1 (beides logische Kerne auf dem selben, physischem Core) gleichzeitig belastet, die Leistung nicht 2x dem entspricht, was ein logischer Kern alleine leisten kann.
na ja, laut deinen eigenen Worten sollte dabei aber so zwischen +30% und +100% möglich sein.
Hier nochmals zur Erinnerung.
Daher der ~30% Leistungsgewinn bei aktiviertem HT.
Streng genommen muss man daraus schließen dass ein Core ohne HT nur zu etwa 50% effizient ist (variabel nach workload) und erst durch Multithreading an die 90% ran kommt.
Streng genommen muss man daraus schließen dass ein Core ohne HT nur zu etwa 50% effizient ist (variabel nach workload) und erst durch Multithreading an die 90% ran kommt.
also komm, zeig, wo?
Nochmal, ganz langsam, für dich:
Ein Core ohne HT ist zu keinem Zeitpunkt zu 100% belastet, da nicht jede Aufgabe, die eine CPU erledigt, alle Teile des Cores beansprucht. Hier setzt HT an und füllt die nicht benötigten Teile des Cores mit Aufgaben eines anderen Threads auf. Dadurch kann die Effizienz des Cores gesteigert werden, eben bis zu besagten ~90%, je nach Workload.
Es ist nicht nötig, da ich das Ergebnis bereits kenne. Wie oben beschrieben.
Und warum hast du es nicht gleich mit gepostet?
Wenn ja, kein Problem, sobald ich wieder an meiner Workstation sitze, lasse ich selbst die heisse Luft aus deinem HT wieder raus.
"mein" HT?Na dann verbrenne dich mal nicht.
Mach dir da keine Sorgen, habe einen kleinen und einen grossen Hausdrachen zuhause, sprich, ich kann mit Feuer gut umgehen. 😉
PPS: Mich würde eine Quelle für deine Behauptung interessieren, dass Intel HT abwirft. Habe mir gerade stichprobenmäßig ~20 Prozessoren aus dem aktuellen Lineup angesehen (Server sowie Desktop) und keinen ohne HT gefunden.
Nö, sonst bekomme ich von jemand wegen so Sachen wie NDA, wahrscheinlich ordentlich einen auf den Deckel. 😬
Aber einen kleinen Tipp gebe ich dir dennoch. Da gibt es so Dinge wie E-.... und die sind bei MT meistens um Welten effektiver als HT. 😉
Gruss Alex
Gruss Alex
Ich bin hier fertig. Du verstehst einfach nicht die Technik dahinter. Ich habe es so einfach wie möglich erklärt. Liegt wohl an mir, ich kann es nicht einfach genug erklären, so dass selbst du es verstehst. Mein Fehler - sorry 😉
-Thomas
Moin @3063370895,
oder du willst mich nicht verstehen. 😉
Thomas, diese Marketingmantra hast du jetzt X Mal wiederholt und ich habe dieses auch verstanden!
Kannst du es nun auch praktisch belegen, danke.
Übrigens, bei modernen CPU's, ist es im Hinblick auf hohe und durchgängige Performance eher wichtiger den richtigen Kühler zu wählen als HT einzuschalten. 😉
Sagen wir es mal so, sie versuchen es sehr oft, aber bisher haben sie mich zum Glück am Stück wieder ausgespuckt. 🤪
Gruss Alex
Habe ich nie behauptet. Du verstehst es einfach nicht.
oder du willst mich nicht verstehen. 😉
Ein Core ohne HT ist zu keinem Zeitpunkt zu 100% belastet, da nicht jede Aufgabe, die eine CPU erledigt, alle Teile des Cores beansprucht. Hier setzt HT an und füllt die nicht benötigten Teile des Cores mit Aufgaben eines anderen Threads auf. Dadurch kann die Effizienz des Cores gesteigert werden, eben bis zu besagten ~90%, je nach Workload.
Thomas, diese Marketingmantra hast du jetzt X Mal wiederholt und ich habe dieses auch verstanden!
Kannst du es nun auch praktisch belegen, danke.
Übrigens, bei modernen CPU's, ist es im Hinblick auf hohe und durchgängige Performance eher wichtiger den richtigen Kühler zu wählen als HT einzuschalten. 😉
Die tun mir echt leid. Fressen Drachen eigentlich Füchse?
Sagen wir es mal so, sie versuchen es sehr oft, aber bisher haben sie mich zum Glück am Stück wieder ausgespuckt. 🤪
Gruss Alex
Thomas, diese Marketingmantra hast du jetzt X Mal wiederholt und ich habe dieses auch verstanden!
Kannst du es nun auch praktisch belegen, danke.
Kannst du es nun auch praktisch belegen, danke.
Mache Aufgabe X auf dem Kern 0 (physischer Kern 0 logischer Kern 0). Die Aufgabe soll den logischen Kern zu 100% belasten. Jetzt mache Aufgabe Y auf Kern 1 (physischer Kern 0 logischer Kern 1). Auch diese Aufgabe soll den logischen Kern zu 100% belasten.
Obwohl der Kern nach deinem Verständnis zu 100% durch Aufgabe X ausgelastet ist, kann die Aufgabe Y auch noch mit einer bestimmten Geschwindigkeit ausgeführt werden. Die Geschwindigkeit von Aufgabe Y ist dann nur noch davon abhängig, wie viele Teile des physischem Kern 0 durch Aufgabe X nicht beansprucht sind und ob diese Teile durch die Aufgabe Y beansprucht werden können.
Übrigens, bei modernen CPU's, ist es im Hinblick auf hohe und durchgängige Performance eher wichtiger den richtigen Kühler zu wählen als HT einzuschalten. 😉
Warum lenkst du immer vom Thema ab und versuchst nicht mal meine Kernaussage (pun intended) zu HT mit Fakten zu widerlegen? Schwurblergequatsche à la "du bist auf Marketing reingefallen" sind keine Fakten.
-Thomas
Moin @3063370895,
nacheinander und nicht gleichzeitig, ansonsten verrate mir mal bitte kurz wie der Cacheinhalt des Prozesses A, der auf deinem Logischen Kern 0 läuft, von Zugriff durch den Prozess B geschützt ist, der wiederum auf dem logischen Kern 1, desselben physikalischen Kerns läuft.
Der Leistungszugewinn bei HT kommt übrigens daher, weil der Hardware-Task-Scheduler der CPU um einiges effizienter ist als der des OS. 😉
Weil wenn der physikalische Kern 0 wegen eines Prozesses der auf seinem logischen Kern 0 läuft an seine thermische Kapazitätsgrenze kommt, du mit einem zweiten Prozess, der auf seinem logischen Kern 1 läuft, überhaupt gar nichts an Leistung herausholst, ohne dabei den anderen Prozess der auf den logischen Kern 0 läuft, entsprechend auszubremsen. 😉
Ausserdem sitze ich gerade bei einem Kunden und muss sein historisch gewachsenes Netzwerk dokumentieren und kann mich daher nur mit begrenzten Kapazitäten gleichzeitig auch noch um dich kümmern.
Gruss Alex
Mache Aufgabe X auf dem Kern 0 (physischer Kern 0 logischer Kern 0). Die Aufgabe soll den logischen Kern zu 100% belasten. Jetzt mache Aufgabe Y auf Kern 1 (physischer Kern 0 logischer Kern 1). Auch diese Aufgabe soll den logischen Kern zu 100% belasten.
nacheinander und nicht gleichzeitig, ansonsten verrate mir mal bitte kurz wie der Cacheinhalt des Prozesses A, der auf deinem Logischen Kern 0 läuft, von Zugriff durch den Prozess B geschützt ist, der wiederum auf dem logischen Kern 1, desselben physikalischen Kerns läuft.
Der Leistungszugewinn bei HT kommt übrigens daher, weil der Hardware-Task-Scheduler der CPU um einiges effizienter ist als der des OS. 😉
Obwohl der Kern nach deinem Verständnis zu 100% durch Aufgabe X ausgelastet ist, kann die Aufgabe Y auch noch mit einer bestimmten Geschwindigkeit ausgeführt werden. Die Geschwindigkeit von Aufgabe Y ist dann nur noch davon abhängig, wie viele Teile des physischem Kern 0 durch Aufgabe X nicht beansprucht sind und ob diese Teile durch die Aufgabe Y beansprucht werden können.
Warum lenkst du immer vom Thema ab und versuchst nicht mal meine Kernaussage (pun intended) zu HT mit Fakten zu widerlegen? Schwurblergequatsche à la "du bist auf Marketing reingefallen" sind keine Fakten.
Übrigens, bei modernen CPU's, ist es im Hinblick auf hohe und durchgängige Performance eher wichtiger den richtigen Kühler zu wählen als HT einzuschalten. 😉
Warum lenkst du immer vom Thema ab und versuchst nicht mal meine Kernaussage (pun intended) zu HT mit Fakten zu widerlegen? Schwurblergequatsche à la "du bist auf Marketing reingefallen" sind keine Fakten.
Weil wenn der physikalische Kern 0 wegen eines Prozesses der auf seinem logischen Kern 0 läuft an seine thermische Kapazitätsgrenze kommt, du mit einem zweiten Prozess, der auf seinem logischen Kern 1 läuft, überhaupt gar nichts an Leistung herausholst, ohne dabei den anderen Prozess der auf den logischen Kern 0 läuft, entsprechend auszubremsen. 😉
Ausserdem sitze ich gerade bei einem Kunden und muss sein historisch gewachsenes Netzwerk dokumentieren und kann mich daher nur mit begrenzten Kapazitäten gleichzeitig auch noch um dich kümmern.
Gruss Alex
Ich geb’s auf, das macht keinen Sinn.
selten jemanden gesehen der so sehr von sich selbst überzeugt ist obwohl er so offensichtlich falsch liegt.
-Thomas
selten jemanden gesehen der so sehr von sich selbst überzeugt ist obwohl er so offensichtlich falsch liegt.
-Thomas
Moin @3063370895,
ähm, wer behauptet den hier ständig irgendetwas, sogar mit Sprüchen wie 30% mehr Leistung und so und kann das im Nachgang noch nicht mal belegen?
Na ja, nach dem du ja so sehr von meinem Unwissen oder deinem eigenen Wissen überzeugt bist, werde ich sobald ich im Büro bin, deine Behauptungen auf jeden Fall etwas wieder zurechtrücken und zwar untermalt mit realen Ergebnissen. 😉
Und nun suche ich jetzt lieber mal weiter wo diese ganzen wild beschrifteten Patchfelder hinführen. 😬😭
Gruss Alex
Ich geb’s auf, das macht keinen Sinn.
selten jemanden gesehen der so sehr von sich selbst überzeugt ist obwohl er so offensichtlich falsch liegt.
selten jemanden gesehen der so sehr von sich selbst überzeugt ist obwohl er so offensichtlich falsch liegt.
ähm, wer behauptet den hier ständig irgendetwas, sogar mit Sprüchen wie 30% mehr Leistung und so und kann das im Nachgang noch nicht mal belegen?
Na ja, nach dem du ja so sehr von meinem Unwissen oder deinem eigenen Wissen überzeugt bist, werde ich sobald ich im Büro bin, deine Behauptungen auf jeden Fall etwas wieder zurechtrücken und zwar untermalt mit realen Ergebnissen. 😉
Und nun suche ich jetzt lieber mal weiter wo diese ganzen wild beschrifteten Patchfelder hinführen. 😬😭
Gruss Alex
Moin Thomas,
du weist aber schon das ich trotzt deines kindischen "blockens" dennoch weiter auf deinen Unsinn, den du übrigens in meinem Beitrag gepostet hast, antworten kann?
https://www.youtube.com/watch?v=VcoVYfDVEww
Schau mal bitte ganz genau hin was ganz unten in dem Bild steht. 😉
Also das hier.
Ausserdem siehst du in diesem Video auch ganz genau, dass die beiden Thread's die auf demselben Core laufen, nacheinander und nicht parallel eingereiht werden.
Und hier zum Thema was es so alles an Nutzen bringt.
https://www.youtube.com/watch?v=8qkXKmpOWa0
https://www.youtube.com/watch?v=xg_l-RWjAh8
https://www.youtube.com/watch?v=VkLrVUslDS0
Gruss Alex
du weist aber schon das ich trotzt deines kindischen "blockens" dennoch weiter auf deinen Unsinn, den du übrigens in meinem Beitrag gepostet hast, antworten kann?
https://www.youtube.com/watch?v=VcoVYfDVEww
Schau mal bitte ganz genau hin was ganz unten in dem Bild steht. 😉
Also das hier.
Ausserdem siehst du in diesem Video auch ganz genau, dass die beiden Thread's die auf demselben Core laufen, nacheinander und nicht parallel eingereiht werden.
Und hier zum Thema was es so alles an Nutzen bringt.
https://www.youtube.com/watch?v=8qkXKmpOWa0
https://www.youtube.com/watch?v=xg_l-RWjAh8
https://www.youtube.com/watch?v=VkLrVUslDS0
Gruss Alex
