Please Help: Serial Port Interrupt Latency in Windows XP

NTDEV
1

Hi All,

I have a laptop with a RS232 serial port. I have a serial port that keeps generating lots of interrupts. There is a driver that has an ISR for this interrupt [IRQ4].

When Windows 2000 Professional was loaded on the system, the device was working fine, meaning the interrupts were getting generated and handled without any latency.

Now after upgarding to Windows XP Professional, Im seeing lots of latency in the ISR invocation by the kernel. As a result my device application is not working as expected.

What could be issue ? Is it something to do with IRQL ?

On my laptop, I checked that IOConnectInterrupt was called with IRQL set to 23 (0x17)

Should I set this to 31 while calling IOConnectInterrupt ?

Further on Desktops, it is working fine on all OS (Windows 2000 Pro, XP Pro, Windows 98, XP Home Edition)

The error scenario could be explained via example as follows

The device generates interrupts every 600 microsecs. So my ISR should get executed almost every 600 microsecs. i.e. there should be time gap of roughly 600 microsecs between two consecutive ISR invocation.

On my windows XP laptop, I see that the time interval between two consecutive ISR invocation keeps varying drastically between 90 microsecs to 1200 microsecs. The behaviour is sporadic.

On all the other boxes where it is working, the time interval is always in the range 550microsec to 650 microsecs. This is an acceptable range.

So what could be the problem ? Please help

Thanks
Kiran

Never miss a thing. Make Yahoo your homepage.

2

> The device generates interrupts every 600 microsecs.

I do not think this device is Windows-compatible, i.e. can work reliably under
Windows, especially on heavy loads and with other “chatty” hardware.

There is nothing surprising in a fact Windows cannot provide 600us latency
reliably (can on some machines, cannot on other).

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

3

The device has worked without any issues on all desktops and all OS.And on laptops, it has worked with Windows 2000 Professional. On laptops with Windows XP, this issue was first seen.

Actually the device generates around 40 to 80 interrupts spaced around 600 microsecs. This burst of interrupts happens roughly every 5 minutes.

I am suspecting that IRQL might be the issue on Win XP laptops. So I was thinking of setting IRQL parameters as hard coded value of 31 while calling IoConnectInterrupt in the driver code.

Is that worth a try ?

Thanks
Kiran

“Maxim S. Shatskih” wrote:
> The device generates interrupts every 600 microsecs.

I do not think this device is Windows-compatible, i.e. can work reliably under
Windows, especially on heavy loads and with other “chatty” hardware.

There is nothing surprising in a fact Windows cannot provide 600us latency
reliably (can on some machines, cannot on other).

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

---------------------------------
Looking for last minute shopping deals? Find them fast with Yahoo! Search.

4

Does this happen on all laptops with XP or one particular brand? Changing the IRQL assigned to you is not recommended, I do not think that this will help your problem in the end. Remember nt is not an RTOS, there are other ISRs (ATA for example) which could starve our ISR for longer than expected.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Kiran Bacche
Sent: Wednesday, January 30, 2008 8:51 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Please Help: Serial Port Interrupt Latency in Windows XP

The device has worked without any issues on all desktops and all OS.And on laptops, it has worked with Windows 2000 Professional. On laptops with Windows XP, this issue was first seen.

Actually the device generates around 40 to 80 interrupts spaced around 600 microsecs. This burst of interrupts happens roughly every 5 minutes.

I am suspecting that IRQL might be the issue on Win XP laptops. So I was thinking of setting IRQL parameters as hard coded value of 31 while calling IoConnectInterrupt in the driver code.

Is that worth a try ?

Thanks
Kiran

“Maxim S. Shatskih” wrote:
> The device generates interrupts every 600 microsecs.

I do not think this device is Windows-compatible, i.e. can work reliably under
Windows, especially on heavy loads and with other “chatty” hardware.

There is nothing surprising in a fact Windows cannot provide 600us latency
reliably (can on some machines, cannot on other).

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

________________________________
Looking for last minute shopping deals? Find them fast with Yahoo! Search.http: — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</http:>

5

Kiran Bacche wrote:

I have a laptop with a RS232 serial port. I have a serial port
that keeps generating lots of interrupts. There is a driver that
has an ISR for this interrupt [IRQ4].

When Windows 2000 Professional was loaded on the system, the
device was working fine, meaning the interrupts were getting
generated and handled without any latency.

