Interrupt Latency of ACPI vs Standard PC

[Jake_Oshins]

I’ve thought about those things, too. And while my knee isn’t jerking, I
don’t know yet where my efforts will be best applied.

I wanted to add one more thing to my previous answer. I have effectively
created two priority levels that most devices will use, medium and low.
This was specifically because, if you want to give yourself low priority,
you can probably make a determination that such a thing is safe. But if you
want to give yourself high priority, you are inherently making a decision
that you are more important than other drivers in the system, which is
something that is really, really hard to do safely within a device driver,
since you can’t usefully know what the other things which you have
pre-empted are.

–
Jake Oshins
Windows Base Kernel Team
This posting is provided “AS IS” with no warranties, and confers no rights.

“Loren Wilton” wrote in message news:xxxxx@ntdev…
> Thanks Jake. I must not be getting enough sleep lately. Filter resource
> requirements is indeed a good place to handle that sort of thing.
>
> I agree, it is impossible to please all the people (or possibly any of the
> people) all the time with interrupt routing. And the problem is that it
> is
> every bit as important to performance as the device design, but is
> virtually
> never under the control of the device designer or driver writer. Instead,
> it is designed by some system designer who may or may not consider
> interrupt
> latency an important consideration, and who almost certainly knows nothing
> about any specific device and its needs.
>
> So you have a case of someone who can write a driver for a device, and
> possibly knows the interrupt needs or desires of the device for optimal
> performance in isolation, but who knows nothing of the interrupt structure
> on the system(s) it will be used in. And you have someone designing a
> system, who, if he does anything with software at all, will write some
> BIOS
> code that won’t be used during real operations anyway. And who might well
> have less real knowlwdge of how the system will be used than even the
> driver
> writer does.
>
> And then the big problem is that all of this can’t be taken in isolation,
> but has to be tuned with everything else happening in the system, which is
> of course constantly varying, making optimal static tuning generally
> impossible, unless one takes a really long-term definition of “optimal”.
> But even that is difficult, because optimal is a matter of the user’s
> definition, Does he want response time or thruput optimized? Well of
> course he wants both; ignoring that, which does he want more? And it may
> be
> different at noon than at 8PM.
>
> Ideally the system should be completely self-tuning and the user’s options
> limited to a single “Go Faster” slider, or more likely push button, and
> the
> system will read the user’s mind and figure out what he really wants,
> since he probably can’t actually express it himself in most cases. In a
> less ideal world, one has to deal with more factors, and not all of them
> can
> be static if truely optimal performance is the goal.
>
> Which gets me to idly wondering about the concept of truely dynamic
> interrupt routing/tuning as part of an adjustable performance strategy.
> Processes and threads have adjustable priorities so that the user (or
> someone) can give an indication of relative desires. I start wondering if
> it would be reasonable to have interrupt affinity and priority levels
> adjustable dynamically, much like thread priority. If you consider a
> device/driver to be a process, then adjusting its relative priority
> doesn’t
> sound like that strange a concept.
>
> It may be difficult or impossible to implement anything like that, and of
> course the knee-jerk reaction is to claim that it is all totally
> inherently
> useless and I don’t want to think about it anymore. But I’ve been
> wondering
> about that general idea for 30 years now, and I still haven’t found
> anything
> that convinces me that it is NOT a good idea. Just that it is often
> difficult to implement, and harder to quantify the likely results.
>
> Loren
>
>

[Jake_Oshins]

Good luck! See if you can convince Intel of that.

–
Jake Oshins
Windows Base Kernel Team
This posting is provided “AS IS” with no warranties, and confers no rights.

“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…
> The best interrupt is no interrupt. Things like AV playback should be
> handled 100% on the south side of the bus, no need to involve the
> processor
> in it. I believe that if you run into performance issues because of
> interrupt latency, it’s about time to migrate to a better architecture !
>
> Alberto.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of
> xxxxx@3Dlabs.com
> Sent: Tuesday, February 17, 2004 9:21 AM
> To: Windows System Software Devs Interest List
> Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>
>
> Loren,
>> Ideally the system should be completely self-tuning and the
>> user’s options
>> limited to a single “Go Faster” slider, or more likely push
>> button, and the
>> system will read the user’s mind and figure out what he
>> really wants,
>> since he probably can’t actually express it himself in most
>> cases. In a
>> less ideal world, one has to deal with more factors, and not
>> all of them can
>> be static if truely optimal performance is the goal.
>
> I think the computer will be very confused if it could read my
> mind ;-).
>>
>> Which gets me to idly wondering about the concept of truely dynamic
>> interrupt routing/tuning as part of an adjustable performance
>> strategy.
>> Processes and threads have adjustable priorities so that the user (or
>> someone) can give an indication of relative desires. I start
>> wondering if
>> it would be reasonable to have interrupt affinity and priority levels
>> adjustable dynamically, much like thread priority. If you consider a
>> device/driver to be a process, then adjusting its relative
>> priority doesn’t
>> sound like that strange a concept.
>
> There are many conflicting goals to satisfy here, and the scheduling of
> which interrupt gets the highest priority is never going to be
> straightforward.
>
> Obviously, a system where you have some sort of real time needs, say AV
> playback, will need to have fast enough response-time on the relevant
> interrupts to the AV playback. But if you raise the importance of the
> sound
> card, and thus reduce the importance of the hard disk interrupt, you may
> get
> problems to get the data across to the sound card. So although the latency
> to the real-time critical part is lower, you’ve missed the goal-post by a
> side effect of trying to get to the goal.
>
> [The above is a completely made up example, and just for illustration
> purposes. Please change devices around as you please. There is always some
> sort of dependancy between one interrupt and another, that may cause
> things
> to go wrong.]
>
> In the ideal world, it shouldn’t really matter which interrupt has what
> priority, because all interrupts are handled within such a short time that
> the next one doesn’t get affected by the latency of other priorities.
>
> This will of course not happen, but I believe the MS initiative to keep
> interrupts short is a good one. This will certainly help. Now there’s of
> course one problem with this: A system that has LOTS of interrupts, the
> scheduling of DPC or some other mechanism to send work off to a lower IRQL
> will take a lot of extra time. Not good for overall performance. So
> someone
> will break the rules to improve performance, and we’re back at the
> beginning
> of a “not so ideal world”.
>
> I’m sometimes amazed at what slowness is allowed for interrupts to be
> handled in Windows, and the system still runs nicely (i.e. it doesn’t
> crash
> or behave too badly, you may get glitches in sound or video, but that’s
> it).
> It’s very interesting to see how long an interrupt can actually be held
> pending. It seems that it is ALMOST FOREVER (in computer time)…
>
> I think the idea of automatically/runtime adjusted interrupts is a fine
> idea. It’s just the implementation of the prioritization routine that I
> have
> a hard time figuring how it should work. I would tend to prioritize
> interrupts that run short times, and let the longer ones run at lower
> priority. That should reduce the average latency. Of course, it’s not good
> for the server system where someone copies a 256KB packet of data from the
> disk to the main memory inside the interrupt handler, but they shouldn’t
> be
> doing that in the first place, eh?
>
> –
> Mats
>
> —
> 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.
>
>

[OSR_Community_User]

Well, this is also a call of the hw vendors, no ? With some prodding from
you guys ? Look for example what’s happening in graphics, Microsoft has
instated de-facto standards for GPUs, and every serious hardware
manufacturer followed suit, and everyone gains. If you guys decided to move
interrupts out of the front-side bus, I doubt anyone in the industry would
complain, specially if it meant higher performance.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Jake Oshins
Sent: Tuesday, February 17, 2004 12:42 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Re:Interrupt Latency of ACPI vs Standard PC

Good luck! See if you can convince Intel of that.

–
Jake Oshins
Windows Base Kernel Team
This posting is provided “AS IS” with no warranties, and confers no rights.

