exakte Zeitmessungen auf Multiprozessoren

[negaH]

Hi Leute,

heute musste ich erstaunt feststellen das meine Zeitmessroutinen/Taktanzahlmessungen auf einem Intel Duo Core Laptop total falsche Ergebnisse liefern. Ich hatte mich schon damit abgefunden das zb. meine Pi Berechnungen auf einem Core Duo 2.16Ghz Laptop nur 4 mal schneller sind als auf einem P4 1.5Ghz Rechner. Das heist das mein Laptop nur 4 mal schneller ist und nicht mehr Power hergibt.

Jetzt musste ich aber feststellen das es garnicht an dem ist, sondern das meine Zeitmessungen falsche Ergebnisse liefert. Es scheint nun wohl so zu sein das auf dem Laptop die Berechnungen ca. 12 mal schneller sind, was mich natürlich freut, da ich nun einen Rechner habe der innerhalb der letzten Stunde drastisch schneller geworden ist ;););)

Ok. Meine Messroutinen arbeiten mit dem Real Time Counter -> RDTSC. Um dessen Werte in Zeiten umrechnen zu können messe ich mit QueryPerformanceCounter()/Frequency() quasi die Taktfrequenz der CPU aus. RDTSC liefert ja nur die CPU Takte zurück und zb. keine Millisekunden.

Nun, das Ausrechnen dieser Taktfrequenz scheint wohl auf Multiprozessoren nicht ganz trivial zu sein. Besonders weil ja auf Laptops zusätzlich noch das ACPI dazwischen funkt und den Prozessortakt variabel einstellen kann.

Gut, ich weis das man mit GetTickCount() auf der sicheren Seite ist, allerdings ist dessen Auflösung eben nicht berauschend. Ich würde also ungern auf RDTSC verzichten, benötige dann aber auch eine exakte Umrechnung von RDTSC in Zeit.

Hat einer von euch eine Idee, Source oder Hinweise wo ich suchen könnte ?
Und als zweite Frage: kann es sein das das ACPI beide Prozessoren unterschiedlich in der Taktfrequenz drosseln kann ?

Gruß Hagen

[supermuckl]

ich hab das gleiche problem mit dem queryperformancecounter dingens.
meine zeitberechnung zeigt teilweise sogar negative werte an, wenn ich die zeit zwischen 2 befehlen messen will, die dort vergangen ist!!

ich bin mit meinem latein am ende.

gettickcount ist mir auch zu ungenau
und der dx-timer zu ressourcenintensiv

[St.Pauli]

Das scheint nicht nur dir so zu gehen. Das Problem müssen auch viele andere Programme (z.B. Spiele) haben die QueryPerformanceCounter und QueryPerformanceFrequency verwenden.

Zitat:

Zitat von Microsoft

While the QueryPerformanceCounter / QueryPerformanceFrequency API is intended to be multiprocessor aware, bugs in the BIOS or motherboard drivers may result in these routines returning different values as the thread moves from one processor to another.

http://www.gamedev.net/community/for...opic_id=409541

http://support.microsoft.com/kb/909944

Ein AMD-Schreiben

Was ich herausgelesen habe ist, dass es auch helfen kann wenn man die neusten Treiber von AMD oder Intel installieren sollte.

[Muetze1]

Das grunglegende Problem ist der mehrfache Taskswitch pro Sekunde und dein Task wird auch frei von einem Kern auf den anderen verschoben. Wenn ein Kern mal öfters im Halt war oder mehrfach die Taktfrequenz änderte, dann gehen die Time Stamp Counter der beiden Kerne auseinander, da einer weniger Taktimpulse hatte als der andere. Da nun der Thread/Prozess mehrfach zwischen den Kernen wechselt, ist die wahrscheinlich hoch, dass man auf einem Kern den Counter liest (Startpunkt) und auf einem/dem anderen Kern den Counter beim Stoppen. Und so einfach kann die Zeit auch mal negativ sein.

Abhilfe würde hier z.B. das Festlegen eines Threads/Prozesses auf einen logische CPU/Kern helfen. Dies schliesst das beschriebene aus, aber nicht die Nebenwirkungen des Power/Taktmanagements.

SetThreadAffinityMask(), SetProcessAffinityMask(), etc ...

So, Details und weitere Info's in den über mir verlinkten Links..

[negaH]

Naja, das ist nicht so trivial wie es sich anhört.

Ich messe ja nicht mit QueryPerformanceCounter() sondern die CPU Takte mit RDTSC -> Time Stamp Counter.

Das sieht dann ungefähr so aus:

1.) Kalibration

- ermittelle die RDTSC Takte für eine beliebige Zeitdauer X (zb. 10ms)
- ermittelle parallel dazu mit QueryPerrformanceCounter() einen Start und Stop Wert
- man hat nun 2 Differenzwerte: 1.) Anzahl der CPU Takte der Messschleife und 2. Anzhal der Takte relativ zu PerformanceFrequency()
- am Schluß kann man mit RDTSC_Takte / Performance_Takte * Peormance_Frequency also die Taktfrequenz der CPU ermitteln.
- dieser Wert wird global gespeichert

2.) Messung

- lese Time Stamp Counter mit RDTSC
- führe zu messende Funktionen aus
- lese Time Stamp Counter mit RDTSC und bilde Differenz, also die Anzhal der CPU Takte der ausgemessenen Funktion

3.) Umrechnung
- dividiere obige errechnete CPU_Frequency durch RDTSC_Takt_Anzhal_gemessen und je nach gewünschter Zeitskale multpliziere es zb. mit 1000 um Millisekunden zu haben

Dh. alle meine Messungen messen nur die CPU Takte aus und rechnen das am Schluß erst auf Zeit um.

Wenn aber die Taktfrequenz einer CPU nicht mehr konstant ist, also variabel mit der Zeit durch das ACPI angepasst werden kann, dann gibt es keinen Weg irgendwelche genaue Messungen durchzuführen, zumnindestens mit dem Time Stamp Counter.

Schätze mal das GetTickCount() wirklich die einzigste Alternative ist, der Time Stamp Counter ist auf alle Fälle unbrauchbar geworden.

Gruß Hagen

[Amateurprofi]

Hallo Hagen,

ich benutze zum Zeitmessen auch nur RDTSC, und die Kalibrierung mache ich auch so wie Du.
Allerdings habe ich bemerkt, daß bei sehr kurzen Kalibrierungszeiten (Du erwähntest 10 ms) die Ergebnisse (RDTSC-Ticks/Sekunde) weit weg waren von der "tatsächlichen" Frequenz. Als optimale Zeitspanne habe ich 200 ms gefunden.

Delphi-Quellcode:

FUNCTION TimeStamp:Int64;
asm
   rdtsc
end;

FUNCTION TimeStampFrequency:int64;
var oldpriority:word;  q0,q1,qf,ts0,ts1:int64; seconds:extended;
begin
   oldpriority:=GetThreadPriority(GetCurrentThread);
   SetThreadPriority(GetCurrentThread,THREAD_PRIORITY_TIME_CRITICAL);
   QueryPerformanceCounter(q0);
   ts0:=TimeStamp;
   Sleep(200);
   ts1:=TimeStamp;
   QueryPerformanceCounter(q1);
   SetThreadPriority(GetCurrentThread,oldpriority);
   QueryPerformanceFrequency(qf);
   seconds:=(q1-q0)/qf;
   result:=Trunc((ts1-ts0)/seconds+0.5);
end;

[marabu]

Hallo Hagen,

es gibt einen interessanten Artikel von Chuck Walbourn im MSDN zu diesem Thema: Game Timing and Multicore Processors.

Grüße vom marabu

[negaH]

@Klaus:

Zitat:

....der "tatsächlichen" Frequenz. Als optimale Zeitspanne habe ich 200 ms gefunden.