Now after upgarding to Windows XP Professional, Im seeing lots of
latency in the ISR invocation by the kernel. As a result my device
application is not working as expected.
…
On my windows XP laptop, I see that the time interval between two
consecutive ISR invocation keeps varying drastically between 90
microsecs to 1200 microsecs. The behaviour is sporadic.

I’ll bet I know the issue. Is this a multiprocessor machine (dual core,
hyperthreaded, or multiprocessor)? Are you using the rdtsc instruction
or KeQueryPerformanceCounter to do your timing?

If so, then the problem is not that the interrupt timing varies. The
problem is the measurement. The interrupts are being handled by
different processors, and their cycle counts are not aligned. The
interrupts are likely working exactly as you expect.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

6

CD/DVD drive in PIO mode can spend significant amount of time (all data
copies by READ/WRITE_REGISTER_USHORT) in ATAPI’s ISR.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Doron Holan” wrote in message news:xxxxx@ntdev…
Does this happen on all laptops with XP or one particular brand? Changing the
IRQL assigned to you is not recommended, I do not think that this will help
your problem in the end. Remember nt is not an RTOS, there are other ISRs (ATA
for example) which could starve our ISR for longer than expected.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Kiran Bacche
Sent: Wednesday, January 30, 2008 8:51 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Please Help: Serial Port Interrupt Latency in Windows XP

The device has worked without any issues on all desktops and all OS.And on
laptops, it has worked with Windows 2000 Professional. On laptops with Windows
XP, this issue was first seen.

Actually the device generates around 40 to 80 interrupts spaced around 600
microsecs. This burst of interrupts happens roughly every 5 minutes.

I am suspecting that IRQL might be the issue on Win XP laptops. So I was
thinking of setting IRQL parameters as hard coded value of 31 while calling
IoConnectInterrupt in the driver code.

Is that worth a try ?

Thanks
Kiran

“Maxim S. Shatskih” wrote:
> The device generates interrupts every 600 microsecs.

I do not think this device is Windows-compatible, i.e. can work reliably under
Windows, especially on heavy loads and with other “chatty” hardware.

There is nothing surprising in a fact Windows cannot provide 600us latency
reliably (can on some machines, cannot on other).

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

________________________________
Looking for last minute shopping deals? Find them fast with Yahoo!
Search.http:h/category.php?category=shopping> — NTDEV is sponsored by OSR For our
schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars To unsubscribe, visit the List Server section of
OSR Online at http://www.osronline.com/page.cfm?name=ListServer</http:>

7

It happens on all laptops with XP.

Also the same laptop with Win 2000 did not have the issue.

Thanks
Kiran