“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…
> The best interrupt is no interrupt. Things like AV playback should be
> handled 100% on the south side of the bus, no need to involve the
> processor
> in it. I believe that if you run into performance issues because of
> interrupt latency, it’s about time to migrate to a better architecture !
>
> Alberto.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of
> xxxxx@3Dlabs.com
> Sent: Tuesday, February 17, 2004 9:21 AM
> To: Windows System Software Devs Interest List
> Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>
>
> Loren,
>> Ideally the system should be completely self-tuning and the
>> user’s options
>> limited to a single “Go Faster” slider, or more likely push
>> button, and the
>> system will read the user’s mind and figure out what he
>> really wants,
>> since he probably can’t actually express it himself in most
>> cases. In a
>> less ideal world, one has to deal with more factors, and not
>> all of them can
>> be static if truely optimal performance is the goal.
>
> I think the computer will be very confused if it could read my
> mind ;-).
>>
>> Which gets me to idly wondering about the concept of truely dynamic
>> interrupt routing/tuning as part of an adjustable performance
>> strategy.
>> Processes and threads have adjustable priorities so that the user (or
>> someone) can give an indication of relative desires. I start
>> wondering if
>> it would be reasonable to have interrupt affinity and priority levels
>> adjustable dynamically, much like thread priority. If you consider a
>> device/driver to be a process, then adjusting its relative
>> priority doesn’t
>> sound like that strange a concept.
>
> There are many conflicting goals to satisfy here, and the scheduling of
> which interrupt gets the highest priority is never going to be
> straightforward.
>
> Obviously, a system where you have some sort of real time needs, say AV
> playback, will need to have fast enough response-time on the relevant
> interrupts to the AV playback. But if you raise the importance of the
> sound
> card, and thus reduce the importance of the hard disk interrupt, you may
> get
> problems to get the data across to the sound card. So although the latency
> to the real-time critical part is lower, you’ve missed the goal-post by a
> side effect of trying to get to the goal.
>
> [The above is a completely made up example, and just for illustration
> purposes. Please change devices around as you please. There is always some
> sort of dependancy between one interrupt and another, that may cause
> things
> to go wrong.]
>
> In the ideal world, it shouldn’t really matter which interrupt has what
> priority, because all interrupts are handled within such a short time that
> the next one doesn’t get affected by the latency of other priorities.
>
> This will of course not happen, but I believe the MS initiative to keep
> interrupts short is a good one. This will certainly help. Now there’s of
> course one problem with this: A system that has LOTS of interrupts, the
> scheduling of DPC or some other mechanism to send work off to a lower IRQL
> will take a lot of extra time. Not good for overall performance. So
> someone
> will break the rules to improve performance, and we’re back at the
> beginning
> of a “not so ideal world”.
>
> I’m sometimes amazed at what slowness is allowed for interrupts to be
> handled in Windows, and the system still runs nicely (i.e. it doesn’t
> crash
> or behave too badly, you may get glitches in sound or video, but that’s
> it).
> It’s very interesting to see how long an interrupt can actually be held
> pending. It seems that it is ALMOST FOREVER (in computer time)…
>
> I think the idea of automatically/runtime adjusted interrupts is a fine
> idea. It’s just the implementation of the prioritization routine that I
> have
> a hard time figuring how it should work. I would tend to prioritize
> interrupts that run short times, and let the longer ones run at lower
> priority. That should reduce the average latency. Of course, it’s not good
> for the server system where someone copies a 256KB packet of data from the
> disk to the main memory inside the interrupt handler, but they shouldn’t
> be
> doing that in the first place, eh?
>
> –
> Mats
>
> —
> 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@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.

[OSR_Community_User]

That’s why people created signal processors, no ? To do this kind of work ?
So, how about having a disk processor and a video signal processor, so that
the stream comes directly from mass storage to the disk processor to the
video processor to the screen ? Look, ma, no CPU ? I believe there’s a lot
of offloading we can do if only we adopt a more rational I/O architecture.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Loren Wilton
Sent: Tuesday, February 17, 2004 10:14 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

The best interrupt is no interrupt. Things like AV playback should be
handled 100% on the south side of the bus, no need to involve the
processor
in it. I believe that if you run into performance issues because of
interrupt latency, it’s about time to migrate to a better architecture !

Um. Everything is a pipe of some sort or other. Sooner or later you start
having problems with turbulent flow around the corners, or the laminar flows
detatching from the walls.

Saying “just throw it over the wall, that solves all MY problems” may be
true. It doesn’t, however, solve all of the problems with the original
implementation.

For instance, video decoding is complicated enough that the only way it is
going to get done practically on the south side of the bridge is by putting
a reasonably general-purpose processor on the south side of the bridge. And
that processor is going to have to get bits from a source, transform them in
some manner, and push them out to a destination. And the translation is
unlikely to be 1:1, so there have to be flow rate conversions.

Now, you can “solve” the problem, for any specific singular case, by making
the transport into hardware fifos that control the wait-state line to the
processor. Thus making the whole thing synchronous, and the average
processor utilization somewhere around 35% max, and limiting the kinds of
transformations that can be accomplished. This might “eliminate” the
problems of interrupts. But it doesn’t really solve the problem, it just
gives you a problem that is probably worse.

The only way to “eliminate” interrupts is to design a system such that when
peripheral data becomes available to a processing thread, the thread is
scheduled automatically by the hardware. But scheduled doesn’t necessarily
mean run; you still have to get some processor cycles somewhere. And that
might be stealing them from something else that reall wants them too. Which
gets you into priority handling on scheduling and slicing and deciding what
to assign to which piece of hardware, which gets you into cache nearness
considerations and ability to get to the specific hardware.

Which is to say, it solves nothing. You still have all the same problems to
solve, they are just wrapped in a different color ribbon.

Loren

---

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.

[OSR_Community_User]

If we’re doing a lot of processing south of the bus, there’s no such thing
as “locking” memory, in fact, chances are that memory is not necessary. And
yes, maybe the lowest level of the file system should be moved out to a
peripheral processor too, why not ?

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@3Dlabs.com
Sent: Tuesday, February 17, 2004 9:50 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

The best interrupt is no interrupt. Things like AV playback should be
handled 100% on the south side of the bus, no need to involve
the processor
in it. I believe that if you run into performance issues because of
interrupt latency, it’s about time to migrate to a better
architecture !

I suppose this means:

1. Load one CD’s worth of data into memory.
2. Lock above memory to not page out.
3. Set pointer to memory into sound card.
4. Let sound card play the contents of memory.
5. When sound card interrupts saying it’s finished, de-allocate the CD’s
   worth of memory and start over.

Or did you want to integrate the file system driver into the sound card, so
that we can read the hard disk via the PCI bus, without involvment of the
CPU in either disk reads or sound playing?

Neither sound like the right thing to do to me…

–
Mats

---

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.

[OSR_Community_User]

What would be your I/O architecture, when video clips would be sent to one
of your receiver, and the information would flow thru PAN (personal area
network ), yes our skin is our network to a presentation manager. Not too
far out :-). And some people are actively working on this.

-prokash

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, February 17, 2004 11:16 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

That’s why people created signal processors, no ? To do this kind of work ?
So, how about having a disk processor and a video signal processor, so that
the stream comes directly from mass storage to the disk processor to the
video processor to the screen ? Look, ma, no CPU ? I believe there’s a lot
of offloading we can do if only we adopt a more rational I/O architecture.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Loren Wilton
Sent: Tuesday, February 17, 2004 10:14 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

The best interrupt is no interrupt. Things like AV playback should be
handled 100% on the south side of the bus, no need to involve the
processor
in it. I believe that if you run into performance issues because of
interrupt latency, it’s about time to migrate to a better architecture
!

Um. Everything is a pipe of some sort or other. Sooner or later you start
having problems with turbulent flow around the corners, or the laminar flows
detatching from the walls.

Saying “just throw it over the wall, that solves all MY problems” may be
true. It doesn’t, however, solve all of the problems with the original
implementation.

For instance, video decoding is complicated enough that the only way it is
going to get done practically on the south side of the bridge is by putting
a reasonably general-purpose processor on the south side of the bridge. And
that processor is going to have to get bits from a source, transform them in
some manner, and push them out to a destination. And the translation is
unlikely to be 1:1, so there have to be flow rate conversions.

Now, you can “solve” the problem, for any specific singular case, by making
the transport into hardware fifos that control the wait-state line to the
processor. Thus making the whole thing synchronous, and the average
processor utilization somewhere around 35% max, and limiting the kinds of
transformations that can be accomplished. This might “eliminate” the
problems of interrupts. But it doesn’t really solve the problem, it just
gives you a problem that is probably worse.

