polling / interrupt
|
From: Robert Myers on 26 May 2010 14:14 On May 26, 1:43 pm, timcaff...(a)aol.com (Tim McCaffrey) wrote: > > There is a bit of future shock with modern embedded systems. I've worked on a > I/O board that offloaded Disk & Network I/O, handled Gigabit speeds on the > network (with a complete TCP/IP stack) & 4G Fiber channel, and it didn't > (really) use interrupts. All with a single 800 Mhz MIPS processor. > > Well, they were there, but it would have been more efficient just to use > polling (the interrupts just kicked started the poll, more or less), but I > couldn't convince the PTW to make the switch. All the real processing on the > system was done with the interrupts disabled. > That all sounds pretty sensible to me, but, to be honest, had I such a board, I wouldn't care whether it polled or used interrupts, just so long as it kept as many interrupts as possible away from expensive and power hungry processors that are doing whatever it is that I'm really interested in. For the life of me, I can't understand the logic of computer systems that shovel all tasks into one hopper, even if it means constantly interrupting tasks that might well have interrupted another task. I suspect the influence of some legacy (PC?) mentality, but I'm sure there is someone here who can set me straight. Robert.
From: nmm1 on 26 May 2010 14:33 In article <7b6474ee-81dd-4ab7-be1d-756a544ed515(a)u7g2000vbq.googlegroups.com>, Robert Myers <rbmyersusa(a)gmail.com> wrote: > >For the life of me, I can't understand the logic of computer systems >that shovel all tasks into one hopper, even if it means constantly >interrupting tasks that might well have interrupted another task. I >suspect the influence of some legacy (PC?) mentality, but I'm sure >there is someone here who can set me straight. I can correct your query. The 'mentality' is older than personal computers, goes back as long as I can recall, and has NEVER made any sense! I think that it's a relic of the days when the hardware designers were subdeities, and the software people were expected to be thankful for whatever they were given. But the origin was before my time. Regards, Nick Maclaren.
From: Rick Jones on 26 May 2010 14:46 Tim McCaffrey <timcaffrey(a)aol.com> wrote: > There is a bit of future shock with modern embedded systems. I've > worked on a I/O board that offloaded Disk & Network I/O, handled > Gigabit speeds on the network (with a complete TCP/IP stack) & 4G > Fiber channel, and it didn't (really) use interrupts. All with a > single 800 Mhz MIPS processor. Ah, but with what size TCP segments or UDP datagrams?-) It is one thing to handle Gigabit speeds with CKO and TSO (and perhaps LRO) and large sends but getting to link-rate with small segments is another entirely. rick jones -- firebug n, the idiot who tosses a lit cigarette out his car window these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: FredK on 26 May 2010 15:49 <nmm1(a)cam.ac.uk> wrote in message news:htjphb$edj$1(a)smaug.linux.pwf.cam.ac.uk... > In article > <7b6474ee-81dd-4ab7-be1d-756a544ed515(a)u7g2000vbq.googlegroups.com>, > Robert Myers <rbmyersusa(a)gmail.com> wrote: >> >>For the life of me, I can't understand the logic of computer systems >>that shovel all tasks into one hopper, even if it means constantly >>interrupting tasks that might well have interrupted another task. I >>suspect the influence of some legacy (PC?) mentality, but I'm sure >>there is someone here who can set me straight. > > I can correct your query. The 'mentality' is older than personal > computers, goes back as long as I can recall, and has NEVER made > any sense! I think that it's a relic of the days when the hardware > designers were subdeities, and the software people were expected to > be thankful for whatever they were given. But the origin was before > my time. > You are on a PDP11 and you want to have IO. Propose the alternative to interrupts that provides low latency servicing of the device. Today you can create elaborate IO cards with offload engines, but ultimately you need to talk to the actual computer system which is otherwise engaged in general computing. On many (most? all?) of todays SMP systems you can generally (depending on the OS I suppose) direct IO interrupts to specific CPUs and have CPUs that may get no interrupts (or only limited interrupts like a clock interrupt).
From: nmm1 on 26 May 2010 17:08
In article <htjt4h$pi0$1(a)usenet01.boi.hp.com>, FredK <fred.nospam(a)dec.com> wrote: > >>>For the life of me, I can't understand the logic of computer systems >>>that shovel all tasks into one hopper, even if it means constantly >>>interrupting tasks that might well have interrupted another task. I >>>suspect the influence of some legacy (PC?) mentality, but I'm sure >>>there is someone here who can set me straight. >> >> I can correct your query. The 'mentality' is older than personal >> computers, goes back as long as I can recall, and has NEVER made >> any sense! I think that it's a relic of the days when the hardware >> designers were subdeities, and the software people were expected to >> be thankful for whatever they were given. But the origin was before >> my time. > >You are on a PDP11 and you want to have IO. Propose the alternative to >interrupts that provides low latency servicing of the device. Today you can >create elaborate IO cards with offload engines, but ultimately you need to >talk to the actual computer system which is otherwise engaged in general >computing. Sigh. You really haven't been following this group. There are two issues there: 1) There are plenty of well-tried alternatives to interrupts though, if you start with a PDP 10, I will agree that they are a plausible approach. 2) The context of this wasn't interrupts versus something else, but funnelling ALL such actions though a single mechanism that is unsatisfactory for almost all of them. For example, there is absolutely NO reason why a floating-point fixup need execute a FLIH in God mode, only to be restored to the mode of the process that was interrupted. The Ferranti Atlas/Titan and ICL 1900 didn't do it. Regards, Nick Maclaren. |