Opened 5 years ago

Last modified 5 years ago

#598 assigned enhancement

DosTmrQueryTime inaccuracy

Reported by: dmik Owned by: dazarewicz
Priority: minor Milestone: Release 3.22
Component: ACPI PSD Version: 3.22.03
Keywords: Cc:


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:

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 5 years ago by dmik

Note that there is a corresponding Firefox issue here: It contains more additional information.

comment:2 Changed 5 years ago by dazarewicz

  • Milestone changed from Release Version 4.0.0 to Release 3.22
  • Owner set to dazarewicz
  • Priority changed from major to minor
  • Status changed from new to assigned
  • Type changed from defect to 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 5 years ago by dmik

  • Type changed from enhancement to defect

Great. Looking forward to give it a try.

comment:4 Changed 5 years ago by dazarewicz

  • Type changed from defect to 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.

Last edited 5 years ago by dazarewicz (previous) (diff)

comment:5 Changed 5 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 5 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 5 years ago by diver (previous) (diff)
Note: See TracTickets for help on using tickets.