Absender: Niedermeier Günter
Datum: Fr, 14.04.2006 00:49:39
In-reply-to:
<000e01c65f2a$9175a7f0$0402a8c0@NEO>
> => Vielleicht könnte Günther das mit seinem QoS in der UML etwas > objektiver > beurteilen...? > Stichwort: Timingprobleme! ...das hab' ich im Okt. als mir die Timingprobleme auffielen auch schon bis zum Exzess durchprobiert. Leider ohne auch nur den geringsten Unterschied fest zu stellen. :-((( M.E. fällt das auch erst dann wirklich auf, wenn als Gast auch ein 2.6er Kernel läuft. Bei meinen ersten Versuchen mit mit VMware unter Kernel 2.6 im Host traten erstmals Probleme mit den 2.6er Gastkerneln auf die mit 1000HZ übersetzt waren. Dazu kam noch der Seiteneffekt, dass sich ACPI im Host seit 2.6 dazugemischt hat. Und das bringt in dieser Konstellation die schlimmsten Auswirkungen mit sich. Da kann es schon mal vorkommen, dass sich die Uhr im Gast um +/- 20 sek. pro Minute vertut. (Je nach CPU-Last im Gast) Erste Besserung brachte ein 100HZ Gastkernel - aber nur in geringem Maße. Der beste und vermutlich auch unsauberste Workarround ist: Host mit 1000HZ acpi=off noapic clock=pmtmr und im Gast mit 100HZ (bei 2.6) zu arbeiten - wenn möglich. Zur Not geht auch ein 1000HZ Gast-2.6. Äquivalent denke ich, kann man das auf die UML auch umsetzen. Meine Versuche mit der EFW mit Kernel 2.6 in der UML zeigten ein durchaus ähnliches Verhalten wie in der VMware. Interessanter Weise habe ich mit XEN20 im Cop ebenfalls ein ähnliches Zeitdrift feststellen können. Das bewegt sich aber in geringeren Grenzen von nur +/- 2...3 sek., dafür aber wesentlich sprunghafter. Vermutlich werden diese Probleme erst dann gelöst sein, wenn der Linuxkernel seinen Takt so wie der Windowskernel ableitet, denn mit Windows in der VM hatte ich noch nie timing Probleme. Auch mit normalem clock und acpi im Host. Grundsätzlich gilt für alle o.g. Varianten: sobald der Gast unter Strom steht (hohe konstante CPU-Last) gibt es keinerlei Timingprobleme mehr. Gruß Günter