Doron Holan wrote:
v:* {behavior:url(#default#VML);} o:* {behavior:url(#default#VML);} w:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} Does this happen on all laptops with XP or one particular brand? Changing the IRQL assigned to you is not recommended, I do not think that this will help your problem in the end. Remember nt is not an RTOS, there are other ISRs (ATA for example) which could starve our ISR for longer than expected.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Kiran Bacche
Sent: Wednesday, January 30, 2008 8:51 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Please Help: Serial Port Interrupt Latency in Windows XP

The device has worked without any issues on all desktops and all OS.And on laptops, it has worked with Windows 2000 Professional. On laptops with Windows XP, this issue was first seen.

Actually the device generates around 40 to 80 interrupts spaced around 600 microsecs. This burst of interrupts happens roughly every 5 minutes.

I am suspecting that IRQL might be the issue on Win XP laptops. So I was thinking of setting IRQL parameters as hard coded value of 31 while calling IoConnectInterrupt in the driver code.

Is that worth a try ?

Thanks

Kiran

“Maxim S. Shatskih” wrote:

> The device generates interrupts every 600 microsecs.

I do not think this device is Windows-compatible, i.e. can work reliably under
Windows, especially on heavy loads and with other “chatty” hardware.

There is nothing surprising in a fact Windows cannot provide 600us latency
reliably (can on some machines, cannot on other).

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

---------------------------------

Looking for last minute shopping deals? Find them fast with Yahoo! Search. — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

---------------------------------
Never miss a thing. Make Yahoo your homepage.

8

Check PIO on the disk and CD drive. Those can be set differently on different installs of even the same OS. It may depend on whether the OEM drivers for the IDE controller happened to be available.

Loren
----- Original Message -----
From: Kiran Bacche
To: Windows System Software Devs Interest List
Sent: Wednesday, January 30, 2008 9:35 PM
Subject: RE: Re:[ntdev] Please Help: Serial Port Interrupt Latency in Windows XP

It happens on all laptops with XP.

Also the same laptop with Win 2000 did not have the issue.

Thanks
Kiran

Doron Holan wrote:
Does this happen on all laptops with XP or one particular brand? Changing the IRQL assigned to you is not recommended, I do not think that this will help your problem in the end. Remember nt is not an RTOS, there are other ISRs (ATA for example) which could starve our ISR for longer than expected.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Kiran Bacche
Sent: Wednesday, January 30, 2008 8:51 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Please Help: Serial Port Interrupt Latency in Windows XP

The device has worked without any issues on all desktops and all OS.And on laptops, it has worked with Windows 2000 Professional. On laptops with Windows XP, this issue was first seen.

Actually the device generates around 40 to 80 interrupts spaced around 600 microsecs. This burst of interrupts happens roughly every 5 minutes.

I am suspecting that IRQL might be the issue on Win XP laptops. So I was thinking of setting IRQL parameters as hard coded value of 31 while calling IoConnectInterrupt in the driver code.

Is that worth a try ?

Thanks
Kiran

“Maxim S. Shatskih” wrote:
> The device generates interrupts every 600 microsecs.

I do not think this device is Windows-compatible, i.e. can work reliably under
Windows, especially on heavy loads and with other “chatty” hardware.

There is nothing surprising in a fact Windows cannot provide 600us latency
reliably (can on some machines, cannot on other).

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

----------------------------------------------------------------------------

Looking for last minute shopping deals? Find them fast with Yahoo! Search. — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

------------------------------------------------------------------------------
Never miss a thing. Make Yahoo your homepage. — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

9

You have the serial-attached hardware, correct?

Sorry, but the serial port has RTS/CTS flow control protocol to stall the
peripheral till the OS/software will get the next data bytes from the host UART
to the memory.

It’s really bad that your hardware cannot do RTS/CTS flow control. The
peripheral’s serial interface must be stalled and not sending any bytes while
the host drives RTS low, which the host UART does automatically when it is
about to FIFO overflow.

Also, using FIFO on a host UART is a very good idea to reduce the number of
interrupts generated by the UART.

I can understand that there can be some primitive serial-attached hardware
which cannot do RTS/CTS, or which uses RTS/CTS and also DTR/DSR lines for some
data/state indications which are not standard for a serial port, or which uses
the hard timings in its serial protocol and so on, but for me it looks like
such hardware can be reliably served under MS-DOS only, not under non-realtime
multitasking OS like Windows.

Serial port is to transfer 7bit or 8bit bytes, possibly with parity, with
RTS/CTS flow control. Using a serial port in some other mode like a set of 9
random wires is a bad idea in modern OSes. Also, the only strict timing in a
serial port is between bits of a byte, including parity and stop one. Timing
between bytes (any 2 bytes) can be any.

As about “it works on some laptops and not others”. This is the usual
picture of unreliable and unsupported operation mode. It works by mere luck,
this is not guaranteed.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Kiran Bacche” wrote in message news:xxxxx@ntdev…
> It happens on all laptops with XP.
>
> Also the same laptop with Win 2000 did not have the issue.
>
> Thanks
> Kiran
>
> Doron Holan wrote:
> v:* {behavior:url(#default#VML);} o:
{behavior:url(#default#VML);} w: {behavior:url(#default#VML);} .shape
{behavior:url(#default#VML);} Does this happen on all laptops
with XP or one particular brand? Changing the IRQL assigned to you is not
recommended, I do not think that this will help your problem in the end.
Remember nt is not an RTOS, there are other ISRs (ATA for example) which could
starve our ISR for longer than expected.
>
> d
>
> From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Kiran Bacche
> Sent: Wednesday, January 30, 2008 8:51 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Please Help: Serial Port Interrupt Latency in Windows XP
>
>
> The device has worked without any issues on all desktops and all OS.And
on laptops, it has worked with Windows 2000 Professional. On laptops with
Windows XP, this issue was first seen.
>
>
>
> Actually the device generates around 40 to 80 interrupts spaced around
600 microsecs. This burst of interrupts happens roughly every 5 minutes.
>
>
>
> I am suspecting that IRQL might be the issue on Win XP laptops. So I was
thinking of setting IRQL parameters as hard coded value of 31 while calling
IoConnectInterrupt in the driver code.
>
>
>
> Is that worth a try ?
>
>
>
> Thanks
>
> Kiran
>
>
>
> “Maxim S. Shatskih” wrote:
>
> > The device generates interrupts every 600 microsecs.
>
> I do not think this device is Windows-compatible, i.e. can work reliably
under
> Windows, especially on heavy loads and with other “chatty” hardware.
>
> There is nothing surprising in a fact Windows cannot provide 600us latency
> reliably (can on some machines, cannot on other).
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> ---------------------------------
>
> Looking for last minute shopping deals? Find them fast with Yahoo!
Search. — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>
>
> ---------------------------------
> Never miss a thing. Make Yahoo your homepage.

10

Yes Tim, you are right. The driver uses rdtsc instruction for measuring the time between two consecutive interrupts.However, the laptop is neither dual core nor hyperthread nor multiprocessor. It is just a single Intel Pentium M 1.7 GHz Box.

Also I checked the CPU Freq using CPU-Z utility. I found that the the freq was changing from 1694 MHz to 598 MHz back and forth. After googling, I found that it was the due to the power save mode settings. So I changed( via the Battery Wizard) the Power Mode setting to ensure CPU Freq is maximum. Now the CPU Freq does not change but remains fixed at 1694.5.

But the problem still exist. I think the problem is due to some CPU Frequency related issue. Becoz of that, the code that relies on rdtsc becomes unreliable.

Any clue on what can be tried next ?

Thanks
Kiran

Tim Roberts wrote:
Kiran Bacche wrote:
>
>
> I have a laptop with a RS232 serial port. I have a serial port
> that keeps generating lots of interrupts. There is a driver that
> has an ISR for this interrupt [IRQ4].
>
> When Windows 2000 Professional was loaded on the system, the
> device was working fine, meaning the interrupts were getting
> generated and handled without any latency.
>
> Now after upgarding to Windows XP Professional, Im seeing lots of
> latency in the ISR invocation by the kernel. As a result my device
> application is not working as expected.
> …
> On my windows XP laptop, I see that the time interval between two
> consecutive ISR invocation keeps varying drastically between 90
> microsecs to 1200 microsecs. The behaviour is sporadic.
>

I’ll bet I know the issue. Is this a multiprocessor machine (dual core,
hyperthreaded, or multiprocessor)? Are you using the rdtsc instruction
or KeQueryPerformanceCounter to do your timing?

If so, then the problem is not that the interrupt timing varies. The
problem is the measurement. The interrupts are being handled by
different processors, and their cycle counts are not aligned. The
interrupts are likely working exactly as you expect.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

11

“Kiran Bacche” wrote in message news:xxxxx@ntdev…
> Yes Tim, you are right. The driver uses rdtsc instruction for measuring the time between two consecutive interrupts.However,
> the laptop is neither dual core nor hyperthread nor multiprocessor. It is just a single Intel Pentium M 1.7 GHz Box.

Why do you need to measure time between interrupts?
Is this Modbus or alike protocol?

–PA

12

“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev…
> You have the serial-attached hardware, correct?
>
> Sorry, but the serial port has RTS/CTS flow control protocol to stall the
> peripheral till the OS/software will get the next data bytes from the host UART
> to the memory.

??? They can use any flow control or none at all…
The XP issue can be caused by ACPI stealing CPU time,
or some in-box driver has longer DPCs in XP than in win2k.

How to verify this:
- Run on a desktop board; also try Safe mode to possibly exclude some stuff.

600 us corresponds to only ~19600 bitrate. A standard laptop
easily works at 115200 (with flow control, of course).

Regards,
–PA

13

> 600 us corresponds to only ~19600 bitrate. A standard laptop

easily works at 115200 (with flow control, of course).

Even Pentium-166 works at 115200, with FIFO for sure.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

14

Kiran Bacche wrote:

Yes Tim, you are right. The driver uses rdtsc instruction for
measuring the time between two consecutive interrupts.However, the
laptop is neither dual core nor hyperthread nor multiprocessor. It is
just a single Intel Pentium M 1.7 GHz Box.

Also I checked the CPU Freq using CPU-Z utility. I found that the the
freq was changing from 1694 MHz to 598 MHz back and forth. After
googling, I found that it was the due to the power save mode
settings. So I changed( via the Battery Wizard) the Power Mode setting
to ensure CPU Freq is maximum. Now the CPU Freq does not change but
remains fixed at 1694.5.

But the problem still exist. I think the problem is due to some CPU
Frequency related issue. Becoz of that, the code that relies on rdtsc
becomes unreliable.

Any clue on what can be tried next ?

Well, let’s be sure we know exactly what problem you’re trying to
solve. My theory is that the interrupts are being handled exactly as
you expect, with the timing you expect, but that you are simply unable
to verify that because of the unreliability of the cycle counter. If
so, then it seems to me you don’t really have a problem at all.

There is simply no generic way of doing microsecond-accurate timing in
Windows. If you really need to verify the timing, add some debug code
in your driver to toggle a line on one of the parallel ports and monitor
it with an oscilloscope.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

15

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, January 31, 2008 6:05 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Please Help: Serial Port Interrupt Latency in Windows XP

> 600 us corresponds to only ~19600 bitrate. A standard laptop
> easily works at 115200 (with flow control, of course).

Even Pentium-166 works at 115200, with FIFO for sure.

:slight_smile: I used 115200 in DOS at PC XT (8086) in TSR program running on the background :slight_smile: I’m not sure if UARTs at this PC had FIFO; probably not.

But you were completely right in your long reply. NT is not RTOS and if they don’t use some kind of flow control, they’re out of luck.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

16

Sorry to chime in so late. Instead of using RDTSC use
KeQueryPerformanceCounter or you will introduce race conditions in the
entire system. RDTSC without a lock adds a race condition because it is not
an atomic or multiprocessor safe instruction. OS provided
KeQueryPerformanceCounter will do this for you. If there are third party
drivers on the system which call RDTSC without a proper locking mechanism,
KeQueryPerformanceCounter is still be subject to race conditions which are
beyond your control.

/Daniel

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Kiran Bacche wrote:
>> Yes Tim, you are right. The driver uses rdtsc instruction for measuring
>> the time between two consecutive interrupts.However, the laptop is
>> neither dual core nor hyperthread nor multiprocessor. It is just a single
>> Intel Pentium M 1.7 GHz Box.
>> Also I checked the CPU Freq using CPU-Z utility. I found that the the
>> freq was changing from 1694 MHz to 598 MHz back and forth. After
>> googling, I found that it was the due to the power save mode settings.
>> So I changed( via the Battery Wizard) the Power Mode setting to ensure
>> CPU Freq is maximum. Now the CPU Freq does not change but remains fixed
>> at 1694.5.
>> But the problem still exist. I think the problem is due to some CPU
>> Frequency related issue. Becoz of that, the code that relies on rdtsc
>> becomes unreliable.
>> Any clue on what can be tried next ?
>
> Well, let’s be sure we know exactly what problem you’re trying to solve.
> My theory is that the interrupts are being handled exactly as you expect,
> with the timing you expect, but that you are simply unable to verify that
> because of the unreliability of the cycle counter. If so, then it seems
> to me you don’t really have a problem at all.
>
> There is simply no generic way of doing microsecond-accurate timing in
> Windows. If you really need to verify the timing, add some debug code in
> your driver to toggle a line on one of the parallel ports and monitor it
> with an oscilloscope.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

17

Actually that should be “If there are third party drivers on the system
which call RDTSC instead of KeQueryPerformanceCounter, it is still subject
to race conditions beyond your control.” because using separate locks (your
own next to the OS provided) is not going to help.

/Daniel

wrote in message news:xxxxx@ntdev…
> If there are third party drivers on the system which call RDTSC without a
> proper locking mechanism, KeQueryPerformanceCounter is still be subject to
> race conditions which are beyond your control.
>
> /Daniel
>
>
> “Tim Roberts” wrote in message news:xxxxx@ntdev…
>> Kiran Bacche wrote:
>>> Yes Tim, you are right. The driver uses rdtsc instruction for measuring
>>> the time between two consecutive interrupts.However, the laptop is
>>> neither dual core nor hyperthread nor multiprocessor. It is just a
>>> single Intel Pentium M 1.7 GHz Box.
>>> Also I checked the CPU Freq using CPU-Z utility. I found that the the
>>> freq was changing from 1694 MHz to 598 MHz back and forth. After
>>> googling, I found that it was the due to the power save mode settings.
>>> So I changed( via the Battery Wizard) the Power Mode setting to ensure
>>> CPU Freq is maximum. Now the CPU Freq does not change but remains fixed
>>> at 1694.5.
>>> But the problem still exist. I think the problem is due to some CPU
>>> Frequency related issue. Becoz of that, the code that relies on rdtsc
>>> becomes unreliable.
>>> Any clue on what can be tried next ?
>>
>> Well, let’s be sure we know exactly what problem you’re trying to solve.
>> My theory is that the interrupts are being handled exactly as you expect,
>> with the timing you expect, but that you are simply unable to verify that
>> because of the unreliability of the cycle counter. If so, then it seems
>> to me you don’t really have a problem at all.
>>
>> There is simply no generic way of doing microsecond-accurate timing in
>> Windows. If you really need to verify the timing, add some debug code in
>> your driver to toggle a line on one of the parallel ports and monitor it
>> with an oscilloscope.
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>
>

18

Huh? I must be missing something. RDTSC reads the performance counter on the
current processor. Other than the other issues already endlessly discussed
here (cpu speed, drift between cpus etc.) how is this an MP issue?

On Feb 4, 2008 9:47 AM, wrote:

> Sorry to chime in so late. Instead of using RDTSC use
> KeQueryPerformanceCounter or you will introduce race conditions in the
> entire system. RDTSC without a lock adds a race condition because it is
> not
> an atomic or multiprocessor safe instruction. OS provided
> KeQueryPerformanceCounter will do this for you. If there are third party
> drivers on the system which call RDTSC without a proper locking mechanism,
> KeQueryPerformanceCounter is still be subject to race conditions which are
> beyond your control.
>
> /Daniel
>
>
> “Tim Roberts” wrote in message news:xxxxx@ntdev…
> > Kiran Bacche wrote:
> >> Yes Tim, you are right. The driver uses rdtsc instruction for measuring
> >> the time between two consecutive interrupts.However, the laptop is
> >> neither dual core nor hyperthread nor multiprocessor. It is just a
> single
> >> Intel Pentium M 1.7 GHz Box.
> >> Also I checked the CPU Freq using CPU-Z utility. I found that the the
> >> freq was changing from 1694 MHz to 598 MHz back and forth. After
> >> googling, I found that it was the due to the power save mode settings.
> >> So I changed( via the Battery Wizard) the Power Mode setting to ensure
> >> CPU Freq is maximum. Now the CPU Freq does not change but remains fixed
> >> at 1694.5.
> >> But the problem still exist. I think the problem is due to some CPU
> >> Frequency related issue. Becoz of that, the code that relies on rdtsc
> >> becomes unreliable.
> >> Any clue on what can be tried next ?
> >
> > Well, let’s be sure we know exactly what problem you’re trying to solve.
> > My theory is that the interrupts are being handled exactly as you
> expect,
> > with the timing you expect, but that you are simply unable to verify
> that
> > because of the unreliability of the cycle counter. If so, then it seems
> > to me you don’t really have a problem at all.
> >
> > There is simply no generic way of doing microsecond-accurate timing in
> > Windows. If you really need to verify the timing, add some debug code
> in
> > your driver to toggle a line on one of the parallel ports and monitor it
> > with an oscilloscope.
> >
> > –
> > Tim Roberts, xxxxx@probo.com
> > Providenza & Boekelheide, Inc.
> >
> >
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
Mark Roddy

19

Here is what says Intel: "RDTSC instruction does not serialize instruction execution. That is, it does not imply that all the events caused by the preceding instructions have been completed or that events caused by subsequent instructions have not begun. If an exact event count is desired, software must use a serializing instruction (such as the CPUID instruction) before and/or after the execution of the RDTSC instruction. "

But I have doubts that adding a CPUID instruction is enough because I recall having read an in-depth article which says doing RDTSC from multiple CPUs simultaneously is absolutely taboo and it had something to do because of the way the MSRs are working or something like that (sorry). I am travelling in India and possibilities to look it up are limited for me now.

/Daniel

“Mark Roddy” wrote in message news:xxxxx@ntdev…
Huh? I must be missing something. RDTSC reads the performance counter on the current processor. Other than the other issues already endlessly discussed here (cpu speed, drift between cpus etc.) how is this an MP issue?

On Feb 4, 2008 9:47 AM, wrote:

Sorry to chime in so late. Instead of using RDTSC use
KeQueryPerformanceCounter or you will introduce race conditions in the
entire system. RDTSC without a lock adds a race condition because it is not
an atomic or multiprocessor safe instruction. OS provided
KeQueryPerformanceCounter will do this for you. If there are third party
drivers on the system which call RDTSC without a proper locking mechanism,
KeQueryPerformanceCounter is still be subject to race conditions which are
beyond your control.

/Daniel

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Kiran Bacche wrote:
>> Yes Tim, you are right. The driver uses rdtsc instruction for measuring
>> the time between two consecutive interrupts.However, the laptop is
>> neither dual core nor hyperthread nor multiprocessor. It is just a single
>> Intel Pentium M 1.7 GHz Box.
>> Also I checked the CPU Freq using CPU-Z utility. I found that the the
>> freq was changing from 1694 MHz to 598 MHz back and forth. After
>> googling, I found that it was the due to the power save mode settings.
>> So I changed( via the Battery Wizard) the Power Mode setting to ensure
>> CPU Freq is maximum. Now the CPU Freq does not change but remains fixed
>> at 1694.5.
>> But the problem still exist. I think the problem is due to some CPU
>> Frequency related issue. Becoz of that, the code that relies on rdtsc
>> becomes unreliable.
>> Any clue on what can be tried next ?
>
> Well, let’s be sure we know exactly what problem you’re trying to solve.
> My theory is that the interrupts are being handled exactly as you expect,
> with the timing you expect, but that you are simply unable to verify that
> because of the unreliability of the cycle counter. If so, then it seems
> to me you don’t really have a problem at all.
>
> There is simply no generic way of doing microsecond-accurate timing in
> Windows. If you really need to verify the timing, add some debug code in
> your driver to toggle a line on one of the parallel ports and monitor it
> with an oscilloscope.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Mark Roddy

20

There are several issues, one problem is that each processor has its own time-stamp counter so you should use it in combination with KeGetCurrentProcessorNumber only. Another issue is the inaccuracy because of the out-of-order execution problem mentioned by Intel but this is not the real problem.

There is a blog article on the subject and what I’m sure about is that its bottom line is that using RDTSC anywhere will cause KeQueryPerformanceCounter to malfunction globally but I forgot the details of exactly why. I thought it was because of a race condition but it may also have to do with internal book keeping that KeQueryPerformanceCounter is doing and not be exactly a race condition. I want to get this exactly right but I cannot find the article right now, so if anybody knows exactly or find the article please post the link.

/Daniel

“Mark Roddy” wrote in message news:xxxxx@ntdev…
Huh? I must be missing something. RDTSC reads the performance counter on the current processor. Other than the other issues already endlessly discussed here (cpu speed, drift between cpus etc.) how is this an MP issue?

On Feb 4, 2008 9:47 AM, wrote:

Sorry to chime in so late. Instead of using RDTSC use
KeQueryPerformanceCounter or you will introduce race conditions in the
entire system. RDTSC without a lock adds a race condition because it is not
an atomic or multiprocessor safe instruction. OS provided
KeQueryPerformanceCounter will do this for you. If there are third party
drivers on the system which call RDTSC without a proper locking mechanism,
KeQueryPerformanceCounter is still be subject to race conditions which are
beyond your control.

/Daniel

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Kiran Bacche wrote:
>> Yes Tim, you are right. The driver uses rdtsc instruction for measuring
>> the time between two consecutive interrupts.However, the laptop is
>> neither dual core nor hyperthread nor multiprocessor. It is just a single
>> Intel Pentium M 1.7 GHz Box.
>> Also I checked the CPU Freq using CPU-Z utility. I found that the the
>> freq was changing from 1694 MHz to 598 MHz back and forth. After
>> googling, I found that it was the due to the power save mode settings.
>> So I changed( via the Battery Wizard) the Power Mode setting to ensure
>> CPU Freq is maximum. Now the CPU Freq does not change but remains fixed
>> at 1694.5.
>> But the problem still exist. I think the problem is due to some CPU
>> Frequency related issue. Becoz of that, the code that relies on rdtsc
>> becomes unreliable.
>> Any clue on what can be tried next ?
>
> Well, let’s be sure we know exactly what problem you’re trying to solve.
> My theory is that the interrupts are being handled exactly as you expect,
> with the timing you expect, but that you are simply unable to verify that
> because of the unreliability of the cycle counter. If so, then it seems
> to me you don’t really have a problem at all.
>
> There is simply no generic way of doing microsecond-accurate timing in
> Windows. If you really need to verify the timing, add some debug code in
> your driver to toggle a line on one of the parallel ports and monitor it
> with an oscilloscope.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Mark Roddy