Yep, absolutely, once I modelled network traffic buffer requirement during
mid 80’s for IBM network controller, wrote internal paper, etc. But I’m sure
in my brain some oxidation went in, it decayed a lot. Klienrock used to be
our mentor.
It sounds like you are after the (in)famous I/O channel of mainframe. For
SCSI, I will get to it later, so if I find anything interesting and not
propritary ( I would post here ) for now it is SATA I’m after. Not much I
can talk about, I have to keep my mouth shut …
-prokash
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Thursday, January 15, 2004 10:55 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NMI’s etc.
Well, if the arrival rate is larger than the departure rate, you have a
bottleneck anyway ! The point of the queue is to smooth it out: even if the
arrival rate is only larger during a small enough period of time, the queue
can absorb that peak, as long as the average arrival rate is smaller than
the average departure rate over a decently long period of time, and also, of
course, as long as you have enough buffering space in the I/O card. Another
point of buffering would be, if we can save interrupts, for example, by
batching interrupts from the drive, so that each card-to-processor interrupt
conveys multiple disk interrupts to the processor. I don’t know enough about
current SCSI gear to know if this is true, but it has been tried before in
the mainframe world.
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Sinha, Prokash
Sent: Thursday, January 15, 2004 1:31 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NMI’s etc.
Very interesting !. Thanks.
Yes, that is why interrupt latency tries to say that it is that HW time.
When there is a need, sure that is what to look at. Buffering, queueing and
all those are provide more flexibilities. As we say if the arrival rate is
slightly higher than departure rate, queue itself is a bottleneck, and there
are lots of studies around it.
-prokash
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Thursday, January 15, 2004 7:21 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NMI’s etc.
Note that the elapsed time between the interrupt is signaled and the ISR
gets control is often 100% hardware, and the issue may not be the OS but how
the hardware and the buses are laid out. If you’re talking response time,
it’s possibly a question of optimizing the hardware path from the peripheral
to the processor. However, if you’re talking throughput, the real issue
however is the interrupt service time of the peripheral, that is, how long
it’s going to be between the time a peripheral interrupts and the time that
peripheral is able to interrupt again: and this is the difference, say,
between a PDA and a high volume network server. And this is one instance
where an I/O processor helps, because it can act as an effective buffer
between the peripheral and the CPU and the OS: the I/O processor handles the
peripheral, avoiding CPU loading issues with competing ISRs and the need to
reset PIC bits from CPU code.
In that line, some old machines used to have interrupt queuing by hardware,
so that you could have multiple interrupts pending per i/o controller, and
that would ease the requirement that the ISR re-enabled interrupts, because
they wouldn’t have been disabled to begin with. The ISR could count on not
being interrupted at the same IRQL level, or sometimes even at higher level,
because those interrupts would have been queued by the hardware. Some other
machines just delegated interrupt handling to I/O processors, and
implemented a queued interface between the processors and the central
processor. The Sperry DCP/40, for example, did all its I/O in programmable
I/O processors; when the item was ready, the I/O processor would queue the
item to a hardware queue to be read by the CPU. The CPU hardware queues
operated in such a way that you could “arm” the queue: when a queue was
armed with a certain threshold, and an item was enqueued such that the
threshold was crossed, the hardware would enqueue a “software attention
item” into another queue, typically an OS dispatcher’s ready queue. So this
system had no ISRs in the CPU, it only had dispatch routines which would be
run directly by the OS switcher. The dispatch routine would then empty the
queue, rearm it, and exit, so that the next item deposited by the I/O
processor caused a new software attention item to be enqueued to the
dispatch queue.
We also used to have terminal simulators. This was a program that ran on a
mainframe and made it look like hundreds of terminals. This simulator could
be programmed to generate network traffic with a wide range of parameters,
so that we could put hardware probes in the server and measure such things
as interrupt latency and service time. Note the difference, interrupt
latency controls the minimum response time, but interrupt service time is a
factor in the total service time of a transaction, which can be used to
build a queued model of the performance of the system. So, for example,
sometimes you not only want to limit the interrupt latency to such and such
microseconds, but you want to state that 95% or 99% of the transactions are
answered within so many milliseconds, and that involves looking at the
transaction as a whole and applying queuing theory to it. And then, the
final proof would be to have the simulator feed the system with enough
volume to see if the performance was adequate.
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Prokash Sinha
Sent: Thursday, January 15, 2004 9:45 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NMI’s etc.
Mat,
I use motorola, and I used sprint PCS, so there might be a good chance that
your code (with chipset) being used in one of those :).
Sure, I totally agree with you on all you said here …
Yes in most cases the interrupt latency is defined the way you explained.
And it is Okay for us with that definitation, since the ISR writter(s) would
know what (s)he is left with to respond in time.
Windows CE is still considered ( or at least some circles think) as
soft-real time. ALSO I THINK THERE IS SOME OFFICIAL DEFINITION FOR HARD AND
SOFT REAL TIME IN TERMS OF WORST CASE LATENCY. In the past around 2.0
version people did not think that it is a good real time system(s), since
there was a period of time in the dispatcher, when other interrupt(s) were
masked out, then on 3.0 it is totally preemptive, so an higher priority can
hijack anytime. There were official study (benchmarking) that was published
either on IEEE computer Journal or Embedded programming that it surely fairs
well. BUT AS I SAID, THERE IS THAT SEGMENT WHO CAN USE IT SINCE ONLY A SMALL
PART OF HAL/KERNEL CAN NOT BE TAKEN OUT OR CHANGED ( FOR EXAMPLE DEVICE
MANAGER !!!) but most of the other stuff are very configurable, even the
base infrastructure for serial debug. I NEVER TRIED TO GO AFTER THE
MINIMALIST APPROACH ON IT, ONE DAY SOON, I MIGHT HAVE TO SEE WHAT IS THE
ALMOST ABSOLUTE FOOTPRINT I CAN HAVE (SOME ROUGH ESTIMATE).
Many thanks for the info(s) …
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@3Dlabs.com
Sent: Thursday, January 15, 2004 2:08 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NMI’s etc.
Prokash,
Yes, every user of “real time” has their own definition of what it means.
I used to work in a company that produces a commercial real time OS, which
if you’ve ever used a GSM-based mobile phone (west coast US + NY, DC area
etc, europe, asia, australia and so on), you’ve most likely “used” some of
“my” code…
Whilst this was not distributed as source code, it would give deterministic
worst case, and had many functions to configure different parts of the OS to
fit the purpose of the system that it’s put in. It’s available for many
different 16 and 32-bit processors (and even 8-bit ones).
The main feature of this particular OS was to avoid increasing
latency/timing when number of tasks increase [obviously, in a modern
processor, the number of tasks will have some effect on for instance cache
hit rates, etc], so that if you have two tasks or a thousand, you’d get the
same timing. This requires a lot of clever managing of queues and priorities
etc.
Now, this is a real real-time OS. When I worked on the GSM base station at
Ericsson, they used a 25MHz AMD 29243 processor. The worst case interrupt
latency was something like 40 microseconds, which means about 1000 clock
cycles. We had real time requirements that meant that one particular
interrupt had to be serviced (and completed) after 100 microsecond,
otherwise all current calls would get lost. If we missed by another 40
microseconds, the hardware would automatically reset.
On a 100MHz 486, the interrupt latency was about 7 microseconds, worst case.
Windows CE is not even close to this sort of real-time. Last I heard, they
were trying to get interrupt latency “lower than 300 us”, on a something
comparable to a 100MHz 486.
By the way, when I’m saying interrupt latency, I’m not talking about the
time it takes to actually issue the IACK, but the time from the interrupt
pin going active until the interrupt service routine is actually dealing
with the interrupt. I’m not sure what definition Windows CE people have.
–
Mats
Well,
RTOS is somewhat different in taste. Usually people look at some of
the following -
- Deterministic latency (worst case)
- Total configurability, so the footprint has to be as low as
possible. 3. Total source control, so that h/w components can be
choosen ( ie should
an UART have a 16byte FIFO or not, if not then how quickly we
need to poll
or respond to interrupt, should we need SRAM or DRAM (time is
a factor)
etc., etc.)
- Others …
So it might be really hard to back fill these w/o exposing allmost all
the NT code. But CE and embedded NT is for that, though not for
very very small
footprint( < 2k). AS AN EXAMPLE ON A BASE LEVEL 8051 family,
you can have
only two priorities for interrupt, if a timer ISR and a
serial unit ISR is
used, there has to be total control about who gets what
priority, and there
are others even to put instruction on RAM or flash. Similarly
of ARM based
SOC, we want to have absoulte control, so it is better to go after the
source, phar-lap, microC, ecos and others are our choices.
Again there is
hacking required to tune these stuff too.
-prokash
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Nick Ryan
Sent: Wednesday, January 14, 2004 11:25 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] NMI’s etc.
Out of curiousity, if it really is possible to real-time enable an
operating system like Windows or Linux without much compromising the
design and behavior of the OS, why can’t the support be built-in to
the kernel (perhaps enabled with an option of some sort)? This seems
to me like a missed business op for Microsoft, since if I’m gonna put
a RTOS into a device, assuming the kernel needs to be hacked for
RTOS support,
I’ll go for Linux (resting easy since I know the hackers had access to
the source code for the kernel they had to hack).
xxxxx@3Dlabs.com wrote:
> Gary,
>
> I agree, bad design is bad design. I’m not saying I’m
recommending “my
> solution”.
>
> By the way, NMI can be interrupted! By SMI! 
>
> Also, NMI and any other IRQL can possibly be “interrupted” by any
> exception that the processor may perform due to whatever
operation it’s
> performing, memory access violations, divide by zero,
illegal opcode,
> FPU traps, and so on. No way you can stop those, whatever you do.
>
> NMI’s remind me of a company I visited whilst working at
AMD, they were
> using NMI as a way to build a RTOS behind Windows. Very clever. They
> even had a prioritized interrupt controller, so you could
have some 8
> different inputs + a timer to run your real time apps. Real
time apps
> with Windows interface. And when I say real time, I mean 4-6
> microseconds interrupt latency, worst case.
>
> –
> Mats
>
> -----Original Message-----
> *From:* Gary G. Little [mailto:xxxxx@sbcglobal.net]
> *Sent:* Tuesday, January 13, 2004 8:01 PM
> *To:* Windows System Software Devs Interest List
> *Subject:* Re:[ntdev] global kernel lock
>
> A bad design by any other name is still a bad design.
Besides the
> assembly sequence “pusfd/cli/…/popfd” cannot
absolutely prevent
> pre-emption, nor has it ever, even in the glory days of
DOS. It does
> not prevent NMI from interrupting the system. You can
raise IRQL to
> an arbitrary high level, but about the only way you can
your device
> will not be interrupted is to tie your device to NMI
… and then
> you have no support APIs to assist you in hooking your
interrupt nor
> syncing access to your code.
>
> –
> Gary G. Little
> Seagate Technologies, LLC
>
> > mailto:xxxxx> wrote
> > in message news:xxxxx@ntdev…
> >
> > Michael,
> >
> > Sorry to have to ask, but: Why?
> >
> > Unless you’re building a debugger or some such,
> there’s really
> > no valid case for “Must not be interrrupt by
> another thread”.
> > There’s probably something wrong in your design if “must” do
> > this. You should ever only need to block threads that are
> > accessing the same data as your own thread.
> >
> > However, if you really want to do BAD design in
> your driver, a
> > KeRaiseIRQL() call with sufficently high IRQL will
> do the job.
> > Obviously followed by KeLowerIRQL(oldIRQL). [
> OldIRQL is passed
> > back from the Raise function]
> >
> > It’s EXTREMELY bad practice to do this, however.
> >
> > You should never do this in a production driver.
> >
> > If you explain what you’re trying to achieve, to
> the members of
> > this mailing list, I’m sure someone will suggest
> some suitable
> > solution to the problem.
> >
> > Further, unless this lock is really short, you’ll
> be in trouble
> > with Microsoft once they start using the “maximum interrupt
> > latency” method to achieve real time video and audio, which
> > states that any driver must not block interrupts
> for more than X
> > microseconds per second. If you block all interrupts and/or
> > threads, you probably can’t fulfill this criteria,
> unless it’s
> > like three lines of code in between raise and lower IRQL.
> >
> > –
> > Mats
> >
> > -----Original Message-----
> > From: xxxxx@sonydadc.com
> > [mailto:xxxxx@sonydadc.com]
> > Sent: Tuesday, January 13, 2004 4:05 PM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] global kernel lock
> >
> >
> > Hello,
> >
> > I have a small piece of code within my driver,
> which must
> > not be interrupted by any other thread.
> > My 1st thought was to use _asm cli, but I dont
> know if this
> > will work on multi processor systems
> > (or even p4 with hyperthreading) as well.
> >
> > Is there an API call to prevent interruption?
> > Or what is the proper way to achieve this.
> >
> >
> >
> > Best Regards
> > Michael
> >
> > — Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256 You are
> > currently subscribed to ntdev as:
> xxxxx@3dlabs.com
> > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> xxxxx@3dlabs.com
> > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
> –
> Nick Ryan
> (Microsoft Windows MVP for DDK)
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@3dlabs.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@maxtor.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@maxtor.com To
unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx>