Laufzeitunterschiede sind höchstens ein Resultat der Problematik. Das Problem an sich ist aber das Laufzeitscheduling und dessen Unterschiede
Kannst Du das ein wenig ausführlicher beschreiben oder mich entsprechend auf Lesestoff verlinken?
Auf Lektüre kann ich dich leider nicht verweisen, in der Theorie habe ich mich bislang nur ausführlicher mit harter ("echter") Echtzeit und deren Anforderungen befasst. Eventuell kann jemand Anderes da aushelfen, meine Erfahrungen mit Linux und Scheduling beruhen ausschließlich auf praktischer Erfahrung und Tests.
Sollte damit das CPU sheduling gemeint sein
Ja ist es. Allein die Wahl des Schedulers verändert aber die Problematik nicht.
In Kurz bekommt jedes Programm einen Zeitslot zugeteilt (wie, wann, wie lange hängt vom Scheduler ab) und kann diesen entweder frühzeitig aufgeben oder voll ausnutzen.
Gameserver geben sie fast immer frühzeitig auf, benötigen dafür in sehr regelmäßigen und genauen Intervallen einen solchen. Webserver sind exakt das Gegenteil. Entsprechend passt das nicht sonderlich gut zusammen und die Zeitslots des Gameservers werden verschoben/ungenau. Resultat sind (Micro)lags durch
a) falsche / nicht ausreichende Zukunfts-Simulationen der Game-Engine und entsprechende Korrekturen. Erkennbar durch leichte Sprünge
b) verspätete Rückantworten. Reduziert die serverseitige FPS-Berechnung und ist zumal an der Berechnung von Physik-Simulationen gut erkennbar.
Wenn du nun einen 2. Scheduler (Hypervisor) über diesen einen Scheduler packst wird das Problem offensichtlich nicht grade verbessert da beide ihre Zeitslots verteilen. Das Problem ist simulierbar indem man sleep-Jitter auf dem Server analysiert, entsprechenden Programmcode hatte ich bereits paarmal im Forum verlinkt.
gilt diese Aussage auch noch wenn man als Vergleich ein Win2012R2+Hyper-V ins Rennen bringt?
Tut mir leid, ich habe keine Erfahrung mit Hyper-V. Es soll sehr gut sein aber dann wiederum soll die Metro Oberfläche auch "sehr gut" sein