Ein "Hintergrund"-Thread läuft doch über den Dispatcher des Main-Threads soweit ich weiß, zumindest unter Windows.

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...

Und wie kommen die Daten von der SPS?

ComPort und TCP-Stack haben ja einen Cache, womit es garnicht wichtig wäre, dass es schnell und genau getimet gelesen wird ... so lange man nur insgesamt schneller liest, als der Cache voll läuft.

Zitat von himitsu:

Und wie kommen die Daten von der SPS?

ComPort und TCP-Stack haben ja einen Cache, womit es garnicht wichtig wäre, dass so oder und genau gelesen wird ... so lange man nur insgesamt schneller liest, als der Cache voll läuft.

Lesen tue ich mit leicht modifizierten Snap7. An einer 1500 schaffe ich damit via gemanagtem Netz ca. 550 Polls pro Sekunde, wobei derzeit nur alle 500 ms gelesen wird (was sich aber zeitweise ändern kann). Ist halt eine Entwicklung. Wie gesagt: Top-Speed wären temporär ein Log alle 100ms. Wenn's schneller werden muss, dann werden die Daten ehe in der SPS mit Zeitstempel versehen. Dann ist die PC-Seite mehr oder weniger egal...

Zitat von BigAl:

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

Die entsprechende Funktion der Windows API zum Einstellen der Zeit lautet timeBeginPeriod.

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