115865 - PRInterval times incorrect on Windows XP Pro

Status: RESOLVED WONTFIX

(NSPR :: NSPR, defect, P2)

Description

[Chris Waterson]

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...

Warren


Subject:
Re: NSPR not up-to-date for XP?
From:
John Wainwright <[e-mail]>
Date:
Tue, 18 Dec 2001 08:18:12 -0800
To:
Warren Harris <[e-mail]>
CC:
[e-mail], [e-mail]

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.
 
John.
----- Original Message -----
From: Warren Harris
To: John Wainwright
Cc: [e-mail] ; [e-mail]
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?

Warren

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.

Comment 1

[Wan-Teh Chang]

This is a serious bug.  Unfortunately I don't have any XP Pro
system to try this on.  (I only have XP Home.)

Comment 2

[Wan-Teh Chang]

It seems that this is a known "behavior by design" of
QueryPerformanceCounter:

http://support.microsoft.com/support/kb/articles/Q274/3/23.asp

We may need to rewrite NSPR's interval timers based on
GetTickCount, which only has millisecond resolution.

Comment 3

[Wan-Teh Chang]

It seems that NSPR has the mistake described in
this Knowledge Base article:

http://support.microsoft.com/support/kb/articles/Q327/8/09.asp

void
_PR_MD_INTERVAL_INIT()
{
    LARGE_INTEGER count;

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

        _nt_ticksPerSec = count.LowPart;
        PR_ASSERT(_nt_ticksPerSec > PR_INTERVAL_MIN);
    } else
        _nt_ticksPerSec = -1;
}

Comment 4

[Wan-Teh Chang]

Upon closer inspection, I don't think we are affected
by the second problem even though the NSPR code is
incorrect.

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.

Comment 5

[Wan-Teh Chang]

Attachment: Assert the assumption our code relies on

Our code only uses the lower 32 bits of the result
of QueryPerformanceFrequency, so assert that the
higher 32 bits are all zeroes.

Comment 6

[Wan-Teh Chang]

I opened bug 176881 for the potential bug of
our code on processors running faster than 4 GHz.

Comment 7

[Wan-Teh Chang]

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:
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/queryperformancecounter.asp)

    Remarks
    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.  [...]

Comment 8

[Wan-Teh Chang]

Warren, you might want to try the patch in bug 176881.

Comment 9

[Wan-Teh Chang]

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
winmm.lib.

Comment 10

[Christophe Ravel]

The target milestone is already released. Resetting target milestone.

Comment 11

[WADA:World Anti-bad-Duping Agency]

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?

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

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.