Opened 11 years ago
Last modified 10 years ago
#598 assigned enhancement
DosTmrQueryTime inaccuracy
| Reported by: | dmik | Owned by: | David Azarewicz |
|---|---|---|---|
| Priority: | minor | Milestone: | Release 3.22 |
| Component: | ACPI PSD | Version: | 3.22.03 |
| Keywords: | Cc: |
Description
There is a test case for Firefox that demonstrates inaccuracy in intervals when using the high resolution timer (enabled by removing NSPR_OS2_NO_HIRES_TIMER=1 from the environment) located here: http://ru2.halfos.ru/core/downloads/kernel/os4/Test/timerTest.html.
The test case simply fires up a repetitive 5s timer and then logs its output. Some results are weird: you can get intervals less than 5ms and some of them are 10 times less (as low as 529 ms). This is definitely not considered as normal. With NSPR_OS2_NO_HIRES_TIMER=1 all works fine: the intervals are never less than 5000ms and the bias is not more than +40ms (pretty much expected for the low resolution timer used in this case).
There was a similar ticket #589 but it described a simply different issue (hires timer breakage after suspend). This problem has nothing to do with suspend.
Change History (6)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
| Milestone: | Release Version 4.0.0 → Release 3.22 |
|---|---|
| Owner: | set to |
| Priority: | major → minor |
| Status: | new → assigned |
| Type: | defect → enhancement |
Several months ago I added an SMP safe query timer function to the PSD to replace the SMP unsafe one in the kernel. This should resolve this issue. Versions 3.22.04 and higher will have this enhancement. A new release should be available soon.
comment:4 by , 11 years ago
| Type: | defect → enhancement |
|---|
This issiue CAN NOT be a defect. There is not and never was anything broken in the PSD. It is an enhancement because a NEW FEATURE was added.
Furthermore, the attributes of a ticket are for the developer to track and organize the ticket. You should not change these if the developer has set them.
comment:5 by , 11 years ago
David, I am a developer too, no need to explain :) Sorry, I didn't mean to change it. It's a very nasty bug of either Trac or Safari WRT form auto-filling (I suspect the latter). It constantly sets it to whatever value was set when the form was submitted for the first time. Already seen it before and suffered from that in my own tickets. E.g. It would change it again to *defect* right now if I didn't catch its hand and manually change it back before submitting this comment.
comment:6 by , 10 years ago
David, could it be that this problem is still there with 3.22.06? At least in the mozilla ticket 19 (link is in comment 1) ppl say so.
Note that there is a corresponding Firefox issue here: https://github.com/bitwiseworks/mozilla-os2/issues/19. It contains more additional information.