Please Help: Serial Port Interrupt Latency in Windows XP

__rdtsc is available in user mode as an intrinsic. If this causes
KeQueryPerformanceCounter to malfunction globally the VS folks have shot the
OS folks in the foot. Wouldn’t be the first time that happened.

It just reads a timestamp counter from the current cpu. As long as you
aren’t too concerned about the absolute accuracy of that timestamp counter,
everything ought to be fine.

On Feb 4, 2008 11:23 AM, wrote:

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

Mark Roddy wrote:

__rdtsc is available in user mode as an intrinsic. If this causes
KeQueryPerformanceCounter to malfunction globally the VS folks have
shot the OS folks in the foot. Wouldn’t be the first time that happened.

It just reads a timestamp counter from the current cpu. As long as you
aren’t too concerned about the absolute accuracy of that timestamp
counter, everything ought to be fine.

Which, ironically enough, is exactly what KeQueryPerformanceCounter does
on a multiprocessor system.

Daniel has shared this FUD before. I do not believe the problem is real.

On Feb 4, 2008 11:23 AM, > mailto:xxxxx> wrote:
>
> 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.
>

KeQueryPerformanceCounter on an MP machine doesn’t do any bookkeeping.
It calls HalQueryPerformanceCounter, which does an rdtsc and returns.
With all due respect, I think you are hallucinating.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</mailto:xxxxx>