Elapsed Time gequantelt?

' schrieb:Ich kann das Bsp. nicht öffnen, (ev. gehe ich von was falschem aus) aber was hier geschrieben wird kann ich nicht so glauben.

Warum geht den das (siehe Bild)?

Kein Ahnung. Gegenfrage: Warum sind diese 15,625 ms (1/64 s) Stufen hier da? Das Vi kannst Du schnell nachbauen. Ich kann Dir aber alles auch in jeder gewünschten Version konvertieren.
Gruß Ludwig
   

Edit: Bei mir reagiert dein Beispiel ganz anders. Mit diesem VI
   
erhalte ich je 10 mal starten ca. 9 mal das Ergebnis Null und einmal 16.625ms. Ich habe Windows XP SP3 und einen Athlon-Prozessoer mit nur 1 Kern. Was verwendest Du? Und verwendest Du auch?

Anzeige

' schrieb:Kein Ahnung. Gegenfrage: Warum sind diese 15,625 ms (1/64 s) Stufen hier da? Das Vi kannst Du schnell nachbauen. Ich kann Dir aber alles auch in jeder gewünschten Version konvertieren.
Gruß Ludwig
[attachment=41939:elapsed4.png]

Edit: Bei mir reagiert dein Beispiel ganz anders. Mit diesem VI
[attachment=41941:elapsed5.png]
erhalte ich je 10 mal starten ca. 9 mal das Ergebnis Null und einmal 16.625ms. Ich habe Windows XP SP3 und einen Athlon-Prozessoer mit nur 1 Kern. Was verwendest Du?

Mit einem WAIT = 0ms oder (Wait until..) in der Schlaufe sieht das schon anders aus.

Ich habe mein Bsp. mal in eine Schlaufe 10000 gemacht und es dauert 10 sek., oder eben 1ms pro durchlauf, wie erwartet.
Zu meinem Rechner, der ist relativ schnell, Intel Core2 Duo 2,33GHz mit Vista Business.

EDIT: Hab es mal auf meinem alten Rechner (P4 1,8 GHz Win2000) gemacht, dort verhält es sich in etwa so wie du (Lucki) beschrieben hast.

Jetzt schreib ich aber schnell diesen Posting FERTIG - bevor der Server wieder zwischendrinnen abstürzt.

' schrieb:Dann gibt es GetTickCount, der auf ms genau ist.

Und wenn ihr mich steinigt, ich beschwöre, dass ich schon mit GetTickCount in Delphi gearbeitet habe, der auf 1ms genau aufgelöst hat.

Jetzt hab ich nochmals nachgekuckt: Betriebssystem ist WinXP SP3. Hier hat der GetTickCount eine Auflösung von 15.650 ms. Der Befehl GetTickCount an sich geht sehr schnell: Springen in Kernel32.dll und dort lediglich 5 Befehle (einschließlich ret) ausführen. Der Befehl GetLocalTime jedoch, der 100ns auflösen kann, macht dagegen tausende von Befehlen (z.B. in ntdll.RltExtendedmagicDevide).

Das Problem bei GetTickCount: Da wird eine Speicherzelle, nämlich die, die mit den 5 Befehlen ausgelesen wird, hochgezählt. Und zwar im Raster wie in GetSystemTimeAdjustment steht. Da steht bei mir aktuell halt 156250 - und 156250*100ns ergibt diese obinösen 15.6250ms.

Früher unter DOS gab es einen Timerinterrupt, der alle 18 (oder doch 15) Millisekunden kam.

' schrieb:Jetzt hab ich nochmals nachgekuckt: Betriebssystem ist WinXP SP3. Hier hat der GetTickCount eine Auflösung von 15.650 ms.

Das stimmt mit meinen Ergebnissen überein. Wenn ich allerdings die Funktione GetSystemTimeAdjustment aufrufe, kommt ein anderer Wert heraus:
   

Allerdings weiß ich auch woran das liegt: Mein Sachwissen über den Aufruf externer Bibliotheken ist sehr "überschaubar". Könntest Du bitte mal beim angehängten VI nachsehen, was ich das falsch mache?

  TestDLL.vi (Größe: 29,69 KB / Downloads: 163)

' schrieb:Könntest Du bitte mal beim angehängten VI nachsehen, was ich das falsch mache?

Heute abend.

Mach mal aus allen Typen (Rückgabewert + Parameter) U32. DWord ist ein Doppel-Wort, also 2*16Bit. Boolsches wird auch als U32 gehandhabt.

Schnell bevor der Server wieder weg geht:

' schrieb:Mach mal aus allen Typen (Rückgabewert + Parameter) U32. DWord ist ein Doppel-Wort, also 2*16Bit. Boolsches wird auch als U32 gehandhabt.

Deine Werte kommen daher, weil die tatsächliche Zahl größer ist als 65535 und somit nicht mehr in 16Bit passt. Sie wird praktisch abgeschnitten auf 16Bit.

Anzeige

' schrieb:Schnell bevor der Server wieder weg geht:
Deine Werte kommen daher, weil die tatsächliche Zahl größer ist als 65535 und somit nicht mehr in 16Bit passt. Sie wird praktisch abgeschnitten auf 16Bit.

Danke, das hat funktioniert. Damit sich niemand wundert: Habe oben das VI verbessert, so daß das Problem jetzt gar nicht mehr existiert
Es wäre gut, wenn auch Andere das VI mal laufen ließen. Vielleicht gibt es auch kleinere Quantensprünge als diese 15.625 ms.

' schrieb:Es wäre gut, wenn auch Andere das VI mal laufen ließen. Vielleicht gibt es auch kleinere Quantensprünge als diese 15.625 ms.

Ich komme auf 156002 bei lpTimeAdjustment.

' schrieb:Vielleicht gibt es auch kleinere Quantensprünge als diese 15.625 ms.

15.625 ms unter WinXP auf AMD Athlon System.

Bei mir sind's auch 15,625 ms (Intel Pentium D mit Windows XP)

Gruß Markus

' schrieb:15.625 ms unter WinXP auf AMD Athlon System.