none
Unterschiedliches Verhalten einer Anwendung auf speziefischer Hardware nach Update von Windows 10(1709) auf Windows 10(1803 oder hoeher) RRS feed

  • Frage

  • Hallo Community,

    wie im Titel schon steht habe ich bei einer Anwendung der Firma in der ich arbeite ein Problem nach dem Update auf Windows 10(1803). Zunächst erstmal Angaben zur Verwendeten Hardware:

    Merkmal

    Test PC alt Win 10 Enterprise 1709

    Test PC alt Win 10  Enterprise 1803

    Test PC neu Win 10 Enterprise 1803

    CPU

    Treiberversion Treiberanbieter

    Intel Core i3 2120 3,3GHz

    10.0.16299.15 Microsoft

    Intel Core i3 2120 3,3GHz

    10.0.17134.1 Microsoft

    Intel Core i3 4150 3,5GHz

    10.0.17134.1 Microsoft

    Motherboard

    Model

    Chipset

    Southbridge

    Dell Inc.

    0M5dCD

    Intel Sandy Bridge H61

    Dell Inc.

    0M5dCD

    Intel Sandy Bridge H61

    HP

    198E

    Intel Haswell

    H81

     

    RAM

    Type

    Channel

    Size

    DDR 3

    Dual

    4 GBytes

    DDR 3

    Dual 4

    GBytes

    DDR 3

    Single

    4 GBytes

     

    Netzwerkadapter

    Treiberversion Treiberanbieter

    Realtek PCIe GBE Family Controller 9.1.406.2015 Microsoft

    Realtek PCIe GBE Family Controller 9.1.406.2015 Microsoft

    Realtek PCIe GBE Family Controller 9.1.406.2015 Microsoft

     

    In der Tabelle sind die Daten der Testmaschinen zu sehen, auf der die Unterschiedlichen Windowsversionen aufgespielt wurden und die mögliche Sendelast unserer Anwendung getestet wurde. Mit Windows 10 1709 konnte eine Sendelast von 200 MBit/s erreicht werden. Nach beenden und Neustarten der Anwendung konnte diese Sendelast immer zuverlässig sichergestellt werden. Upgraded man die Windowsversion oder spielt ein Cleaninstall von Windows 10 1803 auf, auch mit den Kumulativen Updates kann der Wert für die Sendelast nicht mehr zuverlässig sichergestellt werden. Von 10 Versuchen (Beenden -> Neustarten der Anwendung) konnte 6 mal die Sendelast von 200 MBit/s erreicht werden, jedoch die anderen 4 mal wurde nur eine Sendelast von 120 MBit/s erreicht. Hierbei konnte im Code der Anwendung festgestellt werden, dass mit Windows 10 1803, die Anwendung bei einem Aufruf von Sleep(dwmilliseconds = 1 ms) öfters 30 ms gesleept hat statt wie erwartet 15 ms oder weniger wie es mit Windows 10 1709 der Fall war.

    Zusätzlich habe ich ETW Traces aufgenommen und konnte darin erkennen, dass bei der Messung des alten Test PCs mit Windows 10 1803 unsere Anwendung ca. 20000 weniger Context Switches hatte. Da ich noch nicht viel Erfahrung in der Analyse von ETW Traces besitze konnte ich diesen leider nicht mehr Informationen entnehmen. Jedoch konnte man bei der Aufnahme der Traces sehen, dass wenn die Trace Funktion gestartet wird, der alte Test PC mit Windows 10 1709 die 200 MBit/s aufrechterhalten konnte. Bei der Aufnahme mit Windows 10 1803 hingegen, wenn die Anwendung 200 MBit/s stabil anliegen hatte und die Trace Funktion gestartet wurde ist die Leistung auf 100 MBit/s gesunken für die gesamte dauer des Tracings. Deaktivierte man die Trace Funktion ist sie wieder auf 200 MBit/s gestiegen. Mir ist bewusst das bei dieser Aufnahme somit das Tracing Programm einen Einfluss ausgeübt hat, allerdings war dies eben bei Windows 10 1709 nicht der Fall.

    Mit Windows 10 1803 auf dem Test PC mit neuerer Hardware konnten hingegen wieder zuverlässig die 200 MBit/s erreicht werden. Auf dem neuen Test PC beeinflusste das aktivieren der Trace Funktion nur für eine Sekunde die Sendeleistung oder beim Speichern. Beim alten Test PC Windows 10 1803 beeinflusste das laufende Tracing hingegen Permanent die Sendelast. Ich vermute deswegen irgendeine Änderung im Scheduling oder Timing bei der Windows 10 1803 Version auf dem alten Test PC.

    Ich würde gerne Wissen was die Ursache für dieses Verhalten ist, sowie ob ich dieses Problem beheben kann über Gewisse Einstellungen oder ähnliches, nicht mit Änderung der Hardware, da bereits zu sehen ist, dass eine Änderung der Hardware das ganze wieder stabilisiert. Wir wüssten nur gern woher dieses zufällig auftretende Problem kommt und was wir unseren Kunden als Voraussetzungen nennen können, damit wir die 200 MBit/s Sendelast gewährleisten können. Zusätzlich würden wir gerne Wissen wie dieses Problem nur Zufällig auftreten kann und ob dieses Problem mit zukünftigen Windows Versionsupdates, je nach Hardware wieder auftreten könnte.

    Mit freundlichen Grüßen

    Wito90

    Dienstag, 2. Juli 2019 07:01