The only way to “eliminate” interrupts is to design a system such that when
peripheral data becomes available to a processing thread, the thread is
scheduled automatically by the hardware. But scheduled doesn’t necessarily
mean run; you still have to get some processor cycles somewhere. And that
might be stealing them from something else that reall wants them too. Which
gets you into priority handling on scheduling and slicing and deciding what
to assign to which piece of hardware, which gets you into cache nearness
considerations and ability to get to the specific hardware.

Which is to say, it solves nothing. You still have all the same problems to
solve, they are just wrapped in a different color ribbon.

Loren

---

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

[OSR_Community_User]

Maybe put the whole of the TCP/IP on the peripheral card ?

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Sinha, Prokash
Sent: Tuesday, February 17, 2004 2:46 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

What would be your I/O architecture, when video clips would be sent to one
of your receiver, and the information would flow thru PAN (personal area
network ), yes our skin is our network to a presentation manager. Not too
far out :-). And some people are actively working on this.

-prokash

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, February 17, 2004 11:16 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

That’s why people created signal processors, no ? To do this kind of work ?
So, how about having a disk processor and a video signal processor, so that
the stream comes directly from mass storage to the disk processor to the
video processor to the screen ? Look, ma, no CPU ? I believe there’s a lot
of offloading we can do if only we adopt a more rational I/O architecture.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Loren Wilton
Sent: Tuesday, February 17, 2004 10:14 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

The best interrupt is no interrupt. Things like AV playback should be
handled 100% on the south side of the bus, no need to involve the
processor
in it. I believe that if you run into performance issues because of
interrupt latency, it’s about time to migrate to a better architecture
!

Um. Everything is a pipe of some sort or other. Sooner or later you start
having problems with turbulent flow around the corners, or the laminar flows
detatching from the walls.

Saying “just throw it over the wall, that solves all MY problems” may be
true. It doesn’t, however, solve all of the problems with the original
implementation.

For instance, video decoding is complicated enough that the only way it is
going to get done practically on the south side of the bridge is by putting
a reasonably general-purpose processor on the south side of the bridge. And
that processor is going to have to get bits from a source, transform them in
some manner, and push them out to a destination. And the translation is
unlikely to be 1:1, so there have to be flow rate conversions.

Now, you can “solve” the problem, for any specific singular case, by making
the transport into hardware fifos that control the wait-state line to the
processor. Thus making the whole thing synchronous, and the average
processor utilization somewhere around 35% max, and limiting the kinds of
transformations that can be accomplished. This might “eliminate” the
problems of interrupts. But it doesn’t really solve the problem, it just
gives you a problem that is probably worse.

The only way to “eliminate” interrupts is to design a system such that when
peripheral data becomes available to a processing thread, the thread is
scheduled automatically by the hardware. But scheduled doesn’t necessarily
mean run; you still have to get some processor cycles somewhere. And that
might be stealing them from something else that reall wants them too. Which
gets you into priority handling on scheduling and slicing and deciding what
to assign to which piece of hardware, which gets you into cache nearness
considerations and ability to get to the specific hardware.

Which is to say, it solves nothing. You still have all the same problems to
solve, they are just wrapped in a different color ribbon.

Loren

---

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.

[OSR_Community_User]

Well receiver is small too, so how about an extreemly small wireless
interface, antena is quite small, embedded so bare eye could not see it.

The challenge comes to battery and low-bandwidth PAN. Heavy engergy could
cause serious damage to the human-body. Not 5 volts, 4/5th of TCP would have
to be trashed, so some such…

-prokash

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, February 17, 2004 11:57 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Maybe put the whole of the TCP/IP on the peripheral card ?

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Sinha, Prokash
Sent: Tuesday, February 17, 2004 2:46 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

What would be your I/O architecture, when video clips would be sent to one
of your receiver, and the information would flow thru PAN (personal area
network ), yes our skin is our network to a presentation manager. Not too
far out :-). And some people are actively working on this.

-prokash

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, February 17, 2004 11:16 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

That’s why people created signal processors, no ? To do this kind of work ?
So, how about having a disk processor and a video signal processor, so that
the stream comes directly from mass storage to the disk processor to the
video processor to the screen ? Look, ma, no CPU ? I believe there’s a lot
of offloading we can do if only we adopt a more rational I/O architecture.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Loren Wilton
Sent: Tuesday, February 17, 2004 10:14 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

The best interrupt is no interrupt. Things like AV playback should be
handled 100% on the south side of the bus, no need to involve the
processor
in it. I believe that if you run into performance issues because of
interrupt latency, it’s about time to migrate to a better architecture
!

Um. Everything is a pipe of some sort or other. Sooner or later you start
having problems with turbulent flow around the corners, or the laminar flows
detatching from the walls.

Saying “just throw it over the wall, that solves all MY problems” may be
true. It doesn’t, however, solve all of the problems with the original
implementation.

For instance, video decoding is complicated enough that the only way it is
going to get done practically on the south side of the bridge is by putting
a reasonably general-purpose processor on the south side of the bridge. And
that processor is going to have to get bits from a source, transform them in
some manner, and push them out to a destination. And the translation is
unlikely to be 1:1, so there have to be flow rate conversions.

Now, you can “solve” the problem, for any specific singular case, by making
the transport into hardware fifos that control the wait-state line to the
processor. Thus making the whole thing synchronous, and the average
processor utilization somewhere around 35% max, and limiting the kinds of
transformations that can be accomplished. This might “eliminate” the
problems of interrupts. But it doesn’t really solve the problem, it just
gives you a problem that is probably worse.

The only way to “eliminate” interrupts is to design a system such that when
peripheral data becomes available to a processing thread, the thread is
scheduled automatically by the hardware. But scheduled doesn’t necessarily
mean run; you still have to get some processor cycles somewhere. And that
might be stealing them from something else that reall wants them too. Which
gets you into priority handling on scheduling and slicing and deciding what
to assign to which piece of hardware, which gets you into cache nearness
considerations and ability to get to the specific hardware.

Which is to say, it solves nothing. You still have all the same problems to
solve, they are just wrapped in a different color ribbon.

Loren

---

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

[OSR_Community_User]

Ground Control to Major Tom
Your circuit’s dead, there’s something wrong
Can you hear me, Major Tom?
Can you hear me, Major Tom?
Can you hear me, Major Tom?
Can you…

“Here am I floating round my tin can
Far above the Moon
Planet Earth is blue
And there’s nothing I can do.”

David Bowie, Space Oddity.

Meanwhile, back on planet earth…how about them Yankees?

=====================
Mark Roddy

-----Original Message-----
From: Sinha, Prokash [mailto:xxxxx@maxtor.com]
Sent: Tuesday, February 17, 2004 3:09 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Well receiver is small too, so how about an extreemly small
wireless interface, antena is quite small, embedded so bare
eye could not see it.

The challenge comes to battery and low-bandwidth PAN. Heavy
engergy could cause serious damage to the human-body. Not 5
volts, 4/5th of TCP would have to be trashed, so some such…

-prokash

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, February 17, 2004 11:57 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Maybe put the whole of the TCP/IP on the peripheral card ?

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Sinha, Prokash
Sent: Tuesday, February 17, 2004 2:46 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

What would be your I/O architecture, when video clips would
be sent to one
of your receiver, and the information would flow thru PAN
(personal area
network ), yes our skin is our network to a presentation
manager. Not too
far out :-). And some people are actively working on this.

-prokash

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, February 17, 2004 11:16 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

That’s why people created signal processors, no ? To do this
kind of work ?
So, how about having a disk processor and a video signal
processor, so that
the stream comes directly from mass storage to the disk
processor to the
video processor to the screen ? Look, ma, no CPU ? I believe
there’s a lot
of offloading we can do if only we adopt a more rational I/O
architecture.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Loren Wilton
Sent: Tuesday, February 17, 2004 10:14 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

> The best interrupt is no interrupt. Things like AV playback
should be
> handled 100% on the south side of the bus, no need to involve the
processor
> in it. I believe that if you run into performance issues because of
> interrupt latency, it’s about time to migrate to a better
architecture
> !

Um. Everything is a pipe of some sort or other. Sooner or
later you start
having problems with turbulent flow around the corners, or
the laminar flows
detatching from the walls.

