https://bugs.winehq.org/show_bug.cgi?id=51857
Bug ID: 51857 Summary: Support Configurable Time measurement precision for Wine versions 5.0.x and onwards Product: Wine Version: 5.0.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: ishinberg0@gmail.com Distribution: ---
`NtQuerySystemTime` used to provide timestamp value by calling `gettimeofday`, at least on wine 4.0.x. This would provide micro-second accuracy for timestamping used in logging,tracing, etc
On Wine 5.0.x and 6.0.x, optimizations were introduced to provide near-realtime timestamp, relying on HAVE_CLOCK_GETTIME (which is always defined during the `configure` phase of the wine build).
This results in milliseconds accuracy (though the resolution is still in microseconds, it only gets updated around once every 1 ms / 1000 us.
This is not optimal for application requiring us precision for timestamp measurement.
If this suggestion is approved, I'd be willing to contribute a PR/fix for this issue. I also need this fix backported to 6.0.x, if possible
10x
https://bugs.winehq.org/show_bug.cgi?id=51857
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #1 from joaopa jeremielapuree@yahoo.fr --- If this problem breaks a real application, surely your patch will be welcomed in wine-patches :D
https://bugs.winehq.org/show_bug.cgi?id=51857
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #2 from Zebediah Figura z.figura12@gmail.com --- If you want a higher-precision timestamp, you should be using QueryPerformanceCounter(), not GetSystemTimeAsFileTime/NtQuerySystemTime. The latter only has 1 ms resolution on Windows either.
https://bugs.winehq.org/show_bug.cgi?id=51857
--- Comment #3 from Idan Sheinberg ishinberg0@gmail.com --- (In reply to Zebediah Figura from comment #2)
If you want a higher-precision timestamp, you should be using QueryPerformanceCounter(), not GetSystemTimeAsFileTime/NtQuerySystemTime. The latter only has 1 ms resolution on Windows either.
I'm running a JVM installation on top of Wine (mandatory, don't ask) so this is out of my control.
https://bugs.winehq.org/show_bug.cgi?id=51857
--- Comment #4 from Idan Sheinberg ishinberg0@gmail.com --- (In reply to joaopa from comment #1)
If this problem breaks a real application, surely your patch will be welcomed in wine-patches :D
I have no problem submitting patch (I even wrote and RPM patch to revert that specific change in my custom built wine 6.0.1 RPM). I'm just wondering what's the best way to tackle this issue.
Ideally, it would be an environment variable, something like WINE_CLOCK_USE_GETTIMEOFDDAY. When set (during run, NOT during the build), NtDLL will not revert to the old behavior and will not optimize clock access.
Where should I even purpose such a behavior? It doesn't feel like patch but more of a feature.
https://bugs.winehq.org/show_bug.cgi?id=51857
--- Comment #5 from Zebediah Figura z.figura12@gmail.com --- It's going to be a hard sell to include anything like that upstream. The whole point of having multiple clock sources is that there's a tradeoff between measurement speed and clock resolution. Our current behaviour matches Windows, and there would be a performance penalty associated with using a higher-resolution clock source for NtQuerySystemTime.
Typically we don't include such optional behaviour, either. What little configuration there is in Wine is usually for working around bugs or API mismatches. The maintenance cost would be too high otherwise. Is it feasible for you to use a local patch or shim instead?
https://bugs.winehq.org/show_bug.cgi?id=51857
--- Comment #6 from Idan Sheinberg ishinberg0@gmail.com --- (In reply to Zebediah Figura from comment #5)
It's going to be a hard sell to include anything like that upstream. The whole point of having multiple clock sources is that there's a tradeoff between measurement speed and clock resolution. Our current behaviour matches Windows, and there would be a performance penalty associated with using a higher-resolution clock source for NtQuerySystemTime.
Typically we don't include such optional behaviour, either. What little configuration there is in Wine is usually for working around bugs or API mismatches. The maintenance cost would be too high otherwise. Is it feasible for you to use a local patch or shim instead?
I understand what you are saying, and agree. We'll use a patch when building wine to revert this issue.
10x
Idan