Again a "realtime" question

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

Reply to
René
Loading thread data ...

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

Reply to
Voytek

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
Reply to
Andreas Hadler

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.

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 (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

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
 Click to see the full signature
Reply to
Scott Moore

"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
Reply to
George Neuner

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

Reply to
Paul Keinanen

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

Reply to
Paul Keinanen

Dear Voytek, Andreas, Hans-Bernhard, Scott, George and Paul,

Thank You for Your explanations, it's clear to me now. Hope that next time, when I post a question about something embedded, You won't start laughing just by seeing my name ;-).

Sincere greetings, Rene

Reply to
René

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

Reply to
Ed Beroset

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

Reply to
Rufus V. Smith

time,

Well, this post made me laugh! ;^D

Rufus

Reply to
Rufus V. Smith

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

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

Reply to
Ed Beroset

usable

that is

have

altogether).

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

Reply to
René

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.

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

George

--
for email reply remove "/" from address
Reply to
George Neuner

usable

that is

have

altogether).

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)
Reply to
Frank Bemelman

I used to implement RT assembly line machine vision QA apps on NT4 with hard cycles times that ranged from 50ms for a single part up to

1.4s for 192 parts. A few systems supported flexible cycling through interlocks with the conveyor, but most simply had a trigger and a specified maximum response time. Most systems supported several different CPU, camera and algorithm configurations so processing times were greatly variable, but we tested and guaranteed response time for marketed hardware configurations - oddball configurations were supported but were not guaranteed.

Even the systems that supported flexible cycles were spec'd hard because customer use of the conveyor interlocks was optional. A few customers used the interlocks simply as a failsafe, but most used them to drive their conveyors faster either by timing the conveyor to the average response and delaying if the QA system wasn't ready or by directly linking advance to the ready signal and variably cycling the conveyor.

Usable performance with aspirations to real time 8-)

George

--
for email reply remove "/" from address
Reply to
George Neuner

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

Reply to
Paul Keinanen

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.

Reply to
Jeff Fox

... snip ...

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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.