Das lässt sich exakt ausrechnen. Die minimale Zeitspanne der "Zeitschleife" sollte min 2 mal so groß sein das wir alle Takte der Refrerenzfrequenz abgearbeitet haben. In unserem Falle also QueryPerformanceFrequency() * 2. Wenn diese Funktion intern auf die Time Stamp Counter geht sollte man also ca. 2 Sekunden warten, da diese Funktion ja dann die CPU Frequenz in Hz angibt und das ist auf 1 Sekunde bezogen. Der Faktor 2 erklärt sich auf Grund des Nyquist Theorems, das auch auf unseren Kalibrierungsprozess wirkt. Sollte QueryPerformanceFrequency() aber wie auf meinem P4 nur ca. 3.6MHz groß sein, die CPU aber mit 1500MHz getaktet werden , so sollte man ca. 3.6 / 1500 * 2 = 4.8 Millisekundewn lang messen. Länger macht keinen Sinn da die maximale Genauigkeit damit schon erreicht wurde.

Da wir ja mit RDTSC und QueryPerformaceCounter() in parallel messen und beide Timer unabhängig vom BIOS, OS usw. laufen sollten (auf SingleCPU ohne ACPI ist das noch korrekt) müssen wir uns um die Thread/Process Prioritäten, dem Tasksheduller usw. überhaupt nicht kümmern. Denn die Wartezeit im Sleep(xyz) könnnte nur größer werden aber niemals kürzer als die minimale Zeit die wir ja vorgeben. Und ansonsten benötigen wir das Sleep() ja eben nicht direkt für unsere Messung, eine Schleife mit GetTickCount() oder sonstwas anderes was minimal QueryPerformanceFrequency() *2 lang andauert hätte es auch getan.

Ergo: ob du im Sleep() 10ms oder 200ms angibts ist auf Grund der differientiellen Kalibrierungsmethode irrelevant. Wir benötigen das Sleep() ja nur damit unserer beiden Timer eine minimale Zeitspanne von > 5ms bekommmen.
Die Prioritäten des Prozesses/Threads zu erhöhen ist Quatsch und verändert garnichts, da wir ja eben eine Differientielle Kalibrierung mit zwei vom OS unabhängigen Timern machen.

So, aber wie es sich nun herausstellt gilt auf neuerer Hardware folgendes:

1.) RDTSC ist abhängig vom CPU Takt und dieser kann fließend und variabel in der Zeitachse durch das Power Management System ACPI einestellt werden. Gerade auf Laptops der Fall.

2.) die PerformanceCounter() benutzen selber RDTSC, sehr ungünstig für unsere Kalibrierung

3.) auf Multiprozessoren können die CPUs unterschiedliche im Takt eingestellt werden was dazu führt das die RDTSC Counter sogar asynchron zueinander sind, jeder CPU Kern hat ja einen eigenen RDTSC und auch Takt

4.) das Windows OS benutzt in QueryPerformanceCounter() die RDTSC und während einer Messung kann die Affinitäten eines Threads zu der CPU sich ändern. Dh. dieser Thread wird teilweise auf der 1. CPU und später auf der 2. CPU ausgeführt. Das Windows OS API für QueryPerformanceCounter() benutzt aber immer nur die RDTSC Counter der zum Aufruf der API Funktion gültigen CPU zum Thread. Das Windows API ist in diesem Falle also eine Fehlkonstruktion.

Ergo beides, RDTSC und QueryPerformanceCounter() sind aus ganz unterschiedlichen Gründen absolut untauglich geworden, sie sind eben nicht mehr unabhängige Timer vom OS/BIOS etc.pp. Eine korrekte Berechnung einer Messschleife benötigt eine Formel die gleich mindestens 3 variable Unbekannte involviert. Diese 3 Unbekannten sind auf der Zeitachse veränderlich und sind

1.) unterschiedlicher CPU Takt der einzelnen CPU Kerne, die RDTSC laufen unterschiedlich schnell
2.) QueryPerfromanceCounter() benutzt selber RDTSC, nicht mehr den Timer Chip des BIOS
3.) der Tasksheduller bzw. die Affinitäten der Threads zu verschiedenen CPUs

