>
> >         I think one is going to have some trouble measuring real time
> > accurately for any period under a second in any sophisticated
> > operating system, be it any of the Windows flavors, DOS, or Linux.
> >
> >         The tricky thing about exact timing on a modern computer is
> > that interrupts are constantly being serviced from many different
> > systems such that a finely-accurate timing routine may be put on hold
> > for a millisecond hear and another there every time the disk drive
> > needs servicing or the operating system must tend to another user.
>
> What do most of you consider real-time?  I have lab software that has
> a typical latency of < 1ms under Windows [NT,95,98].  I only measure
> milliseconds so it may be substantially less.  Occasionally there's
> a 1.x to 2.x ms latency spike.
>
> Is this real-time enough for most of you?  If so there's a few things
> that you can do to make performance more predictable.  One is to make
> sure you have no devices that will disable interrupts for a long time.
> Careful selection of hardware with good drivers helps a lot.  It's
> largely irrelevant now, but make sure you have a bus mastering hard
> drive and no other programmed IO devices.  Disable networking support
> under Win95 (maybe 98 too).  The last thing is that you absolutely
> cannot poll.
>
> I'm using National Instruments aquisition boards and callbacks.  Works
> very well for me.
>
> If 1ms latency isn't enough or occasional higher delays aren't
> acceptable then a more dedicated solution is definitely in order.
>
> How good is PIC AD?  I'm used to working with these National Inst.
> boards with no missing codes with great accuracy and precision.  Is
> the AD on PICs up to serious work?
>
> Chris

>
> Des Bromilow writes:
> >My thesis was based on writing a virtual instruments package under win =
> >3.x/95.
> >I could get the 55ms interupt operable, but anything faster than that is =
> >impossible under the normal PC architecture.
>
>         This pretty well goes along with what I have found in DOS.
>
>         You can try an experiment to see just how busy things are.
> Get a P.C. hardware manual and look at the section on the
> timer/counter which makes tones for the speaker.  There are two
> control bits, one to turn the path to the speaker on and off and
> another to enable the square wave output.  In this case, that bit
> should be off so that the speaker pops once when the path is turned on
> and once when it is turned off.  If you write a timing loop to cycle
> the speaker 500 times per second in a square wave, it should sound
> just like the square wave one gets from the normal counter.  On a
> P.C., it sounds like a sick buzzer which is about to die.  This is due
> to all the little lapses in timing which elongate a cycle here and a
> cycle there.  We aren't trying to measure time, but generating timing
> and it is obvious that in an interrupt-driven world, it is hard to do
> either accurately.  The buzz loop simply accentuates how rough it can
> be.
>
>         You can have interrupts and accurate timing, but the
> interrupts, themselves, are where one needs to take measurements and
> let the foreground activities happen asynchronously.
>
>         I once wrote an experimental routine to pop the speaker every
> time the timer ticked and it gave the P.C. a nice little fast ticking
> sound like a 16-MM movie projector.  The 55-ms timer tick has one of
> the highest priorities on a P.C. so you can literally count on it.
>
> Martin McCormick WB5AGZ  Stillwater, OK
> OSU Center for Computing and Information Services Data Communications Group

>         Okay, folks, I accidentally may have mislead some of us about
> some of the timing issues on a P.C.  I will try to be brief, but clear
> things up.
>
>         The real-time clock updates every 55 milliseconds, all right.
> When one boots DOS, the timer/counter that generates the interrupt
> actually generates it at 55 milliseconds, also.  Then things can get
> interesting.  The hardware interrupt ISR has a vector in low memory
> along with many other such vectors that lets one put new ISR's in
> which reroute the flow through your new ISR and then to what was
> originally there.  This is typical ISR protocol anywhere.  One neat
> thing that programmers can do is to set the deviser latch in the
> timer/counter to some lower value so that the timer ISR rolls over
> much more often such as 1,000 times per second.
>
>         Now, if you want the rest of your computer to continue working
> properly, that new ISR must call the ISR which is next in line every
> 55 milliseconds so the new ISR only does this every 55TH call.  The
> rest of the time, it just does its thing and then exits with an iret.
>
>         BASICA is reported to step up the timer hardware interrupt to
> 4 times the 18.2-HZ rate in order to make music routines run more
> smoothly.
>
>         All this is real nice, but it can only work if you control
> everything that is run on that computer and the order in which it is
> installed.
>
>         There are recommended methods for installing custom routines
> so that terrible things don't happen, but in the cowboy code world of
> Windows, there are no guarantees and the 55-MS ticker is the only sure
> timing constant without resorting to more cowboy or hotdog code and
> its almost certain consequences.  All it takes for a grand mess is for
> your timer modifier to somehow get installed in the wrong place in the
> chain (such has happens if you run some other program with a timer
> modifier), and your system is hosed.
>
> Martin McCormick
>

>
>         This pretty well goes along with what I have found in DOS.
>
>         You can try an experiment to see just how busy things are.
> Get a P.C. hardware manual and look at the section on the
> timer/counter which makes tones for the speaker.  There are two
> control bits, one to turn the path to the speaker on and off and
> another to enable the square wave output.  In this case, that bit
> should be off so that the speaker pops once when the path is turned on
> and once when it is turned off.  If you write a timing loop to cycle
> the speaker 500 times per second in a square wave, it should sound
> just like the square wave one gets from the normal counter.  On a
> P.C., it sounds like a sick buzzer which is about to die.  This is due
> to all the little lapses in timing which elongate a cycle here and a
> cycle there.  We aren't trying to measure time, but generating timing
> and it is obvious that in an interrupt-driven world, it is hard to do
> either accurately.  The buzz loop simply accentuates how rough it can
> be.
>
>         You can have interrupts and accurate timing, but the
> interrupts, themselves, are where one needs to take measurements and
> let the foreground activities happen asynchronously.
>
>         I once wrote an experimental routine to pop the speaker every
> time the timer ticked and it gave the P.C. a nice little fast ticking
> sound like a 16-MM movie projector.  The 55-ms timer tick has one of
> the highest priorities on a P.C. so you can literally count on it.
>
> Martin McCormick WB5AGZ  Stillwater, OK
> OSU Center for Computing and Information Services Data Communications Group
>