[Bug 51857] New: Support Configurable Time measurement precision for Wine versions 5.0.x and onwards
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(a)winehq.org Reporter: ishinberg0(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51857 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #1 from joaopa <jeremielapuree(a)yahoo.fr> --- If this problem breaks a real application, surely your patch will be welcomed in wine-patches :D -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51857 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #2 from Zebediah Figura <z.figura12(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51857 --- Comment #3 from Idan Sheinberg <ishinberg0(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51857 --- Comment #4 from Idan Sheinberg <ishinberg0(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51857 --- Comment #5 from Zebediah Figura <z.figura12(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51857 --- Comment #6 from Idan Sheinberg <ishinberg0(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla