Again a "realtime" question

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Dear subscribers,

Lately there has been much discussion about what Realtime really means. I
have a question regarding this which is a bit off-topic because it concerns
a "normal" computer, not an embedded one. In Win XP you can assign the
priority "realtime" to a task. I guess it means that whenever that task
wants something, everything else is paused. But in what way is this
"realtime"? Is it really "realtime" or is this something that an embedded
programmer can only laugh about?

I hope You'll forgive me my being off-topic.

Thanks in advance!

Yours sincerely,
Rene



Re: Again a "realtime" question
On Mon, 21 Jun 2004 23:57:21 +0200, "René"

Quoted text here. Click to load it

if(Windows == 1){
  realtime = FALSE;
  embedded_programmer = LAUGH;
} else {
  realtime = MAYBE;
}

Re: Again a "realtime" question

Quoted text here. Click to load it

That's userland. This one task is king in userland - do you have any
guarantees about system land? :-) (An embedded programmer laughing)

Andreas
--
There's no time to stop for gas, we're already late.
- Karin Donker

Re: Again a "realtime" question

Quoted text here. Click to load it

In none --- it's marketing gobbledygook.  As an (admittedly crude)
rule-of-thumb, whenever Microsoft uses a technical term you recognize,
in a place where ordinary users may ever see it, it's a good bet to
assume it means something vaguely related, but confusingly different
from the generally accepted meaning of the term.

Quoted text here. Click to load it

Strictly the latter.  The only Microsoft desktop OS that ever was
real-time was the original Win95 (or around there): it was guaranteed
to respond to the boot-up "event" in at most 100 days, by exercising a
complete lockup of the system. ;->

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Again a "realtime" question

Quoted text here. Click to load it

If you equate priority with realtime, yes. However, having a task hog
the CPU is realtime for one task only, which pretty much negates the idea
of a realtime "multitask operating system". Sure, lots of characteristics
make up a realtime system. What Windows et all lacks here is "latency", as
in "how fast can an interrupting device get serviced". In windows, the
service to a particular device not only have long latency, but variable
latency as well, as in you cannot predict how fast the device will get
serviced.

--
Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
We've slightly trimmed the long signature. Click to see the full one.
Re: Again a "realtime" question
On Mon, 21 Jun 2004 23:57:21 +0200, "René"

Quoted text here. Click to load it

"Realtime" in Windows is relative.  The short answer is "NO" but see
below for the (really) complicated answer.  Laughing depends on your
perspective.  

Threads in Win32 are preemptively scheduled and have prioritiy levels
ranging from 0..31, 31 being the highest.  Additionally, each Win32
process is assigned a priority class which determines the starting
level, dynamic range and incremental differences between various
levels of thread priority within the process.  Scheduling is done by
soley by thread priority level - the thread which currently is ready
to run and has the highest priority will be executed.  If more than
one thread is ready to run and all are at the current highest
priority, they will be executed round robin until they all finish or
block, or until a still higher priority thread becomes ready to run.

The process classes "idle", "normal" and "high" allow thread priority
levels from 0..15 and have some overlap in their allowed ranges ...
so, for example, a "lowest" priority thread in a "high" priority
process (level 11) can be preempted by a "highest" priority thread in
a "normal" priority process (level 12).  Threads marked "time
critical" in any of these classes execute at level 15 which is the
highest priority normally used in a Win32 system.  Additionally, the
scheduler dynamically adjusts the priorities of all non "time
critical" threads in any these process classes to ensure "fairness"
and prevent starvation.

The system treats "realtime" class processes differently.  A
"realtime" process can set thread priority levels from 16..31 and the
scheduler will not adjust them.  Thus any ready thread in a
"realtime" process will preempt all threads in all non realtime
processes.  
{* Being Windows, there is, of course, an exception to this.  The
kernel may temporarily "boost" the priority of any thread in the
system which blocked pending I/O and is not at a "time critical"
priority (ie. 31 for realtime, 15 for all else).  When an I/O
operation completes, a kernel mode driver can temporarily raise the
calling thread's priority by up to 2 counts in hopes that the thread
will quickly start another I/O operation and block again.  This driver
initiated "boosting" is separate from, and has nothing to do with,
dynamic fairness adjustments made by the scheduler. }

You must be very careful with "realtime" processes because almost all
of the basic Win32 services (task manager, GUI, filesystem, network,
etc.) run only at "high" priority.  "Realtime" class processes can't
rely on any OS services being available to them other than kernel mode
and in-process (DLL) services.  In other words, if the service is
implemented in a separate executable, you probably can't use it.  In
practice this means the vast majority of the documented Win32 API is
unusable.

A realtime process gone wrong will freeze or crash the system with no
possibility of recovery.  Microsoft itself recommends that developers
not use the "realtime" priority class because of its potential for
harming the system.  

George
--
for email reply remove "/" from address

Re: Again a "realtime" question
On Tue, 22 Jun 2004 02:23:58 -0400, George Neuner

Quoted text here. Click to load it

Is this documented somewhere ?

The only reason I can think of altering the real time priorities is
preventing priority inversions, i.e. boosting a low priority thread
priority holding a shared resource, which is also waited by a higher
priority thread.

Win CE 3.0 does this and there are several articles in MSDN about it,
but does Win NT/2k/XP also do this ?

Paul
  

Re: Again a "realtime" question

Quoted text here. Click to load it

It is pieced together from several sources.  The info on the scheduler
came partly  from Jeff Richter's MS books "Advanced Windows NT" and
"Advanced Windows" and partly from Art Baker's book "the Windows NT
Device Driver Book".   The OP asked specifically about WinXP but all
Win32 desktop systems use the same scheduler.  

The info on "boosting" came partly from Baker's book and partly from
the NT4 DDK.  The newer plug-n-play drivers behave identically to NT
drivers WRT most processing ... their additional functionality is to
better support 2-level drivers and to support detection and use of hot
swapped hardware.

The NT4 DDK says that variable priority threads may be dynamcally
adjusted and that "time critical" threads (level 15 or 31) can not be
boosted.  It does not say that other realtime threads cannot be
boosted.  The 2K/XP DDKs refer back to or parrot the NT docs wherever
processing is the same and offer no new information on this subject.

Baker supplies more data but also does not settle the matter.  He says
that "realtime" threads (levels 16..31) are statically prioritized -
however, he distinguishes "system" threads created by kernel code
(using PsCreateSystemThread) from "user" threads created by
application code.   He notes that "system" threads can have either
"realtime or variable priority" but says nothing useful regarding
"user" threads.

Baker confirms the other sources regarding scheduler behavior, however
his careful separation of "system" vs "user" threads creates ambiguity
regarding boosting.   Boosting applies only to user mode threads and
so is not relevent to his kernel mode "system" threads.  I have found
no other information beyond the DDK notes to indicate which "user"
threads boosting does apply to.


So, admittedly, I am guessing.  As a responsible developer faced with
ambiguous information, I am forced to assume the worst - namely that
in Win32 all application threads are subject to boosting except where
explicitly noted.

YMMV.


Quoted text here. Click to load it

Yes ... Win32 desktop system schedulers correctly handle priority
inversion.  Driver I/O boosting is a separate issue.

George

--
for email reply remove "/" from address

Re: Again a "realtime" question
On Tue, 22 Jun 2004 16:47:34 -0400, George Neuner

Quoted text here. Click to load it

Thanks for the pointers, I will look into some of them.

Paul


Re: Again a "realtime" question
Quoted text here. Click to load it

The term realtime is always relative.  In Windows it is
relative to geological timescales where the length of
a human lifespan is easily missed as too momentary.

Re: Again a "realtime" question
On Mon, 21 Jun 2004 23:57:21 +0200, "René"

Quoted text here. Click to load it

