exakte Zeitmessungen auf Multiprozessoren

[TERWI]

Ich buddel diesen Fred mal wieder aus weil er hier den Nagel gennau auf den Kopf trifft
und endlich mal ne Antwort auf supermuckl's letzte Frage kommt.

Vorab gesagt: Ich brauche zwingend eine Routine, welche Zeitabstände <= ca. 200-250µS (mükro, NICHT milli Sekunden !) messen kann. besser noch kürzer.
QPC eignet sich im Prinzip hervorragend - wäre da nur nicht dieses lästige, zufällige hin- und herschalten zwischen den CPU's.

Bei mir z.B. laufen die Zeitunterschiede der CPU's mit der Laufzeit immer mehr auseinander, so das man spätetes nach 1 Stunde Laufzeit nur noch völlig 'beknackte' Negativ- wie auch Positiv-Werte bekommt.

Völligst untauglich.
Und andere Timer kommen leider nicht in Frage, weil die Auflösung zu klein ist.

Hatte dazu schon einen anderen Fred aufgemacht.
Diesen hab ich nur aus o.g. Grund mal weder hochgeholt, weil das Problem an sich hier sehr gut beschrieben ist.
Nur noch keine Lösung in Sicht ?!

Wo diskutieren wir ggf. weiter - in diesem Fred oder in dem anderen Fred ?

[himitsu]

Zitat:

wäre da nur nicht dieses lästige, zufällige hin- und herschalten zwischen den CPU's.

Es gibt nicht nur das Umgeschalte von threads zwischen den CPUs Kernen (MultiProzessor, also mehrere Prozessoren/CPUs/Chips auf einem Mainboard, hat ja kaum jemand), welches man ja abschalten kann (wie drüben shcon jemand sagte), sondern auch noch das zwischen den Threads insgesammt, welches man nicht so leicht beeinflussen kann.
Man kann höchstens seinen Thread an einen Kern binden und muß alle anderen Threads von diesem Kern bannen. (du wirst nur nicht auf alle Threads Zughrif haben und neuerstelle Threads gehen dir schnell mal durch die Lappen)

Da Windows (und bestimmt auch Linux, Mac und co.) überall Fensterorientiert arbeitet, kann man solche Zeiteinheiten nahezu vergessen.
Die Programme Threads werden in Zeitfenstern abgearbeit, also ein paar Millisekunden für diesen Thread, dann wieder ein paar für einen anderen Thread.
Wie diese Zeitfenster verteilt sind, verrät Windows nicht ... es wird nur gesagt, daß dieses sich dynamisch je nach Prozessorauslastung anders verhält. (wieviele Kerne, wer wo laufen darf und wieviel die Threads grade arbeiten und dann wird noch verteilt wer gerade auf welchem Kern arbeitet)

Zitat:

> ...
> Start der Messung
> bissl messen
> Ende des Zeitfensters


> andere Threads werden bearbeitet (das kann ja mehrere Millisekunden dauern)


> Start des nächsten Zeitfensters
> bissl messen
> Ende der Messung
> ...

Und schon kannst du deine Microsekunden vergessen


Das Einzige was geht, und das auch nur, wenn der Messvorgang kürzer ist als das verfügbare Zeitfenser.

Zitat:

> ...
> Threadverarbeitung abgeben (Zeitfenster vorzeitig beenden)


> andere Threads werden bearbeitet (das kann ja mehrere Millisekunden dauern)


> Start des neuen Zeitfensters (ab hier steht ja ein volles Zeitfenster für die nchfolgenden Befehle zur Verfügung)
> Start der Messung
> was sehr Kurzes machen
> Ende der Messung
> ...

Zur Messung externer Dinge ist sowas aber nicht geeignet.


Windows ist nunmal (standardmäßig) kein RealTimeSystem.

Was man machen kann, wenn man schnell auf etwas Reagieren muß/will ist, mit Interrupts zu arbeiten (also quasi auf Treiberebene)

[divBy0]

Oder du kannst verschiedene Realtimeerweiterungen für Windows nutzen. Link oder Link

[hathor]

Enhanced Timer
This Enhanced Timer (Etimer) is based on two Windows* API functions; QueryPerformanceCounter and QueryPerformanceFrequency. There is no way to know which frequency Microsoft is using to implement those two functions on any given platform. But one thing for sure is that the frequency of that timer will never change during the course of timing. The timer can be either the chipset timer or the power management timer or something else.

http://www.delphi-forum.de/viewtopic...=528456#528456

http://www.delphi-forum.de/viewtopic...=528819#528819

With Multi-threaded Applications in Multi-Processor Systems

The Etimer can also be used in Multi-processor systems. Since the time retrieved from the timer will be slightly different on different processors it is important that the start and stop time be taken on the same processor to ensure accuracy. The Etimer was developed to deal with multi processors. It first searches for the available processors and uses the first one available. The processor ID of the processor is used to take the initial reading and is stored in the Etime_t variable so that the final reading will be measured on the same processor. If no processor is available or the processor where the start time was taken is not available, the Etime function will return an error code.

http://software.intel.com/en-us/arti...nhanced-timer/