Saying “just throw it over the wall, that solves all MY
problems” may be
true. It doesn’t, however, solve all of the problems with
the original
implementation.

For instance, video decoding is complicated enough that the
only way it is
going to get done practically on the south side of the bridge
is by putting
a reasonably general-purpose processor on the south side of
the bridge. And
that processor is going to have to get bits from a source,
transform them in
some manner, and push them out to a destination. And the
translation is
unlikely to be 1:1, so there have to be flow rate conversions.

Now, you can “solve” the problem, for any specific singular
case, by making
the transport into hardware fifos that control the wait-state
line to the
processor. Thus making the whole thing synchronous, and the average
processor utilization somewhere around 35% max, and limiting
the kinds of
transformations that can be accomplished. This might “eliminate” the
problems of interrupts. But it doesn’t really solve the
problem, it just
gives you a problem that is probably worse.

The only way to “eliminate” interrupts is to design a system
such that when
peripheral data becomes available to a processing thread, the
thread is
scheduled automatically by the hardware. But scheduled
doesn’t necessarily
mean run; you still have to get some processor cycles
somewhere. And that
might be stealing them from something else that reall wants
them too. Which
gets you into priority handling on scheduling and slicing and
deciding what
to assign to which piece of hardware, which gets you into
cache nearness
considerations and ability to get to the specific hardware.

Which is to say, it solves nothing. You still have all the
same problems to
solve, they are just wrapped in a different color ribbon.

Loren

---

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

---

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[OSR_Community_User]

I hear you Mark :-).

-prokash

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Tuesday, February 17, 2004 12:20 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Ground Control to Major Tom
Your circuit’s dead, there’s something wrong
Can you hear me, Major Tom?
Can you hear me, Major Tom?
Can you hear me, Major Tom?
Can you…

“Here am I floating round my tin can
Far above the Moon
Planet Earth is blue
And there’s nothing I can do.”

David Bowie, Space Oddity.

Meanwhile, back on planet earth…how about them Yankees?

=====================
Mark Roddy

-----Original Message-----
From: Sinha, Prokash [mailto:xxxxx@maxtor.com]
Sent: Tuesday, February 17, 2004 3:09 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Well receiver is small too, so how about an extreemly small
wireless interface, antena is quite small, embedded so bare
eye could not see it.

The challenge comes to battery and low-bandwidth PAN. Heavy
engergy could cause serious damage to the human-body. Not 5
volts, 4/5th of TCP would have to be trashed, so some such…

-prokash

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, February 17, 2004 11:57 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Maybe put the whole of the TCP/IP on the peripheral card ?

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Sinha, Prokash
Sent: Tuesday, February 17, 2004 2:46 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

What would be your I/O architecture, when video clips would
be sent to one
of your receiver, and the information would flow thru PAN
(personal area
network ), yes our skin is our network to a presentation
manager. Not too
far out :-). And some people are actively working on this.

-prokash

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, February 17, 2004 11:16 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

That’s why people created signal processors, no ? To do this
kind of work ?
So, how about having a disk processor and a video signal
processor, so that
the stream comes directly from mass storage to the disk
processor to the
video processor to the screen ? Look, ma, no CPU ? I believe
there’s a lot
of offloading we can do if only we adopt a more rational I/O
architecture.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Loren Wilton
Sent: Tuesday, February 17, 2004 10:14 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

> The best interrupt is no interrupt. Things like AV playback
should be
> handled 100% on the south side of the bus, no need to involve the
processor
> in it. I believe that if you run into performance issues because of
> interrupt latency, it’s about time to migrate to a better
architecture
> !

Um. Everything is a pipe of some sort or other. Sooner or
later you start
having problems with turbulent flow around the corners, or
the laminar flows
detatching from the walls.

Saying “just throw it over the wall, that solves all MY
problems” may be
true. It doesn’t, however, solve all of the problems with
the original
implementation.

For instance, video decoding is complicated enough that the
only way it is
going to get done practically on the south side of the bridge
is by putting
a reasonably general-purpose processor on the south side of
the bridge. And
that processor is going to have to get bits from a source,
transform them in
some manner, and push them out to a destination. And the
translation is
unlikely to be 1:1, so there have to be flow rate conversions.

Now, you can “solve” the problem, for any specific singular
case, by making
the transport into hardware fifos that control the wait-state
line to the
processor. Thus making the whole thing synchronous, and the average
processor utilization somewhere around 35% max, and limiting
the kinds of
transformations that can be accomplished. This might “eliminate” the
problems of interrupts. But it doesn’t really solve the
problem, it just
gives you a problem that is probably worse.

The only way to “eliminate” interrupts is to design a system
such that when
peripheral data becomes available to a processing thread, the
thread is
scheduled automatically by the hardware. But scheduled
doesn’t necessarily
mean run; you still have to get some processor cycles
somewhere. And that
might be stealing them from something else that reall wants
them too. Which
gets you into priority handling on scheduling and slicing and
deciding what
to assign to which piece of hardware, which gets you into
cache nearness
considerations and ability to get to the specific hardware.

Which is to say, it solves nothing. You still have all the
same problems to
solve, they are just wrapped in a different color ribbon.

Loren

---

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

---

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.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@maxtor.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

[OSR_Community_User]

Sounded like me a grass hopper (smoker)!. Glad I did sound like … Since
I’m thinking along that line what I mentioned, and it is not really too far
out and that has some similarity with other stuff.

-prokash

-----Original Message-----
From: Sinha, Prokash
Sent: Tuesday, February 17, 2004 1:25 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

I hear you Mark :-).

-prokash

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Tuesday, February 17, 2004 12:20 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Ground Control to Major Tom
Your circuit’s dead, there’s something wrong
Can you hear me, Major Tom?
Can you hear me, Major Tom?
Can you hear me, Major Tom?
Can you…

“Here am I floating round my tin can
Far above the Moon
Planet Earth is blue
And there’s nothing I can do.”

David Bowie, Space Oddity.

Meanwhile, back on planet earth…how about them Yankees?

=====================
Mark Roddy

-----Original Message-----
From: Sinha, Prokash [mailto:xxxxx@maxtor.com]
Sent: Tuesday, February 17, 2004 3:09 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Well receiver is small too, so how about an extreemly small wireless
interface, antena is quite small, embedded so bare eye could not see
it.

The challenge comes to battery and low-bandwidth PAN. Heavy engergy
could cause serious damage to the human-body. Not 5 volts, 4/5th of
TCP would have to be trashed, so some such…

-prokash

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, February 17, 2004 11:57 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Maybe put the whole of the TCP/IP on the peripheral card ?

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Sinha, Prokash
Sent: Tuesday, February 17, 2004 2:46 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

What would be your I/O architecture, when video clips would be sent to
one of your receiver, and the information would flow thru PAN
(personal area
network ), yes our skin is our network to a presentation
manager. Not too
far out :-). And some people are actively working on this.

-prokash

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, February 17, 2004 11:16 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

That’s why people created signal processors, no ? To do this kind of
work ? So, how about having a disk processor and a video signal
processor, so that
the stream comes directly from mass storage to the disk
processor to the
video processor to the screen ? Look, ma, no CPU ? I believe
there’s a lot
of offloading we can do if only we adopt a more rational I/O
architecture.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Loren Wilton
Sent: Tuesday, February 17, 2004 10:14 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

> The best interrupt is no interrupt. Things like AV playback
should be
> handled 100% on the south side of the bus, no need to involve the
processor
> in it. I believe that if you run into performance issues because of
> interrupt latency, it’s about time to migrate to a better
architecture
> !

Um. Everything is a pipe of some sort or other. Sooner or later you
start having problems with turbulent flow around the corners, or
the laminar flows
detatching from the walls.

Saying “just throw it over the wall, that solves all MY problems” may
be true. It doesn’t, however, solve all of the problems with
the original
implementation.

For instance, video decoding is complicated enough that the only way
it is going to get done practically on the south side of the bridge
is by putting
a reasonably general-purpose processor on the south side of
the bridge. And
that processor is going to have to get bits from a source,
transform them in
some manner, and push them out to a destination. And the
translation is
unlikely to be 1:1, so there have to be flow rate conversions.

