2009-10-02 20 views

risposta

9

I sistemi operativi Windows per desktop non sono accurati al di sotto di 40 ms. Il sistema operativo semplicemente non è in tempo reale e pertanto presenta un jitter significativo non deterministico. Ciò significa che, sebbene possa riportare valori fino al millisecondo o anche più piccoli, non si può davvero contare su quei valori per essere veramente significativi. Quindi, anche se l'intervallo del timer viene impostato su un valore di qualche millisecondo, non è possibile fare affidamento sui tempi tra l'impostazione e l'attivazione per essere effettivamente ciò che hai detto di volere.

Aggiungete a questo fatto che l'intero framework su cui state lavorando non è deterministico (il GC potrebbe sospenderti e fare la raccolta duing nel momento in cui il Timer dovrebbe sparare) e vi ritroverete con carichi e carichi di rischio provando fare tutto ciò che è tempo critico

+0

Non è particolarmente critico; sto scrivendo un "processore virtuale" per un gioco di simulazione di robot che utilizza un timer per eseguire le istruzioni ad una velocità specificata e mi chiedo solo quanto in alto posso impostarlo. – RCIX

+1

Non vorrei provare ad andare più frequente di 1ms. Lo scheduler del sistema operativo non farà comunque nulla di più frequente di quello per la tua app. – ctacke

+0

Bene, grazie per le informazioni! – RCIX

2

System.Timers.Timer è strano. Usa un doppio come intervallo ma in effetti chiama Math.Ceiling su di esso e lancia il risultato come int da utilizzare con un System.Threading.Timer sottostante. La sua precisione teorica è quindi 1 ms e non è possibile specificare un intervallo che superi 2.147.483.647 ms. Data questa informazione, non so davvero perché venga usato un doppio come parametro dell'intervallo.

2

Un paio di anni fa ho trovato accurato circa 16ms ... ma purtroppo non ricordo i dettagli.

+4

Quello sarà 15.625 ms == 64Hz, la frequenza dell'orologio di sistema. –

1

Potete scoprirlo facilmente per voi stessi eseguendo un ciclo che campiona costantemente la durata del tempo risultante e controlla su quale granularità procede.

0

Ho confrontato System.Timers.Timer e System.Threading.Timer - entrambi forniscono errori sistematici intorno a 8,16 ms, in particolare su piccoli intervalli (1000,6000 ms). Ogni successiva chiamata della routine del timer si è verificata con un aumento dell'intervallo dalla prima chiamata. Ad esempio, il timer con un intervallo di 2000 ms scatta nel 2000, 4012, 6024, 8036, 10048 millisecondi e così via (i timestamp ottenuti da Environment.TickCount e Stopwatch.ElapsedTicks, danno entrambi gli stessi risultati).

0

La risoluzione del timer scende al regime 1ms senza molti sforzi di implementazione. Ho appena descritto il motivo della precisione double in this answer. Quando si configura un sistema da eseguire a 1024 interrupt al secondo (utilizzando l'API del timer multimediale) l'intervallo di tempo tra gli interrupt è 0,9765625 ms. La risoluzione standard per i tempi è di 100ns. Quei valori sono memorizzati come numeri interi. Il valore 0.9765625 non può essere memorizzato senza perdere la precisione in un numero intero con risoluzione di 100 ns. L'ultima cifra (5) rappresenta 500 ps. Quindi la risoluzione deve essere superiore di tre ordini di grandezza. La memorizzazione di questi valori di in numeri interi con una risoluzione di 100 ps è senza speranza poiché un numero intero di 8 byte con una risoluzione di 100 ps avvolgere afer circa 21350 giorni o circa 58 anni. Questo intervallo di tempo è troppo breve per essere accettato da chiunque (ricorda lo scenario Y2K!).

Vedere la risposta collegata per ulteriori informazioni sui dettagli.

Problemi correlati