Diese Formel dürfte ohne klare Unterstützung der CPU, BIOS, OS Hersteller nicht zu lösen sein. Das Microsoft das Problem auf die CPU/BIOS Hersteller abschiebt ist ebenfalls nicht korrekt.

Ich baue alle meine Routinen auf GetTickCount() um, da weis ich was ich habe. Die Lösung von MS oder BIOS muß es sein einen hochauflösenden externen Timer als API zur Verfügung zu stellen. Dieser Timer muß eine Absolutzeit zurückgeben, denn was nützt uns eine "Zeitmessung" deren Takt sich variabel verändert ?! Das ist hirnrissig.

Gruß Hagen

[negaH]

Es ergeben sich aber auch andere Vorteile bzw. Möglichkeiten ;)

Man kann RDTSC dazu benutzten um die RMS Auslastung der CPUs zu messen. Auf meinem Laptop zb. ergaben sich für die gleiche zu messende Funktion folgende Zeiten

1.) 12 sec
2.) 4 sec

Das zeigt uns das die 2. Messung auf einer CPU lief die 3 mal schneller getaktet wurde als bei der 1. Messung. Man könnte also eine TrayIcon APP bauen die für jede CPU die aktuelle Taktfrequenz anzeigt. Nun kann man dies PI*Daumen umrechnen in Stromverbrauch, denn bei CMOS ist es so das quasi nur die Taktfrequenz die Stromaufnahme bestimmt.

Gruß Hagen

PS: Marabu, danke für den Link, ich hätte mir mein Palaver oben sparen könne ;)

[Olli]

Wenn du keine Gleitkomma-Ops benutzt, kannste deine Berechnung ja in den Kernelmode verlegen und bei gehaltenem Spinlock (nicht auf Checked Versions machen ;)) tätigen. Das System reagiert dann zwar solange nicht mehr, bis die Berechnung fertig ist und sie läuft auch nur auf einer CPU, aber ansonsten ist alles fit. Ach ja ... wenn du den FPU-Status vorher sicherst, kannste natürlich auch mit FPU-Ops "rummachen" :mrgreen: :zwinker: :angel2:

[Amateurprofi]

@Hagen

Zitat:

Sollte QueryPerformanceFrequency() aber wie auf meinem P4 nur ca. 3.6MHz groß sein, die CPU aber mit 1500MHz getaktet werden , so sollte man ca. 3.6 / 1500 * 2 = 4.8 Millisekundewn lang messen. Länger macht keinen Sinn da die maximale Genauigkeit damit schon erreicht wurde.

Hagen,
ja du hast Recht. Habs noch mal geprüft mit SleepTimes von 5 ms um 5 steigend bis 200.
Die Differenzen sind vernachlässigbar.
Da hab ich wohl seinerzeit irgendwie verrannt.

[negaH]

Die einzigste zeitkritische Operation ist wenn man RDTSC und QueryPerformanceCounter aufruft. Sollte exakt dazwischen ein Taskswitch auftreten haben wir eine Messungenauigkeit. Man könnte das mit einer höheren Threadpriorität versuchen, ist aber im Grunde sinnlos ;) Der Taskswitch könnte ja zu einem ähnlich priorisiertem Task erfolgen, ergo mit höherer Priorität verhindert man nicht den Switch.

Clever ist es einfach vor diesen beiden Aufrufen ein Sleep(0) aufzurufen. Man erzwingt also einen frühzeitgen Taskswitch wenn einer ansteht und nach dem Sleep() ist die Wahrscheinlichkeit enorm hoch das unser Thread erstmal eine minimale Zeitscheibe von ca. 20ms zur Verfügung hat.

In meinem Code verzichte ich also auf Threadprioritäten usw., benutzte nur ein Sleep(0) vor dem Aufruf von RDTSC und QPC, und mache diese Berechnungen exakt 3 mal nacheinander, bzw. so lange bis bei den letzten 3 Messungen mindestens 2 identische Resultate liefern.

