On 21/04/2022 22:58, Eli Zaretskii wrote:
Date: Thu, 21 Apr 2022 22:30:21 +0700
From: Max Nikulin
Eli Zaretskii, Wed, 20 Apr 2022 22:30:21
I see the time samples change in jumps of 15 msec. Which is expected
on MS-Windows, given the scheduler time tick,
Why do you expect such value?
It is a well-known fact that the system timer tick happens 64 times a
second on MS-Windows.
You may notice similar coarse scheduler timer on Linux as well. General
purpose PC nowadays may have higher scheduler frequency, but I saw a
case when usleep(1) caused 20ms pause while there was no problem to get
higher precision form system clock.
Clock resolution generally has a little common with timers.
I agree, but that's something you should tell/ask Paul, not myself.
It may be deeper, e.g. additional call during initialization or extra
privileges may be required.
I have no experience with windows-specific code, but quick search gives
GetSystemTimePreciseAsFileTime that should provide timestamps with fine
granularity
https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimepreciseasfiletime
That API exists only since Windows 8.
I suspect that it means just that MS does not support anything prior to
Windows 8 any more. XP is mentioned in connection to this function:
https://www.lochan.org/2005/keith-cl/useful/win32time.html
Writing about possible intentional hiding of high precision clock I was
assuming latest windows versions, I believe, even Windows 8 is too old
for such modern tricks.
More importantly the Gnulib
implementation of current_timespec doesn't use it.
Even if it is not used yet, is it intentional design decision or just an
issue that should be fixed? I am unsure what function
clock_gettime/timespec_get/gettimeofday is actually used on windows
platform and how it is implemented.
It seems, only coarse clock is currently available in Emacs on Windows
due to usage of current_timespec. Are there any known problem with 16ms
resolution?
