Closed Bug 115865 Opened 23 years ago Closed 2 years ago

PRInterval times incorrect on Windows XP Pro


(NSPR :: NSPR, defect, P2)

Windows XP


(Not tracked)



(Reporter: waterson, Unassigned)




(1 file)

Warren writes:

We discovered a problem with XP Pro on Dell PowerEngine machines --
PRIntervalTimes can be off by a factor of 5 - 6 times. Just a heads up...


Re: NSPR not up-to-date for XP?
John Wainwright <>
Tue, 18 Dec 2001 08:18:12 -0800
Warren Harris <>

Warren, I have found only one reference to bad values from the high-peformance
counter system calls, on the MS support site, but it was for an old HP machine
on NT 4.0 and was apparently fixed in 2K.  
We should perhaps get another of the Dell server boxes (the problem machine is a
Dell PowerEdge) and install XP Pro on that as well.
Do you know if the NS browsers use PRIntervalTimes to compute downloads rates in
their progress dialogs?   If so, they should also be wrong, it might be
worthwhile seeing if that is also wrong.
----- Original Message -----
From: Warren Harris
To: John Wainwright
Cc: ;
Sent: Monday, December 17, 2001 6:26 PM
Subject: Re: NSPR not up-to-date for XP?

Hi John,

I got your message about this being an XP bug, or a problem with that particular
machine. I searched the mozilla bug database and couldn't find anything that
looked remotely relevant. Do we have another XP Pro machine that we can try this
on? Maybe I should install it on my laptop instead of 2000. We need more coverage.

Eric & Chris: What do you think? Is it worth me installing this on my main machine?


John Wainwright wrote:
Hi, Warren.  We have an odd bug on XP Pro (http://bugzilla/show_bug.cgi?id=4632)
that would be explained if the PRIntervalTimer in NSPR was wrong about the tick
count resolution of the OS timer it uses.   We currently see interval times
about 5x faster than they should be, though only on XP Pro (not XP Home)!   The
PRTime timer seems correct in all situations, and we can see the 5x discrepancy
in the debug logs - for example in one download, the log system time stamp said
200 seconds had elapsed, which accorded with wall-clock time, but the total
download time reported by the loading system said 44 seconds and we also see bit
rates in the staus windows that are 5x too fast. Is it easy to see if there are
NSPR fixes (or bugs reported) for this? John.
This is a serious bug.  Unfortunately I don't have any XP Pro
system to try this on.  (I only have XP Home.)
Priority: -- → P1
Target Milestone: --- → Future
Target Milestone: Future → 4.2
It seems that this is a known "behavior by design" of

We may need to rewrite NSPR's interval timers based on
GetTickCount, which only has millisecond resolution.
Target Milestone: 4.2 → 4.3
It seems that NSPR has the mistake described in
this Knowledge Base article:

    LARGE_INTEGER count;

    if (QueryPerformanceFrequency(&count)) {
        while(count.LowPart > PR_INTERVAL_MAX) {
            count.LowPart >>= 1;
            _nt_highMask = (_nt_highMask << 1)+1;

        _nt_ticksPerSec = count.LowPart;
        PR_ASSERT(_nt_ticksPerSec > PR_INTERVAL_MIN);
    } else
        _nt_ticksPerSec = -1;
Upon closer inspection, I don't think we are affected
by the second problem even though the NSPR code is

The NSPR code does incorrectly use only the lower 32 bits
of the result of QueryPerformanceFrequency but does not
use it as a signed integer.  (The 'LowPart' field of
LARGE_INTEGER is a DWORD, which is unsigned.)  Therefore,
we are not affected by this bug for CPU clock speeds up
to 2^32 Hz, which is roughly 4 GHz.  There are no Intel x86
CPUs at 4 GHz or faster right now.

So I think we are affected by the first problem.
Our code only uses the lower 32 bits of the result
of QueryPerformanceFrequency, so assert that the
higher 32 bits are all zeroes.
I opened bug 176881 for the potential bug of
our code on processors running faster than 4 GHz.
I just found a mention of a potential problem with
QueryPerformanceCounter on a multiprocessor machine.
This is a quote from the QueryPerformanceCounter
documentation in MSDN:

    On a multiprocessor machine, it should not matter which processor
    is called. However, you can get different results on different
    processors due to bugs in the BIOS or the HAL.  [...]
Warren, you might want to try the patch in bug 176881.
Priority: P1 → P2
My experiment on Windows XP Professional Service Pack 1
showed that GetTickCount() has a coarse resolution, and
timeGetTime() has a finer resolution.  This is consistent
with what the GetTickCount documentation says.  So if we
are going to ditch the performance counter code, we may
want to use timeGetTime() instead of GetTickCount().
Actually NSPR was using timeGetTime() before.  I changed
it to GetTickCount() so that we don't need to link with
QA Contact: wtchang → nspr
The target milestone is already released. Resetting target milestone.
Target Milestone: 4.3 → ---
Setting dependency to bug 363258 for ease of track.

Wan-Teh Chang, I think bug of HAL of Win was bypassed by bug 363258 successfully. Is it wrong?
Depends on: 363258

The bug assignee didn't login in Bugzilla in the last 7 months.
:KaiE, could you have a look please?
For more information, please visit auto_nag documentation.

Assignee: wtc → nobody
Flags: needinfo?(kaie)
Closed: 2 years ago
Flags: needinfo?(kaie)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.