questions on boot parameters

Hi, I have several questions about the OSLOADER boot parameters. Some of
these parameters are backed by an article, but for other settings I can
hardly find any information.

The /USELEGACYAPICMODE switch, which set the APIC in ‘legacy APIC mode,’.
Does this enable APIC virtual wire mode ? Does this disable the local APIC
as well, so that it behaves as a legacy 8259 PIC ? If not is there another
switch for that ?

Can anybody tell me about the CONFIGFLAGS parameters other than that they
are processor specific ? Is there any information I can find in the CPU
manuals ? (I couldn’t so far)

Then about /CLUSTERMODEADDRESSING and /RESTRICTAPICCLUSTER. Whatever values
I put in there, I do not see them reflected. The only thing
that I observe is that the system behaves in a different way, interrupts are
spread between processors instead of always sent to the lowest processor but
the parameters do not appear to be honored. Can anyone please tell me more
about them ?

Any replies will be greatly appreciated.

//Daniel

The problem with the word “legacy” is that it’s only meaning (in
engineering) is “thing that I wish that I didn’t have to deal with any
more.” So to understand what it means in context, you have to know who
wrote it and when, and possibly how old that person is. USELEGACYAPICMODE
was written fairly recently by a guy who was about 30 at the time. So his
definition of “legacy” is a lot more recent than yours. He was talking
about forcing the processors into XAPIC mode when X2APIC mode is an option.

If you want to actually put the APIC system into virtual wire mode, the
right incantation is:

bcdedit /set hal halacpi.dll

The only thing that I can say about your other questions is that that’s
exactly what I would expect those settings to do at a high level. How is it
that you think that they’re not “reflected?” What would your definition of
“reflected?” be?

Of course, if you actually say what you’re trying to accomplish, I might be
able to tell you how to do it.

Jake Oshins
Windows Kernel Team

This message offers no warranties and confers no rights.


wrote in message news:xxxxx@ntdev…

Hi, I have several questions about the OSLOADER boot parameters. Some of
these parameters are backed by an article, but for other settings I can
hardly find any information.

The /USELEGACYAPICMODE switch, which set the APIC in ‘legacy APIC mode,’.
Does this enable APIC virtual wire mode ? Does this disable the local APIC
as well, so that it behaves as a legacy 8259 PIC ? If not is there another
switch for that ?

Can anybody tell me about the CONFIGFLAGS parameters other than that they
are processor specific ? Is there any information I can find in the CPU
manuals ? (I couldn’t so far)

Then about /CLUSTERMODEADDRESSING and /RESTRICTAPICCLUSTER. Whatever values
I put in there, I do not see them reflected. The only thing
that I observe is that the system behaves in a different way, interrupts are
spread between processors instead of always sent to the lowest processor but
the parameters do not appear to be honored. Can anyone please tell me more
about them ?

Any replies will be greatly appreciated.

//Daniel

Jake, thanks for your reply.

My customer has a latency sensitive device which works well most of the
time. I am helping him to create an environment in which his device can meet
its deadlines, so this is for a dedicated, controlled configuration.

We have a OS supported DPC redirection scheme in place which works great and
allows us to liberate certain processors from executing DPCs. This works
great except in case where an ISR occurs which also executes a DPC which is
then executed on the same undesired processor. We have done a great job of
freeing processors from executing threads and DPCs so that they can be
optimally used for latency sensitive tasks but ultimately would like to turn
this into an exact science.

To complete, what we need is to force all interrupts to be sent to the
processor with the lowest APIC node, no matter what chipset in the system.
Instead of telling them they need a system with certain chipset X, it would
be great if there were a way to force all interrupts to occur on only a
single processor always. Interrupt affinities and PNP request filtering as
it appears only offer limited possibilities.

We have tools to verify exactly what is running on each processor, with the
exception of under the hood magic that is not visible to Windows. What would
be great is if we could limit the processors on which interrupts occur on
systems with chipsets which by default spread interrupts across processors
instead of always sending them to the processor with the lowest APIC node.
Whether this can be achieved as a side effect of a testing feature or
something else or by a dedicated feature does not matter.

//Daniel