Now, you can “solve” the problem, for any specific singular case, by
making the transport into hardware fifos that control the wait-state
line to the
processor. Thus making the whole thing synchronous, and the average
processor utilization somewhere around 35% max, and limiting
the kinds of
transformations that can be accomplished. This might “eliminate” the
problems of interrupts. But it doesn’t really solve the
problem, it just
gives you a problem that is probably worse.

The only way to “eliminate” interrupts is to design a system such that
when peripheral data becomes available to a processing thread, the
thread is
scheduled automatically by the hardware. But scheduled
doesn’t necessarily
mean run; you still have to get some processor cycles
somewhere. And that
might be stealing them from something else that reall wants
them too. Which
gets you into priority handling on scheduling and slicing and
deciding what
to assign to which piece of hardware, which gets you into
cache nearness
considerations and ability to get to the specific hardware.

Which is to say, it solves nothing. You still have all the same
problems to solve, they are just wrapped in a different color ribbon.

Loren

---

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

---

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.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@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@maxtor.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[Maxim_S_Shatskih]

From what I understand, the hardware DVD-decoder cards are the long ago
obsolete remnant of the Pentium-2 and “slot CPUs” era, and modern DVD
facilities are running on the main host CPU.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Jake Oshins”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Tuesday, February 17, 2004 8:42 PM
Subject: Re:[ntdev] Re:Re:Interrupt Latency of ACPI vs Standard PC

> Good luck! See if you can convince Intel of that.
>
> –
> Jake Oshins
> Windows Base Kernel Team
> This posting is provided “AS IS” with no warranties, and confers no rights.
>
> “Moreira, Alberto” wrote in message
> news:xxxxx@ntdev…
> > The best interrupt is no interrupt. Things like AV playback should be
> > handled 100% on the south side of the bus, no need to involve the
> > processor
> > in it. I believe that if you run into performance issues because of
> > interrupt latency, it’s about time to migrate to a better architecture !
> >
> > Alberto.
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of
> > xxxxx@3Dlabs.com
> > Sent: Tuesday, February 17, 2004 9:21 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
> >
> >
> > Loren,
> >> Ideally the system should be completely self-tuning and the
> >> user’s options
> >> limited to a single “Go Faster” slider, or more likely push
> >> button, and the
> >> system will read the user’s mind and figure out what he
> >> really wants,
> >> since he probably can’t actually express it himself in most
> >> cases. In a
> >> less ideal world, one has to deal with more factors, and not
> >> all of them can
> >> be static if truely optimal performance is the goal.
> >
> > I think the computer will be very confused if it could read my
> > mind ;-).
> >>
> >> Which gets me to idly wondering about the concept of truely dynamic
> >> interrupt routing/tuning as part of an adjustable performance
> >> strategy.
> >> Processes and threads have adjustable priorities so that the user (or
> >> someone) can give an indication of relative desires. I start
> >> wondering if
> >> it would be reasonable to have interrupt affinity and priority levels
> >> adjustable dynamically, much like thread priority. If you consider a
> >> device/driver to be a process, then adjusting its relative
> >> priority doesn’t
> >> sound like that strange a concept.
> >
> > There are many conflicting goals to satisfy here, and the scheduling of
> > which interrupt gets the highest priority is never going to be
> > straightforward.
> >
> > Obviously, a system where you have some sort of real time needs, say AV
> > playback, will need to have fast enough response-time on the relevant
> > interrupts to the AV playback. But if you raise the importance of the
> > sound
> > card, and thus reduce the importance of the hard disk interrupt, you may
> > get
> > problems to get the data across to the sound card. So although the latency
> > to the real-time critical part is lower, you’ve missed the goal-post by a
> > side effect of trying to get to the goal.
> >
> > [The above is a completely made up example, and just for illustration
> > purposes. Please change devices around as you please. There is always some
> > sort of dependancy between one interrupt and another, that may cause
> > things
> > to go wrong.]
> >
> > In the ideal world, it shouldn’t really matter which interrupt has what
> > priority, because all interrupts are handled within such a short time that
> > the next one doesn’t get affected by the latency of other priorities.
> >
> > This will of course not happen, but I believe the MS initiative to keep
> > interrupts short is a good one. This will certainly help. Now there’s of
> > course one problem with this: A system that has LOTS of interrupts, the
> > scheduling of DPC or some other mechanism to send work off to a lower IRQL
> > will take a lot of extra time. Not good for overall performance. So
> > someone
> > will break the rules to improve performance, and we’re back at the
> > beginning
> > of a “not so ideal world”.
> >
> > I’m sometimes amazed at what slowness is allowed for interrupts to be
> > handled in Windows, and the system still runs nicely (i.e. it doesn’t
> > crash
> > or behave too badly, you may get glitches in sound or video, but that’s
> > it).
> > It’s very interesting to see how long an interrupt can actually be held
> > pending. It seems that it is ALMOST FOREVER (in computer time)…
> >
> > I think the idea of automatically/runtime adjusted interrupts is a fine
> > idea. It’s just the implementation of the prioritization routine that I
> > have
> > a hard time figuring how it should work. I would tend to prioritize
> > interrupts that run short times, and let the longer ones run at lower
> > priority. That should reduce the average latency. Of course, it’s not good
> > for the server system where someone copies a 256KB packet of data from the
> > disk to the main memory inside the interrupt handler, but they shouldn’t
> > be
> > doing that in the first place, eh?
> >
> > –
> > Mats
> >
> > —
> > 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@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

[OSR_Community_User]

Wow, a luddite ?

How big is the TCP stack code ? I’m going to bet it fits in one chip inside
a card smaller than a CompactFlash. It’ll happen, sooner or later. Sometimes
it’s cheaper to write it in HDL than it is to write it in C.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Tuesday, February 17, 2004 3:20 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Ground Control to Major Tom
Your circuit’s dead, there’s something wrong
Can you hear me, Major Tom?
Can you hear me, Major Tom?
Can you hear me, Major Tom?
Can you…

“Here am I floating round my tin can
Far above the Moon
Planet Earth is blue
And there’s nothing I can do.”

David Bowie, Space Oddity.

Meanwhile, back on planet earth…how about them Yankees?

=====================
Mark Roddy

-----Original Message-----
From: Sinha, Prokash [mailto:xxxxx@maxtor.com]
Sent: Tuesday, February 17, 2004 3:09 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Well receiver is small too, so how about an extreemly small
wireless interface, antena is quite small, embedded so bare
eye could not see it.

The challenge comes to battery and low-bandwidth PAN. Heavy
engergy could cause serious damage to the human-body. Not 5
volts, 4/5th of TCP would have to be trashed, so some such…

-prokash

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, February 17, 2004 11:57 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Maybe put the whole of the TCP/IP on the peripheral card ?

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Sinha, Prokash
Sent: Tuesday, February 17, 2004 2:46 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

What would be your I/O architecture, when video clips would
be sent to one
of your receiver, and the information would flow thru PAN
(personal area
network ), yes our skin is our network to a presentation
manager. Not too
far out :-). And some people are actively working on this.

-prokash

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, February 17, 2004 11:16 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

That’s why people created signal processors, no ? To do this
kind of work ?
So, how about having a disk processor and a video signal
processor, so that
the stream comes directly from mass storage to the disk
processor to the
video processor to the screen ? Look, ma, no CPU ? I believe
there’s a lot
of offloading we can do if only we adopt a more rational I/O
architecture.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Loren Wilton
Sent: Tuesday, February 17, 2004 10:14 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

> The best interrupt is no interrupt. Things like AV playback
should be
> handled 100% on the south side of the bus, no need to involve the
processor
> in it. I believe that if you run into performance issues because of
> interrupt latency, it’s about time to migrate to a better
architecture
> !

Um. Everything is a pipe of some sort or other. Sooner or
later you start
having problems with turbulent flow around the corners, or
the laminar flows
detatching from the walls.

Saying “just throw it over the wall, that solves all MY
problems” may be
true. It doesn’t, however, solve all of the problems with
the original
implementation.

For instance, video decoding is complicated enough that the
only way it is
going to get done practically on the south side of the bridge
is by putting
a reasonably general-purpose processor on the south side of
the bridge. And
that processor is going to have to get bits from a source,
transform them in
some manner, and push them out to a destination. And the
translation is
unlikely to be 1:1, so there have to be flow rate conversions.

