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 dmik

Note that there is a corresponding Firefox issue here: https://github.com/bitwiseworks/mozilla-os2/issues/19. It contains more additional information.

comment:2 Changed 10 years ago by David Azarewicz

Milestone: Release Version 4.0.0Release 3.22
Owner: set to David Azarewicz
Priority: majorminor
Status: newassigned
Type: defectenhancement

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 dmik

Type: enhancementdefect

Great. Looking forward to give it a try.

comment:4 Changed 10 years ago by David Azarewicz

Type: defectenhancement

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.

Last edited 10 years ago by David Azarewicz (previous) (diff)

comment:5 Changed 10 years ago by dmik

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 diver

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.

Last edited 9 years ago by diver (previous) (diff)
Note: See TracTickets for help on using tickets.