P-IV Slower than P-III or windows Sleep(ing)?

**harisankar_r** · August 28th, 2003, 12:17 AM

I'm facing a problem in my application, which communicates with some device through serial port. At some poing, my application is transferring data (around 1KB) to the device. The same applicatoin takes more time when we run in P-IV machine. (OS - Win2K).

I first suspected serial driver and still I was not able to get any answer. Finally I found the problem is with Sleep call which I use in the transfer loop. It is like,

for(int i=0; i<1024; i++)
{
SerialClass.Write(Buffer[i], 1);
Sleep(1);
}

Then I tried to run the following program in both P-III and P-IV, which gives noticeable delay in P-IV.

// Performance.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include "Performance.h"
#include <conio.h>

#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

/////////////////////////////////////////////////////////////////////////////
// The one and only application object

CWinApp theApp;

using namespace std;

int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
int nRetCode = 0;

// initialize MFC and print and error on failure
if (!AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0))
{
// TODO: change error code to suit your needs
cerr << _T("Fatal Error: MFC initialization failed") << endl;
nRetCode = 1;
}
else
{
DWORD dwStart, dwEnd;

dwStart = GetTickCount();
for(int i=0; i<100; i++)
Sleep(1);

dwEnd = GetTickCount();

cout << (dwEnd-dwStart) << " ms Elapsed\n";

getch();
}

return nRetCode;
}

//----------------------------------------------------------------------

Configuration of P-III & P-IV pcs are as below

P-IV 1.6GHz, 256K cache 256MB RAM
p-III 800MHz 256K cache 128 Mb RAM

Output:

In P-III, 1001 ms Elapsed
In P-IV, 1563 ms Elapsed

Where is the actual problem? In Windows, on Processor?

**Deniz** · August 28th, 2003, 12:28 AM

My experience with Sleep() has been that it isnt really supposed to slow down on a faster machine.

Are you only running the program or compiling it as well on the PIV? And which compiler are you using?

**harisankar_r** · August 28th, 2003, 12:37 AM

Originally posted by Deniz
My experience with Sleep() has been that it isnt really supposed to slow down on a faster machine.

Are you only running the program or compiling it as well on the PIV? And which compiler are you using?

This program was compiled in P-IV machine with Microsoft VC++ 6.0.

This program is created as Console application with MFC support.

I don't think the Sleep is delaying, but I'm sure the context switching is something to do with this delay. But overall function execution time more in P-IV. Even If I compile in P-III and run, the same case.

**Deniz** · August 28th, 2003, 12:43 AM

beats me then, I've never tried a console app with MFC, never even heard of it to be honest

**Andreas Masur** · August 28th, 2003, 02:43 AM

Originally posted by harisankar_r
I don't think the Sleep is delaying, but I'm sure the context switching is something to do with this delay. But overall function execution time more in P-IV. Even If I compile in P-III and run, the same case.

Well...it might be due to the new hyper-threading technology of the Pentium IV. It can cause threaded applications running slower than on older Pentiums. Try to disable this feature in the BIOS and see whether it will help...

**harisankar_r** · August 29th, 2003, 01:52 AM

Originally posted by Deniz
beats me then, I've never tried a console app with MFC, never even heard of it to be honest

Its nothing to do with console application. U can even create a MFC application and try this piece of code. Its the same result.

**Yves M** · August 29th, 2003, 07:59 AM

Originally posted by Andreas Masur
Well...it might be due to the new hyper-threading technology of the Pentium IV. It can cause threaded applications running slower than on older Pentiums. Try to disable this feature in the BIOS and see whether it will help...

That's only available from 3.06Ghz onwards, so that can't be the problem.

But in general, Sleep(1) is just guaranteed to sleep for at least one millisecond, it can be much more. If you have to get precision, use either waitable timers or multimedia timers.

The exact reason why the code's execution is slower on the P4 does probably depend on Windows and the hardware configuration. Then again, it might also depend on the outside temperature and wind speed

**Andreas Masur** · August 29th, 2003, 10:04 AM

Originally posted by Yves M
That's only available from 3.06Ghz onwards, so that can't be the problem.

Sorry but this is not true - of the top of my head it starts with 2.40 Ghz - I agree that I basically missed the 1.6 Ghz though...