Now, you can “solve” the problem, for any specific singular
case, by making
the transport into hardware fifos that control the wait-state
line to the
processor. Thus making the whole thing synchronous, and the average
processor utilization somewhere around 35% max, and limiting
the kinds of
transformations that can be accomplished. This might “eliminate” the
problems of interrupts. But it doesn’t really solve the
problem, it just
gives you a problem that is probably worse.

The only way to “eliminate” interrupts is to design a system
such that when
peripheral data becomes available to a processing thread, the
thread is
scheduled automatically by the hardware. But scheduled
doesn’t necessarily
mean run; you still have to get some processor cycles
somewhere. And that
might be stealing them from something else that reall wants
them too. Which
gets you into priority handling on scheduling and slicing and
deciding what
to assign to which piece of hardware, which gets you into
cache nearness
considerations and ability to get to the specific hardware.

Which is to say, it solves nothing. You still have all the
same problems to
solve, they are just wrapped in a different color ribbon.

Loren

---

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

---

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.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.

[OSR_Community_User]

Luddite? No Alberto, I’m not a luddite, not a worshiper of technology
either. I do wonder though why you post on the ‘Windows System Software
Developers Interest List’, as your posts consistently have nothing much to
do with windows system software development.

Signal/noise ~0.

=====================
Mark Roddy

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Wednesday, February 18, 2004 9:24 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Wow, a luddite ?

How big is the TCP stack code ? I’m going to bet it fits in
one chip inside a card smaller than a CompactFlash. It’ll
happen, sooner or later. Sometimes it’s cheaper to write it
in HDL than it is to write it in C.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Tuesday, February 17, 2004 3:20 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Ground Control to Major Tom
Your circuit’s dead, there’s something wrong Can you hear me,
Major Tom?
Can you hear me, Major Tom?
Can you hear me, Major Tom?
Can you…

“Here am I floating round my tin can
Far above the Moon
Planet Earth is blue
And there’s nothing I can do.”

David Bowie, Space Oddity.

Meanwhile, back on planet earth…how about them Yankees?

=====================
Mark Roddy

> -----Original Message-----
> From: Sinha, Prokash [mailto:xxxxx@maxtor.com]
> Sent: Tuesday, February 17, 2004 3:09 PM
> To: Windows System Software Devs Interest List
> Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>
> Well receiver is small too, so how about an extreemly small
wireless
> interface, antena is quite small, embedded so bare eye
could not see
> it.
>
> The challenge comes to battery and low-bandwidth PAN. Heavy engergy
> could cause serious damage to the human-body. Not 5 volts, 4/5th of
> TCP would have to be trashed, so some such…
>
> -prokash
>
> -----Original Message-----
> From: Moreira, Alberto [mailto:xxxxx@compuware.com]
> Sent: Tuesday, February 17, 2004 11:57 AM
> To: Windows System Software Devs Interest List
> Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>
>
> Maybe put the whole of the TCP/IP on the peripheral card ?
>
> Alberto.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Sinha, Prokash
> Sent: Tuesday, February 17, 2004 2:46 PM
> To: Windows System Software Devs Interest List
> Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>
>
> What would be your I/O architecture, when video clips would
be sent to
> one of your receiver, and the information would flow thru PAN
> (personal area network ), yes our skin is our network to a
> presentation manager. Not too far out :-). And some people are
> actively working on this.
>
> -prokash
>
>
>
> -----Original Message-----
> From: Moreira, Alberto [mailto:xxxxx@compuware.com]
> Sent: Tuesday, February 17, 2004 11:16 AM
> To: Windows System Software Devs Interest List
> Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>
>
> That’s why people created signal processors, no ? To do
this kind of
> work ?
> So, how about having a disk processor and a video signal
processor, so
> that the stream comes directly from mass storage to the
disk processor
> to the video processor to the screen ? Look, ma, no CPU ? I believe
> there’s a lot of offloading we can do if only we adopt a
more rational
> I/O architecture.
>
>
> Alberto.
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Loren Wilton
> Sent: Tuesday, February 17, 2004 10:14 AM
> To: Windows System Software Devs Interest List
> Subject: Re: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>
>
> > The best interrupt is no interrupt. Things like AV playback
> should be
> > handled 100% on the south side of the bus, no need to involve the
> processor
> > in it. I believe that if you run into performance issues
because of
> > interrupt latency, it’s about time to migrate to a better
> architecture
> > !
>
> Um. Everything is a pipe of some sort or other. Sooner or
later you
> start having problems with turbulent flow around the
corners, or the
> laminar flows detatching from the walls.
>
> Saying “just throw it over the wall, that solves all MY
problems” may
> be true. It doesn’t, however, solve all of the problems with the
> original implementation.
>
> For instance, video decoding is complicated enough that the
only way
> it is going to get done practically on the south side of
the bridge is
> by putting a reasonably general-purpose processor on the
south side of
> the bridge. And that processor is going to have to get bits from a
> source, transform them in some manner, and push them out to a
> destination. And the translation is unlikely to be 1:1, so
there have
> to be flow rate conversions.
>
> Now, you can “solve” the problem, for any specific singular
case, by
> making the transport into hardware fifos that control the
wait-state
> line to the processor. Thus making the whole thing
synchronous, and
> the average processor utilization somewhere around 35% max, and
> limiting the kinds of transformations that can be
accomplished. This
> might “eliminate” the problems of interrupts. But it
doesn’t really
> solve the problem, it just gives you a problem that is
probably worse.
>
> The only way to “eliminate” interrupts is to design a
system such that
> when peripheral data becomes available to a processing thread, the
> thread is scheduled automatically by the hardware. But scheduled
> doesn’t necessarily mean run; you still have to get some processor
> cycles somewhere. And that might be stealing them from
something else
> that reall wants them too. Which gets you into priority
handling on
> scheduling and slicing and deciding what to assign to which
piece of
> hardware, which gets you into cache nearness considerations and
> ability to get to the specific hardware.
>
> Which is to say, it solves nothing. You still have all the same
> problems to solve, they are just wrapped in a different
color ribbon.
>
> Loren
>
>
> —
> 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
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@stratus.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@stratus.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

[Prokash_Sinha-1]

First by looking at the other email from MARK. It is high time to
apologize, but what can some of us do, I’m set out to write drivers for
win95, since no one else want to do it, so once I face some problems, sure
I will ask interesting questions, and you(mark), walter, alberto or someone
would shed light(s).
Other guys are busy with greatest and latest stuff in the windows driver and
firmware
land. Me trying to formulate if you need first order markov source or third
order to figureout
pattern that might enhance multiple video stream experiences.

I did throw that PAN, since it has a fair amount of similarities (when it
comes down to) w/system
architecture for video streaming. I’ve seen quite a bit of input to this
thread, and I’m still
interested to know if anyone has done any benchmarking on prototypical
streaming setup, and found
some bottlenecks ( in order ). Here U, I say U, are the first bottleneck.
You little rascale, you
are second, etc.,etc. Interestingly, TCP found to be annoying by our radar.
More later !!!

-prokash

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Moreira, Alberto
Sent: Wednesday, February 18, 2004 6:24 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Wow, a luddite ?

How big is the TCP stack code ? I’m going to bet it fits in one chip inside
a card smaller than a CompactFlash. It’ll happen, sooner or later. Sometimes
it’s cheaper to write it in HDL than it is to write it in C.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Tuesday, February 17, 2004 3:20 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Ground Control to Major Tom
Your circuit’s dead, there’s something wrong
Can you hear me, Major Tom?
Can you hear me, Major Tom?
Can you hear me, Major Tom?
Can you…

“Here am I floating round my tin can
Far above the Moon
Planet Earth is blue
And there’s nothing I can do.”

David Bowie, Space Oddity.

Meanwhile, back on planet earth…how about them Yankees?

=====================
Mark Roddy

-----Original Message-----
From: Sinha, Prokash [mailto:xxxxx@maxtor.com]
Sent: Tuesday, February 17, 2004 3:09 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Well receiver is small too, so how about an extreemly small
wireless interface, antena is quite small, embedded so bare
eye could not see it.

The challenge comes to battery and low-bandwidth PAN. Heavy
engergy could cause serious damage to the human-body. Not 5
volts, 4/5th of TCP would have to be trashed, so some such…