Denn im Grunde müsste man wirklich in den Kernelmodus um per CLI/STI auch IRQs unterdrücken zu können. wie's Olliver schon sagte.

Gruß Hagen

[Olli]

Zitat:

Zitat von negaH

Die einzigste zeitkritische Operation ist wenn man RDTSC und QueryPerformanceCounter aufruft. Sollte exakt dazwischen ein Taskswitch auftreten haben wir eine Messungenauigkeit. Man könnte das mit einer höheren Threadpriorität versuchen, ist aber im Grunde sinnlos ;) Der Taskswitch könnte ja zu einem ähnlich priorisiertem Task erfolgen, ergo mit höherer Priorität verhindert man nicht den Switch.

Da kann dir der nächste "nette" Treiber schon ein Schnippchen schlagen. Die Threadprioritäten haben zwar zur Errechnung des Thread-Quantums eine Bewandnis, aber das juckt mal nen Treiber oder dessen DPC oder ISR garnix. Dein Usermode-Code läuft eben mal nur auf IRQL PASSIVE_LEVEL und im Falle eines APCs ein Level höher, aber diese beiden sind, wie man so schön sagt, unterbrechbar. Kommt also Code mit einem höheren IRQL (nicht verwechseln mit IRQs!!!), wird dein Code mal eben angehalten bis der andere fertig hat :mrgreen:
(Das wären bspw. Geräte-IRQLs - auch nicht zu verwechseln mit IRQs - wo dann die ISRs - Interrupt Service Routines - laufen, siehe dein Kommentar zu CLI/STI.)

Zitat:

Zitat von negaH

Denn im Grunde müsste man wirklich in den Kernelmodus um per CLI/STI auch IRQs unterdrücken zu können. wie's Olliver schon sagte.

Naja, Spinlock halten reicht schon, weil da nix anderes in dem Moment "ran darf". Ist dann halt bloß auf einem Prozessor und du darfst keinen ausgelagerten Speicher "anfassen" - ansonsten sagt dir Windows im stilisch ansprechenden himmelblauen Look: KMODE_EXCEPTION_NOT_HANDLED oder KERNEL_MODE_EXCEPTION_NOT_HANDLED oder (am wahrscheinlichsten) der allseits beliebte IRQL_NOT_LESS_OR_EQUAL.

Nachtrag: Übrigens, wenn ich mal Zeit finde, könnten wir das mal versuchen. Mich interessiert das eigentlich mal von der Seite her inwieweit das machbar ist. Man könnte ja eine ISR für die Tastatur einrichten, die dann den Treiber ggf. unterbrechen darf.

[supermuckl]

könnte man denn (jetzt mal von der highskilligen geschichte abgesehen) eine einfachere klasse erstellen, die ansatzweise genauer ist, als die gettickcount methode ?

also mit queryperformance timers, die dann halt wie schon hagen sagt, 3 mal hintereinander kalibriert werden und das beste genommen wird mit sleep(0) davor damit der prozess net auf nem anderen kern geswitcht wird, solange gecountet wird

geht das?

ich hab da net so viel plan von, bräuchte aber auch eine relativ genaue zeitmessung.

ich hab nen proggi, das pings checken soll (und das auch bei multikern-prozessoren ansatzweise genau gehen soll und nicht andauernd 4er pings anzeigen soll, obwol minimal 10 drin sind oder sogar negative werte ;)

könnte da mal jemand ran gehen?? wäre echt extrem hilfreich.

[negaH]

QueryPerformanceCounter() ist absolut exakt, laut Microsoft, wenn die dummen BIOS Programmierer nichts falsch gemacht haben. Aber was interessiert mich das BIOS wenn ich als Programmierer das Microsoft API benutze.

Man kann die Auflösung von GetTickCount() ins Unendliche erhöhen, man muß nur unendlich viele Messungen durchführen, deren Resultate akkumulieren und damit einen Mittelwert berechnen. Das geht defakto mit jedem Messverfahren.
Praktisch gesehen ist das aber alles Theorie denn wir haben nicht unendlich viel Zeit.

