Ok. hab eben mal ein paar anderen Maschinen getestet. Auflösung auf älteren Rechner 16ms auf aktuellen 1ms...

Noch einmal:

Wie Windows sein Thread-Scheduling macht ist ein Implementierungs-Detail.

Das kann sich durch ein kleines Windows-Update ändern (und es hat sich in der Vergangenheit auch mehrmals geändert!), oder abhängig von verwendeten Architektur oder gar CPU-Modell sein. Verlass dich da nicht drauf.

Es ist abhängig von der aktuellen PC-Auslastung, welche Anwendung grade im Vordergrund ist (wie du bereits feststellen musstest) und wer weiß was noch.

Wenn dir das Standard-Verhalten (Windows macht, was es für das beste hält) nicht reicht, dann musst du schauen, wie sich das über die Windows-API beeinflussen lässt.

PS: Ich habe keinen Beleg, aber ich glaube Zeiten im Millisekunden-Bereich und darunter zu messen ist das Hantieren mit Fließkommazahlen nicht die beste Methode. Nimm besser eine TStopWatch aus System.Diagnostics .

Und aufpassen, ob du dein Programm aus Delphi (F9) startest, oder von extern.

Die Delphi-IDE fummelt seit einer Weile am SystemTimeAdjustment rum, so dass solche Timer plötzlich schneller/öfters reagieren.


Es gibt mehrere Implementationen von Higher-Resolution-Timers (z.B. im DirectX),
aber so lange man nicht an der Kernzuordnung und Priorität der Threads rumfummelt, kann man ganz kleine Intervalle eh vergessen.



Es ist möglich seinen Thread auf einen Kern zu begrenzen
und wenn man dann noch ALLE anderen aktuellen/zukünftigen Threads ALLER anderern Anwendungen davon ausschließt, dann wäre man dort alleine und hätte theoretisch die volle Zeit zur Verfügung.

Um was für Daten geht es eigentlich? Es gibt ja auch die Möglichkeit ganz auf einen PC zu verzichten.
Ich hatte für sowas mal einen Raspberry PI laufen. Oder man geht noch weiter runter zum Arduino, der kann auch WiFi, wenn er muss.

Zitat von Sinspin:

Um was für Daten geht es eigentlich? Es gibt ja auch die Möglichkeit ganz auf einen PC zu verzichten.
Ich hatte für sowas mal einen Raspberry PI laufen. Oder man geht noch weiter runter zum Arduino, der kann auch WiFi, wenn er muss.

Es geht um die Datenerfassung an einer Industrieanlage. Da hat ein Pi nichts verloren . Die Daten kommen von einer SPS...

Wie schon gesagt:

Zitat von himitsu:

Und aufpassen, ob du dein Programm aus Delphi (F9) startest, oder von extern.

Die Delphi-IDE fummelt seit einer Weile am SystemTimeAdjustment rum, so dass solche Timer plötzlich schneller/öfters reagieren.

Danke @shebang für das Schlagwort, denn
https://www.delphipraxis.net/206889-...ml#post1482408

Man kann auch bei Windows 10 noch einstellen, wie die Performance bei Vordergrund- und Hintergrund-Programmen aufgeteilt werden soll:

This PC -> Properties -> Advanced System Settings -> Advanced -> Performance -> Settings -> Advanced -> Processor Scheduling

Dort von "Programs" auf "Background Services" umstellen.

Danach sollte die Thread-Performance von Vordergrund und Hintergrundprogrammen gleich sein. So zumindest die Theorie.

(Es kann sein, dass man zu dieser Einstellung auch einfacher hinkommt, aber dies ist die, die ich gerade gefunden habe.)

Die einfache Idee mit [Win] und dann sowas wie "performance", "Thread" oder "Scheduler" funktioniert garnicht


Hey, es gibt einen Windows Performance Analyser

Google Youtube meint https://www.youtube.com/watch?v=6IXx7xx8t2Y
Wozu brauchen wir da noch AQTime

Zitat von himitsu:

Hey, es gibt einen Windows Performance Analyser

Google Youtube meint https://www.youtube.com/watch?v=6IXx7xx8t2Y
Wozu brauchen wir da noch AQTime

Wegen der Zuordnung von Quelltextzeilen zu Ausführungszeiten?

Zitat von dummzeuch:

(Es kann sein, dass man zu dieser Einstellung auch einfacher hinkommt [...])

Ja, den Weg kann man deutlich verkürzen: SystemPropertiesPerformance.exe > Erweitert > Prozessorzeitplanung.

Grüße
Dalai