Opened 10 years ago
Last modified 9 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 Changed 10 years ago by
comment:2 Changed 10 years ago by
Milestone: | Release Version 4.0.0 → Release 3.22 |
---|---|
Owner: | set to David Azarewicz |
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:3 Changed 10 years ago by
Type: | enhancement → defect |
---|
Great. Looking forward to give it a try.
comment:4 Changed 10 years ago by
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 Changed 10 years ago by
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 Changed 9 years ago by
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.