Nein, meiner Meinung nach ist es Aufgabe jedes OS eine relativ genaue Zeitbasis zur Verfügung zu stellen. Aber exakt das ist mit den neueren CPUs/BIOSen/OSen wohl nicht mehr gegeben.

Ich habe meine Routinen auf GetTickCount() umgeschrieben, da mir im Grunde dessen Auflösung fast ausreicht. Man muß halt dann sehr schnelle Routinen mehrfach ausmessen und den GetTickCount() Wert eben nach der Berechnung dividieren.

Davon abgesehen wird man sich, selbst mit einer höchstgenauen Zeitbasis, die Frage gefallen lassen müssen, wie effektiv genau nun die gemessenen Werte sein können, wenn Treiber, Taskmanagement etc.pp. sowieso diese Messungen verfälschen werden.

Anders ausgedrückt: wie Olli es schon andeutete bekommen wir nur dann eine exakte Messung mit einer hochgenauen Zeitbasis, wenn wir sicherstellen können das die auszumessende Funktion auch wirklich die einzigste Funktion ist die wir ausmessen. Das können wir nur wenn wir alle OS/BIOS/Hardware Funktionen die dazwischen funken könnten, deaktivieren. Es reicht also noch nichtmal wenn wir unsere Funktion auf Ring0 mit höchster Priorität ausführen, denn die Hardware mit ihren intelligenten Sub-Controlern (Noth/South Brige, USB, DMA, Speicher, Cache usw. usf.) wird auch dazwischen funken.

Wenn wir das alles geschafft haben auszuschalten, dann bleibt das Problem der CPUs. Denn heutige CPUs sind unberechenbar in ihren Taktzyklen die sie benötigen für den Machinencode. Es ist eben nicht mehr so das ein OpCode wie ADD EAX,EAX exakt X Takte benötigt, sondern je nach Pipline/Cache etc. Status kann dies stark variieren.


@Oliver:
Ja, interessant wäre es durchaus mal sowas zu programmieren. ABER! es verstösst dann gegen meine jetzige Grundregel -> "vermeide unnötigen Streß in der Programmierng indem du den Mist der anderen Coder nicht versuchst besser zu machen !"
Besonders weil man Jahre damit verbringen kann, und in diesen Jahren haben diese Coder/Marketingleute schon wieder 5 neuere Systeme auf den Markt gebracht. Man kommt, ob man es will oder nicht, also immer in Verzug, und rennt diesen "aktuellen Trends und Modeerscheinungen" quasi immer mehr hinterher.

Ergo: interessant wäre es, aber es ist Zeitverschendung aus meiner Sicht.

[edit]
Man könnte also mit QueryPerformanceCounter() eine bessere Genauigkeit als GetTickCount() erreichen, das ist fakt. Die Frage ist nur wie unserere "Komponnente" den WorstCase (Fall, ups doppelt gemoppelt) das der QPC falsche Werte liefert, detektieren kann. In diesem Moment müsste unserere "Komponente" das erkennen können und auf einen anderen Timer ausweichen. Leider gibt es eben keinen exakten Weg genau das zu machen. Eine Sache wie mit GetTickCount() den QPC zu verfizieren ist für mich eine grauenhafte Vorstellung, man kann den Teufel nicht mit dem Belzebub austreiben ;)
Ergo: gehe ich pragmatisch vor, GetTickCount(), und mehr geht nicht.
[/edit]

Gruß Hagen

[supermuckl]

hmm klingt alles logisch aber ich will doch mal meine probleme darstellen, die ich bekommen würde, wenn ich getickcount in meinem projekt verwenden würde:
Hmm klingt alles logisch, aber ich woll doch mal meine Probleme darstellen, die ich bekommen würde, wenn ich GetTickcount in meinem Projekt verwenden würde, anstatt das mit dem QueryPerformanceCounter Dingens zu berechnen:

