Doom9's Forum - View Single Post

kassandro · 27th June 2003, 04:41

@Kurosu
The link to the new Kronos seems to be dead, but the link to the "old" Kronos is ok. Thanks!
I haven´t tested the "real" accuracy of any time function. Theoretically even the simple clock() function should have an accuracy of 1 ms. Using the RDTSC instruction hardwired in the cpu one could measure time with the accuracy of cpu cycles. On the hand -like the UNIX times sytem call - one could measure time by the number of timer interrupts. This is quite natural because the scheduler of the operating system is driven by the timer interrupt. Probably Windows has 100 timer interrupts per seconds, which results in an accuracy of 10 ms.
Being a mathematician by education (not by profession) I do not care much about the accuracy of a timer function as long as it is unbiased (equally wrong on the up and the down side). If one averages over a sufficiently large number of frames, the inaccuracy then simply disappears. Even with a very crude timer function with an accuracy of a 1 s one could measure a 100 fps filter accurately if one averages over, say, 10000 frames, though this seems to be strange because for most frames a duration of 0 s and for only a very few 1 s will be measured in this example.
It is much more important that the timer function excludes the time spent for other processes or threads, because this error cannot be averaged out. That´s why GetThreadTimes()is appropriate. It seems to retrieve its information directly from the scheduler. Hence the overhead of this function should be small. Because GetProcessTimes() uses an identical system interface I will allow also the optional usage of this function in the new version. This is useful if a filter uses several threads, which would be quite weird though.
I agree that one should merge the Kronos and Avstimer and users should decide about the features.

27th June 2003, 04:41	#10 \| Link
kassandro Registered User Join Date: May 2003 Location: Germany Posts: 502	@Kurosu The link to the new Kronos seems to be dead, but the link to the "old" Kronos is ok. Thanks! I haven´t tested the "real" accuracy of any time function. Theoretically even the simple clock() function should have an accuracy of 1 ms. Using the RDTSC instruction hardwired in the cpu one could measure time with the accuracy of cpu cycles. On the hand -like the UNIX times sytem call - one could measure time by the number of timer interrupts. This is quite natural because the scheduler of the operating system is driven by the timer interrupt. Probably Windows has 100 timer interrupts per seconds, which results in an accuracy of 10 ms. Being a mathematician by education (not by profession) I do not care much about the accuracy of a timer function as long as it is unbiased (equally wrong on the up and the down side). If one averages over a sufficiently large number of frames, the inaccuracy then simply disappears. Even with a very crude timer function with an accuracy of a 1 s one could measure a 100 fps filter accurately if one averages over, say, 10000 frames, though this seems to be strange because for most frames a duration of 0 s and for only a very few 1 s will be measured in this example. It is much more important that the timer function excludes the time spent for other processes or threads, because this error cannot be averaged out. That´s why GetThreadTimes()is appropriate. It seems to retrieve its information directly from the scheduler. Hence the overhead of this function should be small. Because GetProcessTimes() uses an identical system interface I will allow also the optional usage of this function in the new version. This is useful if a filter uses several threads, which would be quite weird though. I agree that one should merge the Kronos and Avstimer and users should decide about the features.