none
Unterschiedliches Verhalten einer Anwendung auf speziefischer Hardware nach Update von Windows 10(1709) auf Windows 10(1803 oder höher) 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 06:58

Antworten

  • Hallo Wito,

    ich bin sicherlich kein experte will dir aber dennoch antworten.

    Erstmal ist Windows keine Echtzeitmaschine sich darauf zu verlassen das ein sleep oder ein delay wirklich x ms dauert ist reines Wunschdenken. Wie Du selbst schon festgestellt hast können die Abweichungen enorm sein.

    Es gibt immer wieder versuche eine "high resolution timer" unter Windows zum laufen zu bekommen. Mit durchaus guten Ergebnissen. Aber opfern muss man dafür einen logischen Prozessor, der nichts anderes macht als in einer Schleife zu prüfen wieviel Zeit vergangen ist.

    Ob man einen "high resolution timer" braucht häng ganz davon ab wieviel Ticks pro Sekunde benötigt werden. 60 Ticks die Sekunde sollten machbar sein.

    Wenn man nun 200MBit/s versenden will über welches Interface auch immer, muss man die Zeit vom Tick zu Tick messen und anhang der verstrichenen Zeit die zu Versendenden Mbit ermitteln und versenden. Da ein Tick unterschiedlich ausfallen kann, ist die Packet Größe auch immer unterschiedlich aber im durchschnitt gleich.  

    Wie viele Operationen pro Sekunde dem Betriebssystem zur Verfügung wird allein von der Hardware definiert.

    Somit sollte klar sein wo das Problem ist. Mit 1803 sind viele neue Funktionen hinzugekommen die nun mal Ressourcen verbrauchen. Windows 10 + das Update 1803 + eure Software erfordern mehr Operationen die Sekunde als die Hardware liefern kann. Da die Software 6 mal korrekte Werte geliefert hat, ist es kein grundsätzliches Problem.

    Es wird immer so sein das neue Funktionen zu Windows per Update hinzukommen die wiederum Ressourcen verbrauchen. Ihr müsst euch überlegen wie ihr damit umgeht.


    Gruß Thomas
    13 Millionen Schweine landen jährlich im Müll
    Dev Apps von mir: UWP Segoe MDL2 Assets, UI Strings


    Dienstag, 2. Juli 2019 16:31