Also es geht um das Programm "miniAdmin2", das einen Client für Call of Duty Server für die "Newbies" und "Admins" sein soll.
Es ist ziemlich belieb in der Community und deshalb bemühe ich mich auch im Vorfeld, "Falschanzeigen" im Programm zu vermeiden.
Und da sind wir auch schon beim Problem.
Die Server, die ich da anlegen kann, werden tabellarisch dargestell und erhalten in der Spalte "Ping" immer den aktuellen Ping, vom User zum Server, der sich jede Sekunde akualisiert.

Wenn ich jetzt jetzt die Methode "PerformanceCounter" benutze, sind die Pings in ihrer Auflösung etwa millisekundengenau, was schonmal ziemlich gut aussieht.
Allerdings muss ich, wie gesagt, negative Werte rausfiltern und damit leben, das mir der Ping ab und zu, zu wenig anzeigt.
Zum Beispiel hat ein Server einen Ping von durchschnittlich 15ms und dann auf einmal 4ms und weniger ;)
Das verwirrt die User eventuell total und dann gibts Fragen über Fragen....

Wenn ich jezt die Methode "GetTickCount" benutze, sind die negativen Werte nicht vorhanden und die Pings sind annähernd real.
Allerdings ist die Zeitauflösung je nach Windows und PC etwas grob, was zu pings von 0 oder 16 oder sonstigen "eingerasteten" Messwerten führt.
Damit kann ich also noch weniger leben, da die Server dann sehr unreale Pings haben (obwohl das schon näher hinkommt)
aber wenn ich jetzt 10 Serve untereinander habe und 5 davon immer den gleichen Ping haben ( z.b. alle 16ms) dann sieht das ziemlich blöd aus ;)
Was ich jetzt machen könnte, ist einen Pauschalwert vom Ping abziehen und noch nen gerundeten Wert von 1-2 ms dazu addieren. Das wäre dann schöne Statistikfälschung, sieht aber geil aus *g*

Ich hoffe ihr wisst jetzt was ich meine und ob man was dagegen tun kann weis ich leider nicht ;)

[Daniel]

Wenn ich das richtig sehe, hast Du einzelne Ausreißer nach oben oder unten. Das ist doch kein echtes Problem, zeige einfach den Mittelwert der letzten 4-5 Pings an und Du bist das Problem los. Du kannst Dir dann noch ein Intervall definieren an Werten, die Deinem Ermessen nach im "grünen" Bereich liegen und alle Werte, die nicht darin ligen, klassifizierst Du als Ausreißer und nimmst sie mit schwächerem Gewicht in die Wertung ein.

Gerade was Pings angeht, kommt dieser Wert in meinen Augen der Realität schon etwas näher, weil ein einzeler Ping alleine für sich genommen naturgemäß schwankt.

Nur: Wenn Dir Millisekunden reichen ... warum nimmst Du dann nicht GetTickCount() ? Dann hast Du einen Zähler am Wickel, der nichts mit CPU und BIOS zutun hat - zumindest nicht so direkt, wie dies hier mit den anderen Methoden der Fall ist.

[xaromz]

Hallo,

Zitat:

Zitat von Daniel

Nur: Wenn Dir Millisekunden reichen ... warum nimmst Du dann nicht GetTickCount() ? Dann hast Du einen Zähler am Wickel, der nichts mit CPU und BIOS zutun hat - zumindest nicht so direkt, wie dies hier mit den anderen Methoden der Fall ist.

Vermutlich, weil GetTickCount, wie er oben schrieb, eine geringere Auflösung hat, als Millisekunden.

Gruß
xaromz

[supermuckl]

Dann scheint wohl die einzige Möglichkeit, einen Mittelwert über 5 Pings zu ziehen :/

Eigentlich sollten dann aber auch andere Programme, die solche Zeitabstände messen, probleme haben ?!
Ist es noch irgendjemand anderst aufgefallen bei irgend einem Programm?

[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/