“Jake Oshins” wrote in message
news:xxxxx@ntdev…
> The problem with the word “legacy” is that it’s only meaning (in
> engineering) is “thing that I wish that I didn’t have to deal with any
> more.” So to understand what it means in context, you have to know who
> wrote it and when, and possibly how old that person is. USELEGACYAPICMODE
> was written fairly recently by a guy who was about 30 at the time. So his
> definition of “legacy” is a lot more recent than yours. He was talking
> about forcing the processors into XAPIC mode when X2APIC mode is an
> option.
>
> If you want to actually put the APIC system into virtual wire mode, the
> right incantation is:
>
> bcdedit /set hal halacpi.dll
>
> The only thing that I can say about your other questions is that that’s
> exactly what I would expect those settings to do at a high level. How is
> it that you think that they’re not “reflected?” What would your
> definition of “reflected?” be?
>
> Of course, if you actually say what you’re trying to accomplish, I might
> be able to tell you how to do it.
>
> Jake Oshins
> Windows Kernel Team
>
> This message offers no warranties and confers no rights.
>
> -----------------------------------------------------------
>
> wrote in message news:xxxxx@ntdev…
>
> Hi, I have several questions about the OSLOADER boot parameters. Some of
> these parameters are backed by an article, but for other settings I can
> hardly find any information.
>
> The /USELEGACYAPICMODE switch, which set the APIC in ‘legacy APIC mode,’.
> Does this enable APIC virtual wire mode ? Does this disable the local APIC
> as well, so that it behaves as a legacy 8259 PIC ? If not is there another
> switch for that ?
>
> Can anybody tell me about the CONFIGFLAGS parameters other than that they
> are processor specific ? Is there any information I can find in the CPU
> manuals ? (I couldn’t so far)
>
> Then about /CLUSTERMODEADDRESSING and /RESTRICTAPICCLUSTER. Whatever
> values
> I put in there, I do not see them reflected. The only thing
> that I observe is that the system behaves in a different way, interrupts
> are
> spread between processors instead of always sent to the lowest processor
> but
> the parameters do not appear to be honored. Can anyone please tell me more
> about them ?
>
> Any replies will be greatly appreciated.
>
> //Daniel
>
>
>
>
>
>
>
>

> My customer has a latency sensitive device which works well most of the time. I am helping him to

create an environment in which his device can meet its deadlines, so this is for a dedicated,
controlled configuration.

Well, everything depends on the precise scenario…

As long as you have soft-RT requirements “works well most of the time’” is acceptable.
If there are hard-RT requirements, the only thing that can work here is a custom HAL - you have to be in a total control of interrupt handling. AFAIK, this is not an option any more, or at least not a supported one. Therefore, in case of hard RT requirements would strongly advise you to tell your customer to change the target OS…

Anton Bassov

For example, Windows is not a suitable platform for life-critical or
safety-critical systems, where the consequence of missing a deadline could
be death or serious injury, but it is more than capable of running a stock
trading system where the consequence of missing a deadline is that an
opportunity to make money was lost. Depending on where your device falls on
this spectrum, you can make an engineering decision about the platform, OS,
etc.

wrote in message news:xxxxx@ntdev…

My customer has a latency sensitive device which works well most of the
time. I am helping him to
create an environment in which his device can meet its deadlines, so this
is for a dedicated,
controlled configuration.

Well, everything depends on the precise scenario…

As long as you have soft-RT requirements “works well most of the time’” is
acceptable.
If there are hard-RT requirements, the only thing that can work here is a
custom HAL - you have to be in a total control of interrupt handling. AFAIK,
this is not an option any more, or at least not a supported one. Therefore,
in case of hard RT requirements would strongly advise you to tell your
customer to change the target OS…

Anton Bassov

There are a couple RT substrates that run Windows as the lowest-priority
thread, but do things like support interrupts being routed to DLL code
with guaranteed latencies. But you otherwise cannot do hard-RT from
Windows. One of my major skills was building Windows interfaces to
embedded RT devices, where the device either had a RTOS of its own or was
coded “from scratch”. It was responsible for all the RT management, and
all I did was make a nice GUI control panel and/or draw pretty graphs, and
if I lost a data packet, we could interpolate the point if necessary. The
mission-critical stuff, such as the code that kept the liquid CO2
chromatograph from exploding, was in the embedded system (LIQUID CO2?
Hey, man, eveyone knows solid CO2 sublimates to its gaseous state and it
has no liquid phase! Yeah, right. That’s at STP (Standard Temperature
and Pressure, 68F and 14.7psi. It behaves somewhat differently at
10,000psi, which is why explosion is a very real danger).
joe

For example, Windows is not a suitable platform for life-critical or
safety-critical systems, where the consequence of missing a deadline could
be death or serious injury, but it is more than capable of running a stock
trading system where the consequence of missing a deadline is that an
opportunity to make money was lost. Depending on where your device falls
on
this spectrum, you can make an engineering decision about the platform,
OS,
etc.

wrote in message news:xxxxx@ntdev…

> My customer has a latency sensitive device which works well most of the
> time. I am helping him to
> create an environment in which his device can meet its deadlines, so
> this
> is for a dedicated,
> controlled configuration.

Well, everything depends on the precise scenario…

As long as you have soft-RT requirements “works well most of the time’”
is
acceptable.
If there are hard-RT requirements, the only thing that can work here is a
custom HAL - you have to be in a total control of interrupt handling.
AFAIK,
this is not an option any more, or at least not a supported one.
Therefore,
in case of hard RT requirements would strongly advise you to tell your
customer to change the target OS…

Anton Bassov


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

My belief instead is that nowadays Windows can be configured to work as a
hard RTOS on selected hardware and with special software running, by
eliminating the factors that (supposedly) made this impossible. I also
believe this can be done without a custom HAL and without booting the system
with only a limited number of processors avaiable to Windows.

Regardless of whether that is true or false, what I am looking for is a sure
fire way to limit the processors that receive interrupts in a system. There
are several options but
I am hoping to find a supported way through software without further
limiting the hardware that can be used to support the solution.

//Daniel

wrote in message news:xxxxx@ntdev…
> There are a couple RT substrates that run Windows as the lowest-priority
> thread, but do things like support interrupts being routed to DLL code
> with guaranteed latencies. But you otherwise cannot do hard-RT from
> Windows. One of my major skills was building Windows interfaces to
> embedded RT devices, where the device either had a RTOS of its own or was
> coded “from scratch”. It was responsible for all the RT management, and
> all I did was make a nice GUI control panel and/or draw pretty graphs, and
> if I lost a data packet, we could interpolate the point if necessary. The
> mission-critical stuff, such as the code that kept the liquid CO2
> chromatograph from exploding, was in the embedded system (LIQUID CO2?
> Hey, man, eveyone knows solid CO2 sublimates to its gaseous state and it
> has no liquid phase! Yeah, right. That’s at STP (Standard Temperature
> and Pressure, 68F and 14.7psi. It behaves somewhat differently at
> 10,000psi, which is why explosion is a very real danger).
> joe
>> For example, Windows is not a suitable platform for life-critical or
>> safety-critical systems, where the consequence of missing a deadline
>> could
>> be death or serious injury, but it is more than capable of running a
>> stock
>> trading system where the consequence of missing a deadline is that an
>> opportunity to make money was lost. Depending on where your device falls
>> on
>> this spectrum, you can make an engineering decision about the platform,
>> OS,
>> etc.
>>
>> wrote in message news:xxxxx@ntdev…
>>
>>> My customer has a latency sensitive device which works well most of the
>>> time. I am helping him to
>>> create an environment in which his device can meet its deadlines, so
>>> this
>>> is for a dedicated,
>>> controlled configuration.
>>
>> Well, everything depends on the precise scenario…
>>
>> As long as you have soft-RT requirements “works well most of the time’”
>> is
>> acceptable.
>> If there are hard-RT requirements, the only thing that can work here is a
>> custom HAL - you have to be in a total control of interrupt handling.
>> AFAIK,
>> this is not an option any more, or at least not a supported one.
>> Therefore,
>> in case of hard RT requirements would strongly advise you to tell your
>> customer to change the target OS…
>>
>> Anton Bassov
>>
>>
>> —
>> 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
>>
>
>
>
>
>

In order to understand how naive such a belief is all you have to do is to consider the following scenario.

Let’s say you have a dedicated CPU that runs interrupts and DPCs - no other CPU in the system does it. Now imagine a thread running on this CPU takes an interrupt which queues a DPC. If a thread was holding some dispatcher-level synch construct (for example, FAST_MUTEX) at the time it will be unable to release it until the entire DPC queue gets flushed (and it may get quite long sometimes, for example, when network activity is heavy). If a real-time thread running on another CPU needs this lock it will have to wait AT LEAST until DPC queue gets flushed. Now consider what happens if some DPC routine signals an event and this action results in context switch on this dedicated CPU - now your RT thread’s delay gets few orders of magnitude longer.

As you can see, you are just wasting your time - making all ISRs and DPCs run on a dedicated CPU still does not solve your problem in any possible way. You just cannot make GPOS meets hard-RT requirements.
Period.

Well, the “supported” option is to set interrupt affinity, but, as you say, the OS simply ignores your requests. This is why you need a custom HAL - you have to set interrupt affinity yourself by programming IOAPIC
accordingly…

Anton Bassov

ideally the code running on the dedicated processor should not be making any OS calls at all. The only other code that runs on there is the dispatcher after a clock interrupt. I am pretty sure the dispatcher doesnt need a lock that is not available until the DPC queue on another processor has been drained.

About an event getting signalled which causes a thread to wake up which then could preempt a dedicated thread running on a reserved processor: we have taken measures to guarantee that only our dedicated thread runs on that processor and nothing else. The dedicated thread has acquired a treatment of non-preemptive scheduling. While it’s unconventional, there are Windows features which simply allow you to get such a guarantee.

//Daniel

> ideally the code running on the dedicated processor should not be making any OS calls at all. The only

other code that runs on there is the dispatcher after a clock interrupt

Yes, but how are you going to enforce it??? After all, IIRC, your requests for thread affinities are not guaranteed to be granted by the OS, right. Therefore, even if you try to put a dedicated CPU out of play completely by setting thread affinities of all threads in the system to all CPUs other than your target one there is simply no guarantee that you will succeed. As you can see it yourself (your requests for setting interrupt affinities don’t seem to be granted, right) the OS makes quite a few decisions for you, no matter what you request is. It has a good reason to - its main objective is to optimize a general-case performance, so that your requests may seem unreasonable to it.

The funniest thing here is, of course, that even if you succeed with getting a dedicated CPU for handling interrupts and DPCs you are still a subject to priority inversion - after all, you cannot control what happens behind the scenes when you make a system call, right. Therefore, if your RT app makes a system call which involves mutex acquisition and mutex is being held by some low-priority thread that runs on another CPU,
your RT app is still a subject to unpredictable delay, despite the fact that neither of these two CPUs deals with interrupts and DPCs…

Anton Bassov

Anton, afaik Windows, it always honours thread affinty requests. Always, that is unless there is some weird redirection scheme active under the hood.

//Daniel

Not just that. The consequence can also be failure to sell the assets at
the “right” time. It’s much worse than losing opportunity to make money in
my personal experience learned the hard way.

Calvin

On Thu, May 17, 2012 at 5:55 PM, m wrote:

> For example, Windows is not a suitable platform for life-critical or
> safety-critical systems, where the consequence of missing a deadline could
> be death or serious injury, but it is more than capable of running a stock
> trading system where the consequence of missing a deadline is that an
> opportunity to make money was lost. Depending on where your device falls
> on this spectrum, you can make an engineering decision about the platform,
> OS, etc.
>
> wrote in message news:xxxxx@ntdev…
>
>
> My customer has a latency sensitive device which works well most of the
>> time. I am helping him to
>> create an environment in which his device can meet its deadlines, so this
>> is for a dedicated,
>> controlled configuration.
>>
>
> Well, everything depends on the precise scenario…
>
> As long as you have soft-RT requirements “works well most of the time’”
> is acceptable.
> If there are hard-RT requirements, the only thing that can work here is a
> custom HAL - you have to be in a total control of interrupt handling.
> AFAIK, this is not an option any more, or at least not a supported one.
> Therefore, in case of hard RT requirements would strongly advise you to
> tell your customer to change the target OS…
>
> Anton Bassov
>
> —
> 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=ListServerhttp:
></http:>

Well, missing the opportunity to save money is similar with respect to it comparability to death or serious injury … but I take your point; a better example would have been delay while playing internet radio

“Calvin Guan (news)” wrote in message news:xxxxx@ntdev…
[quote]
the consequence of missing a deadline is that an opportunity to make money was lost.
[/quote]

Not just that. The consequence can also be failure to sell the assets at the “right” time. It’s much worse than losing opportunity to make money in my personal experience learned the hard way.

Calvin

On Thu, May 17, 2012 at 5:55 PM, m wrote:

For example, Windows is not a suitable platform for life-critical or safety-critical systems, where the consequence of missing a deadline could be death or serious injury, but it is more than capable of running a stock trading system where the consequence of missing a deadline is that an opportunity to make money was lost. Depending on where your device falls on this spectrum, you can make an engineering decision about the platform, OS, etc.

wrote in message news:xxxxx@ntdev…

My customer has a latency sensitive device which works well most of the time. I am helping him to
create an environment in which his device can meet its deadlines, so this is for a dedicated,
controlled configuration.

Well, everything depends on the precise scenario…

As long as you have soft-RT requirements “works well most of the time’” is acceptable.
If there are hard-RT requirements, the only thing that can work here is a custom HAL - you have to be in a total control of interrupt handling. AFAIK, this is not an option any more, or at least not a supported one. Therefore, in case of hard RT requirements would strongly advise you to tell your customer to change the target OS…

Anton Bassov


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

> Well, missing the opportunity to save money is similar with respect to it comparability to death

or serious injury …

In this context, yes - both are the results of computation errors that, in turn, result from missing deadlines. This is what makes hard-RT requirements different from the soft-RT ones - in the former case (missed_deadline==computation_error)? TRUE:FALSE line always evaluates to TRUE, i.e. a single
missed deadline is sufficient for making the program fail. It does not necessarily mean that consequences of this failure are always truly disastrous (i.e. loss of life, injuries, chemical contamination that results in evacuation of the whole city,etc) . The only thing it means is that computation fails because of a missed deadline. For example, consider what happens if a computer-controlled sprinkler that paints cars on the conveyor line starts spraying paint a little bit later than it is expected to. Although this is not the question of life and death, the cars(s) may end up with some unpainted strips left, which means the job the computer controls has not been done properly because of a missed deadline. Your example of failing to place an order at the right moment firmly belongs in the same class of errors…

a better example would have been delay while playing internet radio

Exactly…

This is a classical example of a task with soft-RT requirements - although you have to meet deadlines
most of the times in order to get the acceptable performance, missing a deadline on any particular occasion does not make the whole thing fail…

Anton Bassov

> My belief instead is that nowadays Windows can be configured to work as a

hard RTOS

There are some softtware titles for Windows which intercept the whole IDT and inject themselves as some supervisor below Windows, running Windows as one of the tasks.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

>> My belief instead is that nowadays Windows can be configured to work as

> a
> hard RTOS

There are some softtware titles for Windows which intercept the whole IDT
and inject themselves as some supervisor below Windows, running Windows as
one of the tasks.

****
Windows cannot be configured to work as an RTOS. Not possible. As
pointed out, though, an RTOS kernel can be set to run Windows as one of
its tasks.

I used to have a URL for one such company, but it is on my dead machine
(which is supposed to return this Thursday…or Real Soon Now, whichever
comes first)
joe
****


Maxim S. Shatskih
Windows DDK MVP
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

> There are some softtware titles for Windows which intercept the whole IDT

and inject themselves as some supervisor below Windows, running Windows as one of the tasks

AFAIK, they are iRMX derivatives/successors, at least conceptually. These days most of x86-based systems support VMX/SVM extensions, which simplifies the development of hypervisors with RT capacities…

Anton Bassov

“Failure” is also a highly-subjective notion. If a response to a game
controller is delayed enough that the gamer misses a target or fails to
duck in time, absolutely nothing of any “value” has been compromised. But
the gamer will stop using that product. Internet Radio will fail if there
are a small integer number of 1ms delays per minute; these are perceived
as “pops” or “clicks”, and the subjective response of the listener is to
stop using the service. Nothing was lost, every point on the audio wave
was played, but those 1ms dropouts are untenable.

Windows mostly fakes being RT for media, and fakes it so successfully that
nearly all of the time, the users don’t notice. But oh, when they do!
joe

> Well, missing the opportunity to save money is similar with respect to
> it comparability to death
> or serious injury …

In this context, yes - both are the results of computation errors that, in
turn, result from missing deadlines. This is what makes hard-RT
requirements different from the soft-RT ones - in the former case
(missed_deadline==computation_error)? TRUE:FALSE line always evaluates to
TRUE, i.e. a single
missed deadline is sufficient for making the program fail. It does not
necessarily mean that consequences of this failure are always truly
disastrous (i.e. loss of life, injuries, chemical contamination that
results in evacuation of the whole city,etc) . The only thing it means is
that computation fails because of a missed deadline. For example, consider
what happens if a computer-controlled sprinkler that paints cars on the
conveyor line starts spraying paint a little bit later than it is expected
to. Although this is not the question of life and death, the cars(s) may
end up with some unpainted strips left, which means the job the computer
controls has not been done properly because of a missed deadline. Your
example of failing to place an order at the right moment firmly belongs in
the same class of errors…

> a better example would have been delay while playing internet radio

Exactly…

This is a classical example of a task with soft-RT requirements - although
you have to meet deadlines
most of the times in order to get the acceptable performance, missing a
deadline on any particular occasion does not make the whole thing
fail…

Anton Bassov


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

> My belief instead is that nowadays Windows can be configured to work as a

hard RTOS
****
A fascinating myth, but I am unaware of any facts that support this.
****
on selected hardware and with special software running,
****
There are a couple products out that are hard real-time systems, and they
run Windows as a subtask, usually at the lowest priority. This is not at
all the same as saying “Windows can be configured to work as a hard RTOS”.
*****
by
eliminating the factors that (supposedly) made this impossible.
*****
More mythology. You don’t know much about real-time design, I gather. In
real-time design, there are rarely factors that dominate more than the
fundamental software architecture of your RT app. But then, maybe I’m
biased; after all, I have only written hard-RT code and once ran a
graduate seminar in issues of RTOS and RTApp design.
****
I also
believe this can be done without a custom HAL and without booting the
system
with only a limited number of processors avaiable to Windows.
****
Let’s see: booting with fewer processors reduces the amount of available
CPU cycles. And this enhances RT response HOW?
****

Regardless of whether that is true or false, what I am looking for is a
sure
fire way to limit the processors that receive interrupts in a system.
****
And this will accomplish exactly what? Oh, yes, overload some set of
processors to handle ISRs and DPCs, thus increasing overall response
latency. This is going to enhance hard RT response HOW?
****
There
are several options but
I am hoping to find a supported way through software without further
limiting the hardware that can be used to support the solution.
****
AFAIK, the available RT kernels that support windows run on very
plain-vanilla commodity hardware.

One example is at http://www.intervalzero.com/
joe
****

//Daniel

wrote in message news:xxxxx@ntdev…
>> There are a couple RT substrates that run Windows as the lowest-priority
>> thread, but do things like support interrupts being routed to DLL code
>> with guaranteed latencies. But you otherwise cannot do hard-RT from
>> Windows. One of my major skills was building Windows interfaces to
>> embedded RT devices, where the device either had a RTOS of its own or
>> was
>> coded “from scratch”. It was responsible for all the RT management, and
>> all I did was make a nice GUI control panel and/or draw pretty graphs,
>> and
>> if I lost a data packet, we could interpolate the point if necessary.
>> The
>> mission-critical stuff, such as the code that kept the liquid CO2
>> chromatograph from exploding, was in the embedded system (LIQUID CO2?
>> Hey, man, eveyone knows solid CO2 sublimates to its gaseous state and it
>> has no liquid phase! Yeah, right. That’s at STP (Standard Temperature
>> and Pressure, 68F and 14.7psi. It behaves somewhat differently at
>> 10,000psi, which is why explosion is a very real danger).
>> joe
>>> For example, Windows is not a suitable platform for life-critical or
>>> safety-critical systems, where the consequence of missing a deadline
>>> could
>>> be death or serious injury, but it is more than capable of running a
>>> stock
>>> trading system where the consequence of missing a deadline is that an
>>> opportunity to make money was lost. Depending on where your device
>>> falls
>>> on
>>> this spectrum, you can make an engineering decision about the platform,
>>> OS,
>>> etc.
>>>
>>> wrote in message news:xxxxx@ntdev…
>>>
>>>> My customer has a latency sensitive device which works well most of
>>>> the
>>>> time. I am helping him to
>>>> create an environment in which his device can meet its deadlines, so
>>>> this
>>>> is for a dedicated,
>>>> controlled configuration.
>>>
>>> Well, everything depends on the precise scenario…
>>>
>>> As long as you have soft-RT requirements “works well most of the
>>> time’”
>>> is
>>> acceptable.
>>> If there are hard-RT requirements, the only thing that can work here is
>>> a
>>> custom HAL - you have to be in a total control of interrupt handling.
>>> AFAIK,
>>> this is not an option any more, or at least not a supported one.
>>> Therefore,
>>> in case of hard RT requirements would strongly advise you to tell your
>>> customer to change the target OS…
>>>
>>> Anton Bassov
>>>
>>>
>>> —
>>> 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
>

xxxxx@flounder.com wrote:

“Failure” is also a highly-subjective notion.

I thought the saying was “Failure is not an option.”


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