I don't know about XP, but at least NT4 and W2k works surprisingly
well as a soft real time platform, _provided_ that you keep the damn
(l)users away from the computer i.e. disconnect the keyboard and mouse
(or at least lock them away :-).

Selecting only well behaving cards with well behaving drivers and
using only well behaving application and starting the programs before
starting any real time activity and you may get multimedia timer
expiration notifications within a millisecond or two in more than 99 %
of the cases. But still you may experience unexplained more than 10 ms
delays a few times a day.

If you can live all these limitations, you can get a quite usable
performance for many kinds of applications.

However, if you let the user start any programs randomly or let him or
her install any untested cards and drivers, there can be quite severe
hiccups in the RT thread execution.

Paul
    

Re: Again a "realtime" question

Quoted text here. Click to load it

Usable performance, perhaps, but the working definition for "realtime"
that I use is this:  "if it's late, it's wrong."  If the system can't
guarentee that a signal won't be late, it's not realtime, IMHO.

Ed


Re: Again a "realtime" question

Quoted text here. Click to load it

Right, a cutting knife or folder on a high speed packaging equipment that is
10ms late will certainly ruin the package. (although smart design would have
hardware that takes the time criticality of the software out altogether).

But if your beer is fermented an extra 10ms, not many will notice it.

Rufus

certainly



Re: Again a "realtime" question
Quoted text here. Click to load it


It doesn't really matter how it's done -- it's still a real time
requirement, right?

Quoted text here. Click to load it

That's true, but the timing of beer fermentation is important to the
flavor.  An extra 10ms isn't going to be noticed but an extra two days
could very well ruin the beer.  This would be the kind of soft realtime
system that Paul was pointing out *could* be handled by Windows.

Still, isn't beer too important to leave to the management of a mere
machine?  :-)

Ed


Re: Again a "realtime" question
Quoted text here. Click to load it
usable
that is
have
altogether).
Quoted text here. Click to load it

For the fermentation proces it might be less important, and 10 ms is not
much. But imagine your zipper breaking down after You have hurried to the
toilet, after having drunk several beers (and more), causing a delay of 1
second. That might make a huge difference ;-).

Cheers!
Rene



Re: Again a "realtime" question
Quoted text here. Click to load it
usable
that is
have
altogether).
Quoted text here. Click to load it

The bottle department will also run out of beer, and come asking
where it is and why it takes so long ;)

[snip]


--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)



Re: Again a "realtime" question
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

Especially a machine run by a system with the reputation of
Windoze!  I think they have paraphased the old Zenith motto: "We
take the quality out before the label goes on".

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Again a "realtime" question
Quoted text here. Click to load it

Probably it could be handled by Windows only Monday through Friday,
when staff is around to fix possible Windows hiccups.  A blue screen
on Friday night would leave the fermentation without control for
longer than your proposed 2 days.

Obviously extending a 10ms "hard" realtime requirement to 48 hours
doesn't make it "soft".  It's still a hard one, although possibly
easier to achieve.

A truely "soft" requirement would be if management decides to sell
the beer at a lower price (eg under different brand), when fermentation
went wrong.  Then it would be "desireable" to meet the soft realtime
requirement, but not "necessary".

Marc

Re: Again a "realtime" question
Quoted text here. Click to load it

You're right, and that's an important point.

Quoted text here. Click to load it

If we were certain that two extra days really ruined the beer, then
you'd be right -- it's a hard realtime requirement.  However, an extra
two days might not hurt, either.  It depends on the yeast and the
temperature and a number of other things (although in a real system,
these things could be controlled to some degree).  I's still
characterize it as a "soft" realtime requirement.

Quoted text here. Click to load it

That's another way it could be a soft realtime system.

Ed


Re: Again a "realtime" question

Quoted text here. Click to load it

In a production line system a 0.1 % or 1 ppm failure rate might be
quite acceptable, unless of course, if the failure would cause injury
or death to people.

With any non-hard real time system, you have to evaluate if the
possibility of failure to meet a deadline is acceptable or not.
 
Paul


Site Timeline