Alle Antworten

  • Ein Sleep von 1 Millisekunde ist kein tatsächlicher Hardware-Sleep sondern ein reiner Softwaresleep.
    Dieser hängt dann von verschiedenen Laufzeitfaktoren ab und kann nicht garantiert werden und kann daher auch schon mal länger dauern.
    Dies habe ich schon selber so erlebt. Ein Sleep ab 18 Millisekunden entllastet erst tatsächlich die CPU.

    Abhilfe kann nur eine Timer schaffen, der dann über einen Backgroudthread einen Callback ausführt.
    Allerdings sollte die Aktion dann auch innerhalb der Zeit abgeschlossen sein, da der Timer den Callback immer wieder neu aufruft auch wenn die Aktion noch dauert.
    Hier muss man dann den Timer stoppen, die Aktion durchführen und den Timer wieder starten.

    Alternativ hilft statt Sleep auch die Funktion Wait(handle, Timeout), wobei das Handle z.B. der Prozess oder Thread selber sein kann.

    Zum Rest deines Problems prüfe mal die Energieoptionen, ob dein System auf Höchstleistung eingestellt ist.
    Nach einem Upgrade kann dieses Energieprofil u.U. auch fehlen, dann kann man aber ein neues anlegen.
    Der Standard ist nämlich "Ausbalanciert", was ins besonders bei Verwendung von VM's dann nie zur Höchstleistung kommt.

    Freitag, 5. Juli 2019 21:39
  • Danke für die Antwort. Dass ein Sleep von 1ms nicht garantiert werden kann weiß ich, jedoch geht es mir auch nicht darum das er 1ms sleepen sollte. Allerdings sollte hierbei dann maximal 15 ms gesleept werden, wegen der interruptzeit des Systems. Hierbei ist eben verwunderlich dass er doppelt so lang schläft also ca 2 Timeslices.

    Energieoptionen hab ich schon umgestellt und getestet, sowohl die optimale Einstellung für Performance als auch der Ultrapower modus ändern nichts am Problem.

    Was für mich das unverständlichste ist, wie es eben passieren kann das bei mehrmaligen neustarten der Applikation diese zufällig erreichbare maximale Sendelast erreicht wird (120 MBit/s oder 200 MBit/s) keine Hardware fehler, Treiber wurden getestet und sind auch auszuschließen. Scheduling wäre mein Gedanke, aber dabei versteh ich dann nicht wieso er bei mehrfachen Neustarts unterschiedlich Schedulen sollte.

    Dienstag, 9. Juli 2019 07:45
  • Windows ist kein Realtime-OS.
    Alle Prozess-/Threadwechsel sind softwaregesteuert und von vielen Faktoren abhängig.
    Dazu kommen die IO-Subsysteme (Netzwerk, Platten u.v.m).

    Windows ist da auch sehr netzwerklastig um ständig irgendwelche Dienste und Verfügbarkeiten abzufragen.
    Da gibt es bestimmt Einstellungen, um dieses zu reduzieren (Stichwort: Computerbrowser-Dienst).

    Auch die 15ms sind da nicht garantiert, wobei nach meinem Gefühl da immer ein Hardwareinterupt eine Rolle spielt, denn nur ein Sleep(18) bringt bei mir die Prozessorlast des Prozesses auf unter 0,01%.

    Auf meinem kleinen Laptop Intel I7 laufen z.B. ca. 250 Prozesse und 3000 Threads.
    Da real ja nur 8 Threads wirklich gleichzeitig laufen können, werden die Threads eben stark serialisiert.
    Nun sind die Wechsel eben mittels Softwareinterupts per Zeitscheibe gesteuert. Da brauchen nur mehrere Threads ihren Anteil voll ausreizen um das System auszubremsen und dann dein Thread letztendlich wieder drankommt.
    Je nach Auslastung können dann auch noch Prozessorwechsel dazukommen. D.h., dass ein Thread/Prozess auf einen anderen Prozessor verschoben wird.

    Dem kann man aber entgegen wirken in dem man die Prozessorzugehörigkeit festlegt, um Wechsel dieser Art auszuschließen:
    https://docs.microsoft.com/de-de/windows/win32/api/winbase/nf-winbase-setthreadaffinitymask
    Damit kann man dann seine Threads in Abhängigkeit der Verfügbarkeit zuordnen

    Ein Punkt kann auch der Virenscanner sein.

    Ich musste meinen GData nach dem Upgrade auf 1903 komplett deinstallieren, mittles AVCleaner Reste beseitigen und neu installieren um anschließend die gewohnte Zugriffsperformance wieder zu bekommen.

    Und zu guter Letzt: Ist die Maschine virtualisiert und hat mehr als 1 Prozessor zugeordnet?
    Hier kommt dann der Virtualisierer ins Spiel und ob mehr CPU's über die VM's zugeordnet sind als real zur Verfügung stehen. Der Hauptspeicher ist da meist eher unkritisch.
    Eine VM wird erst dann per Zeitscheibe wieder aktiv, wenn die Anzahl der benötigten Prozessoren gleichzeitig verfügbar werden.
    Ich habe es da schon erlebt, dass eine 2-CPU-VM schneller ist als eine 4-CPU-VM da eben auf wendiger Ressourcen gewartet werden muss.
    Für wichtige VM's kann man u.U. CPU's und Haupt-Speicher fest reservieren um Wartezeiten und vor allem Prozessorwechsel zu vermeiden. Dies geht dann halt zu Lasten anderer VM's, die sich den Rest dann teilen.

    Mich hat mal ein Kundenadmin gefragt, warum denn unsere BI-Software beim ETL-Prozess (Daten laden) den Server zu 100% auslastet. Die anderen VMs kämen dann zu fast nichts mehr;-).
    Nun ja, es ist Sache der Virtualisierung denn ich bin der Meinung, 100% Auslastung eines Servers sind zulässig. Denn für was ist der denn sonst da als für die Arbeit.

    Dienstag, 9. Juli 2019 09:09