-prokash

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, February 17, 2004 11:57 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Maybe put the whole of the TCP/IP on the peripheral card ?

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Sinha, Prokash
Sent: Tuesday, February 17, 2004 2:46 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

What would be your I/O architecture, when video clips would
be sent to one
of your receiver, and the information would flow thru PAN
(personal area
network ), yes our skin is our network to a presentation
manager. Not too
far out :-). And some people are actively working on this.

-prokash

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, February 17, 2004 11:16 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

That’s why people created signal processors, no ? To do this
kind of work ?
So, how about having a disk processor and a video signal
processor, so that
the stream comes directly from mass storage to the disk
processor to the
video processor to the screen ? Look, ma, no CPU ? I believe
there’s a lot
of offloading we can do if only we adopt a more rational I/O
architecture.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Loren Wilton
Sent: Tuesday, February 17, 2004 10:14 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

> The best interrupt is no interrupt. Things like AV playback
should be
> handled 100% on the south side of the bus, no need to involve the
processor
> in it. I believe that if you run into performance issues because of
> interrupt latency, it’s about time to migrate to a better
architecture
> !

Um. Everything is a pipe of some sort or other. Sooner or
later you start
having problems with turbulent flow around the corners, or
the laminar flows
detatching from the walls.

Saying “just throw it over the wall, that solves all MY
problems” may be
true. It doesn’t, however, solve all of the problems with
the original
implementation.

For instance, video decoding is complicated enough that the
only way it is
going to get done practically on the south side of the bridge
is by putting
a reasonably general-purpose processor on the south side of
the bridge. And
that processor is going to have to get bits from a source,
transform them in
some manner, and push them out to a destination. And the
translation is
unlikely to be 1:1, so there have to be flow rate conversions.

Now, you can “solve” the problem, for any specific singular
case, by making
the transport into hardware fifos that control the wait-state
line to the
processor. Thus making the whole thing synchronous, and the average
processor utilization somewhere around 35% max, and limiting
the kinds of
transformations that can be accomplished. This might “eliminate” the
problems of interrupts. But it doesn’t really solve the
problem, it just
gives you a problem that is probably worse.

The only way to “eliminate” interrupts is to design a system
such that when
peripheral data becomes available to a processing thread, the
thread is
scheduled automatically by the hardware. But scheduled
doesn’t necessarily
mean run; you still have to get some processor cycles
somewhere. And that
might be stealing them from something else that reall wants
them too. Which
gets you into priority handling on scheduling and slicing and
deciding what
to assign to which piece of hardware, which gets you into
cache nearness
considerations and ability to get to the specific hardware.

Which is to say, it solves nothing. You still have all the
same problems to
solve, they are just wrapped in a different color ribbon.

Loren

---

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

---

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.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@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[Jake_Oshins]

Has anyone read William Gibson’s latest, “Pattern Recognition?” There’s a
character in it who plays a role very similar to the one that Alberto plays.
It gives me a whole new theory on why he hangs out in this newsgroup. I
don’t want to give away much of the book. But it’s terrific.

–
Jake Oshins
Windows Base Kernel Team
This posting is provided “AS IS” with no warranties, and confers no rights.

“Roddy, Mark” wrote in message news:xxxxx@ntdev…
> Luddite? No Alberto, I’m not a luddite, not a worshiper of technology
> either. I do wonder though why you post on the ‘Windows System Software
> Developers Interest List’, as your posts consistently have nothing much to
> do with windows system software development.
>
> Signal/noise ~0.
>
> =====================
> Mark Roddy
>
>
>> -----Original Message-----
>> From: Moreira, Alberto [mailto:xxxxx@compuware.com]
>> Sent: Wednesday, February 18, 2004 9:24 AM
>> To: Windows System Software Devs Interest List
>> Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>>
>> Wow, a luddite ?
>>
>> How big is the TCP stack code ? I’m going to bet it fits in
>> one chip inside a card smaller than a CompactFlash. It’ll
>> happen, sooner or later. Sometimes it’s cheaper to write it
>> in HDL than it is to write it in C.
>>
>>
>> Alberto.
>>
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
>> Sent: Tuesday, February 17, 2004 3:20 PM
>> To: Windows System Software Devs Interest List
>> Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>>
>>
>> Ground Control to Major Tom
>> Your circuit’s dead, there’s something wrong Can you hear me,
>> Major Tom?
>> Can you hear me, Major Tom?
>> Can you hear me, Major Tom?
>> Can you…
>>
>> “Here am I floating round my tin can
>> Far above the Moon
>> Planet Earth is blue
>> And there’s nothing I can do.”
>>
>> David Bowie, Space Oddity.
>>
>> Meanwhile, back on planet earth…how about them Yankees?
>>
>>
>> =====================
>> Mark Roddy
>>
>>
>> > -----Original Message-----
>> > From: Sinha, Prokash [mailto:xxxxx@maxtor.com]
>> > Sent: Tuesday, February 17, 2004 3:09 PM
>> > To: Windows System Software Devs Interest List
>> > Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>> >
>> > Well receiver is small too, so how about an extreemly small
>> wireless
>> > interface, antena is quite small, embedded so bare eye
>> could not see
>> > it.
>> >
>> > The challenge comes to battery and low-bandwidth PAN. Heavy engergy
>> > could cause serious damage to the human-body. Not 5 volts, 4/5th of
>> > TCP would have to be trashed, so some such…
>> >
>> > -prokash
>> >
>> > -----Original Message-----
>> > From: Moreira, Alberto [mailto:xxxxx@compuware.com]
>> > Sent: Tuesday, February 17, 2004 11:57 AM
>> > To: Windows System Software Devs Interest List
>> > Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>> >
>> >
>> > Maybe put the whole of the TCP/IP on the peripheral card ?
>> >
>> > Alberto.
>> >
>> >
>> > -----Original Message-----
>> > From: xxxxx@lists.osr.com
>> > [mailto:xxxxx@lists.osr.com]On Behalf Of Sinha, Prokash
>> > Sent: Tuesday, February 17, 2004 2:46 PM
>> > To: Windows System Software Devs Interest List
>> > Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>> >
>> >
>> > What would be your I/O architecture, when video clips would
>> be sent to
>> > one of your receiver, and the information would flow thru PAN
>> > (personal area network ), yes our skin is our network to a
>> > presentation manager. Not too far out :-). And some people are
>> > actively working on this.
>> >
>> > -prokash
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: Moreira, Alberto [mailto:xxxxx@compuware.com]
>> > Sent: Tuesday, February 17, 2004 11:16 AM
>> > To: Windows System Software Devs Interest List
>> > Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>> >
>> >
>> > That’s why people created signal processors, no ? To do
>> this kind of
>> > work ?
>> > So, how about having a disk processor and a video signal
>> processor, so
>> > that the stream comes directly from mass storage to the
>> disk processor
>> > to the video processor to the screen ? Look, ma, no CPU ? I believe
>> > there’s a lot of offloading we can do if only we adopt a
>> more rational
>> > I/O architecture.
>> >
>> >
>> > Alberto.
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: xxxxx@lists.osr.com
>> > [mailto:xxxxx@lists.osr.com]On Behalf Of Loren Wilton
>> > Sent: Tuesday, February 17, 2004 10:14 AM
>> > To: Windows System Software Devs Interest List
>> > Subject: Re: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>> >
>> >
>> > > The best interrupt is no interrupt. Things like AV playback
>> > should be
>> > > handled 100% on the south side of the bus, no need to involve the
>> > processor
>> > > in it. I believe that if you run into performance issues
>> because of
>> > > interrupt latency, it’s about time to migrate to a better
>> > architecture
>> > > !
>> >
>> > Um. Everything is a pipe of some sort or other. Sooner or
>> later you
>> > start having problems with turbulent flow around the
>> corners, or the
>> > laminar flows detatching from the walls.
>> >
>> > Saying “just throw it over the wall, that solves all MY
>> problems” may
>> > be true. It doesn’t, however, solve all of the problems with the
>> > original implementation.
>> >
>> > For instance, video decoding is complicated enough that the
>> only way
>> > it is going to get done practically on the south side of
>> the bridge is
>> > by putting a reasonably general-purpose processor on the
>> south side of
>> > the bridge. And that processor is going to have to get bits from a
>> > source, transform them in some manner, and push them out to a
>> > destination. And the translation is unlikely to be 1:1, so
>> there have
>> > to be flow rate conversions.
>> >
>> > Now, you can “solve” the problem, for any specific singular
>> case, by
>> > making the transport into hardware fifos that control the
>> wait-state
>> > line to the processor. Thus making the whole thing
>> synchronous, and
>> > the average processor utilization somewhere around 35% max, and
>> > limiting the kinds of transformations that can be
>> accomplished. This
>> > might “eliminate” the problems of interrupts. But it
>> doesn’t really
>> > solve the problem, it just gives you a problem that is
>> probably worse.
>> >
>> > The only way to “eliminate” interrupts is to design a
>> system such that
>> > when peripheral data becomes available to a processing thread, the
>> > thread is scheduled automatically by the hardware. But scheduled
>> > doesn’t necessarily mean run; you still have to get some processor
>> > cycles somewhere. And that might be stealing them from
>> something else
>> > that reall wants them too. Which gets you into priority
>> handling on
>> > scheduling and slicing and deciding what to assign to which
>> piece of
>> > hardware, which gets you into cache nearness considerations and
>> > ability to get to the specific hardware.
>> >
>> > Which is to say, it solves nothing. You still have all the same
>> > problems to solve, they are just wrapped in a different
>> color ribbon.
>> >
>> > Loren
>> >
>> >
>> > —
>> > 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
>> >
>> > —
>> > Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >
>> > You are currently subscribed to ntdev as: xxxxx@stratus.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@stratus.com To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>>
>

