Ce que tu cites dates un peu, les CPU de maintenant peuvent effectuer 2, 4 ou 8 instructions à la fois (dualcore, quadcore ou quadcore+hyperthreading comme le i7).
De plus, ton article parle d'un retard de 10 ms en moyenne, ce qui en vrai, c'est en fait la précision des timers sous Windows.
D'ailleurs, c'est de ça que parles cette article, qui est aussi valable pour la fonction Sleep() de Win32.
Les timers sous Windows sont gérés par interruptions (logicielles certes) mais reste à un niveau très bas.
Dans notre cas, et mes test le montre bien, le décalage n'est pas de 10 ms mais est proportionnel au temps du timer :
17 % dans le cas de ma machine au boulot (Core2 Duo 2.8 Ghz je crois)
17 % encore dans le cas de mon PC perso principal à la maison (Core2 Duo 3.16Ghz)
17 % encore dans le cas de mon deuxième PC perso (i7 920)
Je n'ai pas fait de tests sur un serveur Linux.
Les valeurs que tu montres sont conformes à ce que je trouve mais dans ton cas, la décalage est de 11 %.
Essaies le même test que celui que tu as fais avec 2 secondes puis 10 secondes pour ton timer, tu trouveras des valeurs de 2220 environs dans le premier cas et 11100 environs dans le second.
Voici un très court programme en C qui ressemble à celui de sazuke, il affiche le GetTickCount à chaque échéance du timer. Sa précision est impeccable si rien d'autre ne tourne et il y a un décalage de 10-15 ms lorsque je fait un "dir c: /s" en même temps, ce qui est conforme à l'article que tu cites (Je te conseille de l'essayer sazuke) :
#include <stdio.h>
#include <windows.h>
VOID CALLBACK MaFonctionTimer (HWND hwnd, UINT uMsg, UINT idEvent, DWORD dwTime)
{
/* Fonction nécessaire mais non utilisée */
}
void main (void )
{
HWND hwndTimer;
MSG msg;
if (SetTimer (NULL, 0, 1000, MaFonctionTimer)==0)
{
printf ("Impossible de creer le timer\n");
}
while (GetMessage(&msg, // message structure
NULL, // handle of window to receive the message
NULL, // lowest message to examine
NULL)) // highest message to examine
{
// Post WM_TIMER messages to the hwndTimer procedure.
if (msg.message == WM_TIMER)
{
msg.hwnd = hwndTimer;
printf ("GetTickCount = %d\n", GetTickCount ());
}
TranslateMessage(&msg); // translates virtual-key codes
DispatchMessage(&msg); // dispatches message to window
}
}
Ma conclusion c'est que la team SAMP a réécrit les timers de SAMP pour que le code soit portable entre Windows et Linux (pour qu'il soit plus facile à maintenir).
Mais en faisant ça, ils ont introduit un décalage proportionnel au temps du timer.
Et comme on ne sait pas comment ils ont écrit leurs timers, on ne peut faire que des suppositions sur la façon de contourner le problème.
++
Syg
Sujet: Timer imprécis. (Lu 3921 fois)