**Andreas Masur** · August 29th, 2003, 10:05 AM

Originally posted by Yves M
But in general, Sleep(1) is just guaranteed to sleep for at least one millisecond, it can be much more. If you have to get precision, use either waitable timers or multimedia timers.

Just in addition...'Sleep(1)' will never even get close to one milliseconds...

Calling 'Sleep()' causes an interuption of the running thread and therefore a context-switch to another thread with at least the same priority. Therefore 'Sleep()' is heavily dependent on the time-slice of the operating system which of course varies heavily...

For example, the time-slice length on a Windows NT system is dependent on the size of a quantum. The following shows the three possible quantum lengths (expressed in quantum units) for Windows NT Workstation:

- 6
- 12
- 18

The lengths can be influenced by whether a process owns the foreground window or not. The rest is basic calculation...three quantum units elapse every tick of NT's quantum-tracking timer, and a timer tick period is either 10 milliseconds (uniprocessor x86) or 15 milliseconds (multiprocessor x86). This of course is also dependent on the vendor and motherboard but that would lead too far here.

Which this calculation we would end up with the following time-slice length for a multiprocessor x86 system:

- 30 ms
- 60 ms
- 90 ms

First of all, OTOH I do not remember how the operating systems decides which quantum length to be used but basically you should see my point already...either way, we are being far away from 1 millisecond...

**Yves M** · August 29th, 2003, 10:19 AM

Originally posted by Andreas Masur
Sorry but this is not true - of the top of my head it starts with 2.40 Ghz - I agree that I basically missed the 1.6 Ghz though...

The first P4 with *enabled* hyperthreading was the 3.06 Ghz version. Previous versions of the P4 had HT built-in but disabled inside the chip itself, so it wasn't available.

c.f. this article (for example), there probably are many others.

**Andreas Masur** · August 29th, 2003, 10:30 AM

Originally posted by Yves M
The first P4 with *enabled* hyperthreading was the 3.06 Ghz version. Previous versions of the P4 had HT built-in but disabled inside the chip itself, so it wasn't available.

c.f. this article (for example), there probably are many others.

Well...interesting that it is not stated on the manufacturer site though...

Anyway...I haven't been digging around that much with the Pentium 4 yet...

**Yves M** · August 30th, 2003, 06:40 AM

Oh yes, you are right. I got confused by the fact that the first *historically available* P4 with HT was the 3.06. I forgot that they later made slower P4s with HT available.

**harisankar_r** · September 2nd, 2003, 02:27 AM

Originally posted by Andreas Masur
Just in addition...'Sleep(1)' will never even get close to one milliseconds...

Calling 'Sleep()' causes an interuption of the running thread and therefore a context-switch to another thread with at least the same priority. Therefore 'Sleep()' is heavily dependent on the time-slice of the operating system which of course varies heavily...

For example, the time-slice length on a Windows NT system is dependent on the size of a quantum. The following shows the three possible quantum lengths (expressed in quantum units) for Windows NT Workstation:

- 6
- 12
- 18

The lengths can be influenced by whether a process owns the foreground window or not. The rest is basic calculation...three quantum units elapse every tick of NT's quantum-tracking timer, and a timer tick period is either 10 milliseconds (uniprocessor x86) or 15 milliseconds (multiprocessor x86). This of course is also dependent on the vendor and motherboard but that would lead too far here.

Which this calculation we would end up with the following time-slice length for a multiprocessor x86 system:

- 30 ms
- 60 ms
- 90 ms

First of all, OTOH I do not remember how the operating systems decides which quantum length to be used but basically you should see my point already...either way, we are being far away from 1 millisecond...

How can I set the quantum length or I've to keep my application run slowly in P-IV? What can be the solution for this?

**munna** · September 2nd, 2003, 02:32 AM

P IV not supported, use at your own risk....

Results may vary, use P3 for best reults

**Andreas Masur** · September 2nd, 2003, 02:39 AM

Originally posted by harisankar_r
How can I set the quantum length or I've to keep my application run slowly in P-IV? What can be the solution for this?

Well...you cannot set the length of the quantum...it is pre-defined...

Thread: P-IV Slower than P-III or windows Sleep(ing)?

Thread Tools

Display

P-IV Slower than P-III or windows Sleep(ing)?

ADD to the software release notes

Posting Permissions