[Maxim_S_Shatskih]

> How big is the TCP stack code ? I’m going to bet it fits in one chip inside

a card smaller than a CompactFlash.

The whole iPaq is such a chip, the rest is screen, case to be holdable and the
battery.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

[OSR_Community_User]

I’m here mostly to channel the tidbits of discussion on SoftICE and
associated tools. But system software must be designed too. Or maybe this
list should be restricted to answering questions about how to use Microsoft
APIs ?

And you know, it wasn’t me who started the nonsense, I just answered your
“Major Tom” post. Talk about signal to noise ratio ?

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Wednesday, February 18, 2004 9:36 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Luddite? No Alberto, I’m not a luddite, not a worshiper of technology
either. I do wonder though why you post on the ‘Windows System Software
Developers Interest List’, as your posts consistently have nothing much to
do with windows system software development.

Signal/noise ~0.

=====================
Mark Roddy

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Wednesday, February 18, 2004 9:24 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Wow, a luddite ?

How big is the TCP stack code ? I’m going to bet it fits in
one chip inside a card smaller than a CompactFlash. It’ll
happen, sooner or later. Sometimes it’s cheaper to write it
in HDL than it is to write it in C.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Tuesday, February 17, 2004 3:20 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

Ground Control to Major Tom
Your circuit’s dead, there’s something wrong Can you hear me,
Major Tom?
Can you hear me, Major Tom?
Can you hear me, Major Tom?
Can you…

“Here am I floating round my tin can
Far above the Moon
Planet Earth is blue
And there’s nothing I can do.”

David Bowie, Space Oddity.

Meanwhile, back on planet earth…how about them Yankees?

=====================
Mark Roddy

> -----Original Message-----
> From: Sinha, Prokash [mailto:xxxxx@maxtor.com]
> Sent: Tuesday, February 17, 2004 3:09 PM
> To: Windows System Software Devs Interest List
> Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>
> Well receiver is small too, so how about an extreemly small
wireless
> interface, antena is quite small, embedded so bare eye
could not see
> it.
>
> The challenge comes to battery and low-bandwidth PAN. Heavy engergy
> could cause serious damage to the human-body. Not 5 volts, 4/5th of
> TCP would have to be trashed, so some such…
>
> -prokash
>
> -----Original Message-----
> From: Moreira, Alberto [mailto:xxxxx@compuware.com]
> Sent: Tuesday, February 17, 2004 11:57 AM
> To: Windows System Software Devs Interest List
> Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>
>
> Maybe put the whole of the TCP/IP on the peripheral card ?
>
> Alberto.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Sinha, Prokash
> Sent: Tuesday, February 17, 2004 2:46 PM
> To: Windows System Software Devs Interest List
> Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>
>
> What would be your I/O architecture, when video clips would
be sent to
> one of your receiver, and the information would flow thru PAN
> (personal area network ), yes our skin is our network to a
> presentation manager. Not too far out :-). And some people are
> actively working on this.
>
> -prokash
>
>
>
> -----Original Message-----
> From: Moreira, Alberto [mailto:xxxxx@compuware.com]
> Sent: Tuesday, February 17, 2004 11:16 AM
> To: Windows System Software Devs Interest List
> Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>
>
> That’s why people created signal processors, no ? To do
this kind of
> work ?
> So, how about having a disk processor and a video signal
processor, so
> that the stream comes directly from mass storage to the
disk processor
> to the video processor to the screen ? Look, ma, no CPU ? I believe
> there’s a lot of offloading we can do if only we adopt a
more rational
> I/O architecture.
>
>
> Alberto.
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Loren Wilton
> Sent: Tuesday, February 17, 2004 10:14 AM
> To: Windows System Software Devs Interest List
> Subject: Re: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
>
>
> > The best interrupt is no interrupt. Things like AV playback
> should be
> > handled 100% on the south side of the bus, no need to involve the
> processor
> > in it. I believe that if you run into performance issues
because of
> > interrupt latency, it’s about time to migrate to a better
> architecture
> > !
>
> Um. Everything is a pipe of some sort or other. Sooner or
later you
> start having problems with turbulent flow around the
corners, or the
> laminar flows detatching from the walls.
>
> Saying “just throw it over the wall, that solves all MY
problems” may
> be true. It doesn’t, however, solve all of the problems with the
> original implementation.
>
> For instance, video decoding is complicated enough that the
only way
> it is going to get done practically on the south side of
the bridge is
> by putting a reasonably general-purpose processor on the
south side of
> the bridge. And that processor is going to have to get bits from a
> source, transform them in some manner, and push them out to a
> destination. And the translation is unlikely to be 1:1, so
there have
> to be flow rate conversions.
>
> Now, you can “solve” the problem, for any specific singular
case, by
> making the transport into hardware fifos that control the
wait-state
> line to the processor. Thus making the whole thing
synchronous, and
> the average processor utilization somewhere around 35% max, and
> limiting the kinds of transformations that can be
accomplished. This
> might “eliminate” the problems of interrupts. But it
doesn’t really
> solve the problem, it just gives you a problem that is
probably worse.
>
> The only way to “eliminate” interrupts is to design a
system such that
> when peripheral data becomes available to a processing thread, the
> thread is scheduled automatically by the hardware. But scheduled
> doesn’t necessarily mean run; you still have to get some processor
> cycles somewhere. And that might be stealing them from
something else
> that reall wants them too. Which gets you into priority
handling on
> scheduling and slicing and deciding what to assign to which
piece of
> hardware, which gets you into cache nearness considerations and
> ability to get to the specific hardware.
>
> Which is to say, it solves nothing. You still have all the same
> problems to solve, they are just wrapped in a different
color ribbon.
>
> Loren
>
>
> —
> 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
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@stratus.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@stratus.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.

[OSR_Community_User]

The iPic puts the whole stack in 256 bytes Search for the iPic on the web

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Wednesday, February 18, 2004 10:16 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

How big is the TCP stack code ? I’m going to bet it fits in one chip
inside
a card smaller than a CompactFlash.

The whole iPaq is such a chip, the rest is screen, case to be holdable and
the
battery.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.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@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[Prokash_Sinha-1]

Thanks, but the whole might not be whole if we just take the
base line of tcp/ip as per original SRC’s documentation dated back
late 70s or early 80s. But it is really amazing. And they must have
the basic http get/put etc. SOunds like (frying)PAN is
not such a bad idea

-prokash

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Jamey Kirby
Sent: Wednesday, February 18, 2004 10:37 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

The iPic puts the whole stack in 256 bytes Search for the iPic on the web

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Wednesday, February 18, 2004 10:16 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC

How big is the TCP stack code ? I’m going to bet it fits in one chip
inside
a card smaller than a CompactFlash.

The whole iPaq is such a chip, the rest is screen, case to be holdable and
the
battery.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.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@storagecraft.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