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 <john@kontiki.com> Date: Tue, 18 Dec 2001 08:18:12 -0800 To: Warren Harris <wh232@pacbell.net> CC: eric@kontiki.com, chris@kontiki.com 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: eric@kontiki.com ; chris@kontiki.com 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.

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

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.

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; }

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.

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: (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. [...]

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

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.

The target milestone is already released. Resetting target milestone.

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?