One mouse click, 2 PC's
in [Design]
|
From: Tim Watts on 14 Jun 2010 19:10 On Mon, 14 Jun 2010 15:45:22 -0700, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wibbled: > "mpm" <mpmillard(a)aol.com> wrote in message > news:92354892-0f43-4c64- ade1-497be8af3410(a)r27g2000yqb.googlegroups.com... >>Uh-huh..... then explain how the average microprocessor services its >>interrupts when more than one interrupt are pending!! > > He's used "non-polled" to mean "interrupt driven," e.g., that "when this > here signal line is asserted, there's some hardware mechanism in place > that diverts the CPU to run off and execute a certain chunk of code as > immediately as possible" -- vs. "polled" which is generally understoof > as a chunk of code that's being executed on a regular basis (due to a > timer overflow or similar) that specifically checks an I/O line. > > In general interrupt-driven approaches have lower latencies between > "something happening" and the code that handles that "something" being > executed. Another benefit of interrupt-driven I/O is that when no > devices require attention, on CPU cycles whatsoever are spent worrying > about hose devices... whereas with polled I/O you're chewing up some CPU > cycles (although often a negligible percentage) verifying that, ah, OK, > none of the devices need any attention. > > The USB *bus* actually *is* polled, but the chipsets that interface to > it generally perform that polling in hardware and then interrupt the > main CPU if anything "interesting" has occurred. In a very real sense, > a USB bus controller is a rudimentary I/O co-processor: It takes care of > the drudge work of polling and hence provide the benefits of > interrupt-driven I/O to the main CPU. > >>The net effect of either yields delays that are quite similar to what >>you would expect from polling. > > I don't think you can say that without specifying a polling rate, and > certainly the distributions are different: Interrupt-driven I/O has > latencies that peak at some small value and then a "long tail" that's > created when interrupts are being held off for one reason or another. > Polling I/O has latencies that are very close to a uniform distribution. > > Personally I find polling using the main CPU distasteful once it hits > more than about 10Hz. > > ---Joel Not to mention that some OSes (specifically Linux, because I know it does) implement many device drivers as a bottom-half and top-half model. The top-half gets the interrupt and deals (in as short a time as possible) the absolute minimum to make the device happy (like emptying a limited capacity buffer into RAM or noting some state) then signals the bottom-half to come along and do the long slow boring processing when it can. As the bottom-half is implemented as a kernel tasklet which might conceivably require the further services of a kernel thread or possibly even a user space handler there are no guarantees that being "interrupt driven" means it is serviced to completion in a microsecond. -- Tim Watts Managers, politicians and environmentalists: Nature's carbon buffer.
From: Archimedes' Lever on 14 Jun 2010 19:11 On Mon, 14 Jun 2010 13:43:13 -0700 (PDT), mpm <mpmillard(a)aol.com> wrote: >On Jun 14, 10:03�am, AZ Nomad <aznoma...(a)PremoveOBthisOX.COM> wrote: >> On Mon, 14 Jun 2010 04:59:42 -0700, Archimedes' Lever <OneBigLe...(a)InfiniteSeries.Org> wrote: >> >On Mon, 14 Jun 2010 06:17:36 -0400, JW <n...(a)dev.null> wrote: >> >>On Sun, 13 Jun 2010 21:08:50 -0700 Archimedes' Lever >> >><OneBigLe...(a)InfiniteSeries.Org> wrote in Message id: >> >><3qab16l70s0s0pn9rqoa5ull13dlspi...(a)4ax.com>: >> >> >>>On Sun, 13 Jun 2010 20:34:22 -0500, AZ Nomad >> >>><aznoma...(a)PremoveOBthisOX.COM> wrote: >> >> >>>>On Sun, 13 Jun 2010 18:20:24 -0700, Artemus <bo...(a)invalid.org> wrote: >> >> >>>>>"Ken Ingram" <kening...(a)overden.com> wrote in message >> >>>>>news:4c157293.3891718(a)news.tpg.com.au... >> >>>>>> Is there any practical way that would enable me to use a single mouse >> >>>>>> click in order to start a sequence at exactly the same time on two >> >>>>>> separate PC's (identical units)? >> >> >>>>>> I suppose this means hacking into the mouse lead itself, but how to >> >>>>>> find the relevant wires? >> >> >>>>>> Ken Ingram >> >> >>>>>Even if you succeed with the wiring the sequence start isn't going >> >>>>>to be that exact as the mouse is a polled device. >> >>>>>Art >> >> >>>>Actually, it isn't. >> >> >>> �Mice are polled devices. >> >> >>AlwaysWrong. PS/2 mice use an interrupt. You big dummy. >> > �Do interrupts not also get polled in cyclic fashion? �Can you guarantee >> >that both machines will poll their respective interrupts at the same >> >moment? >> >> Interrupts aren't polled. �Don't you even know the english word >> "interrupt"?- Hide quoted text - >> >> - Show quoted text - > >Uh-huh..... then explain how the average microprocessor services its >interrupts when more than one interrupt are pending!! > >You will find that on most devices, the interrupts are priortized >(either in hardware, or in user-configurable software registers that >control the interrupt hierarchy). >The net effect of either yields delays that are quite similar to what >you would expect from polling. > >-mpm In other words, they *are* "hard" interrupts WHEN they do get polled, which they always eventually will, but it is a round robin polling regardless. Bwuahahahahahahahahahaha!
From: Tim Watts on 14 Jun 2010 19:16 On Mon, 14 Jun 2010 23:10:00 +0000, Tim Watts <tw(a)dionic.net> wibbled: > Not to mention that some OSes (specifically Linux, because I know it > does) implement many device drivers as a bottom-half and top-half model. > The top-half gets the interrupt and deals (in as short a time as > possible) the absolute minimum to make the device happy (like emptying a > limited capacity buffer into RAM or noting some state) then signals the > bottom-half to come along and do the long slow boring processing when it > can. As the bottom-half is implemented as a kernel tasklet which might > conceivably require the further services of a kernel thread or possibly > even a user space handler there are no guarantees that being "interrupt > driven" means it is serviced to completion in a microsecond. On an aside, too many interrupts can of course impair system performance. Some of the Intel gigabit ethernet chipsets employs an optional scheme called interrupt-coalescing which, instead of causing an interrupt on every packet received (for example), can instead buffer incoming packets and fire an interrupt once every n-packets. At least one of the linux ethernet device drivers even has an option to switch it into polled handling for high throughput (note, not low latency) devices as it is deemed to give a net gain in efficiency for some scenarios. -- Tim Watts Managers, politicians and environmentalists: Nature's carbon buffer.
From: Joel Koltner on 14 Jun 2010 19:23 "Tim Watts" <tw(a)dionic.net> wrote in message news:hv6cs8$7gc$6(a)news.eternal-september.org... > Not to mention that some OSes (specifically Linux, because I know it > does) implement many device drivers as a bottom-half and top-half model. > The top-half gets the interrupt and deals (in as short a time as > possible) the absolute minimum to make the device happy (like emptying a > limited capacity buffer into RAM or noting some state) then signals the > bottom-half to come along and do the long slow boring processing when it > can. Windows does this as well -- the interrupt service routine is *supposed* to basically "shut the device up" and then queue up a deferred procedure call (DPCs)... although there's nothing that actually forces you to do this, other than customers complaining that your device driver makes their mouse pointer unresponsive or whatever. :-) > As the bottom-half is implemented as a kernel tasklet which might > conceivably require the further services of a kernel thread or possibly > even a user space handler there are no guarantees that being "interrupt > driven" means it is serviced to completion in a microsecond. I've been told that on heavily-loaded server systems (where the various execution quanta are pretty long relative to desktop systems) DPC latency is often easily in the hundreds of milliseconds range and can actually break one second if you're particularly unlucky. ---Joel
From: Joel Koltner on 14 Jun 2010 19:29
"Tim Watts" <tw(a)dionic.net> wrote in message news:hv6d7r$7gc$7(a)news.eternal-september.org... > At least one of the linux > ethernet device drivers even has an option to switch it into polled > handling for high throughput (note, not low latency) devices as it is > deemed to give a net gain in efficiency for some scenarios. The Windows (NT and later) parallel port driver is purportedly like this: While a parallel port can generate interrupts, these days many printers will accept data bytes very rapidly (e.g., >1MBps) until their buffers are full, so getting an interrupt for each data byte consumes massive CPU time. I've seen a fair amount of hardware that provides some option for, "generate an interrupt when the FIFO is half-full *OR* as soon as there's ANY data in it *and a certain timeout has elapsed since the last byte was received*" as a means of trying to provide high-throughput without slamming the system. (Indeed, you see the same sort of thing with block-based protocols such as USB: In USB to serial converters, they'll usually wait a bit after receiving the first serial character to transmit, in the hopes that more will come since getting on the USB bus at all means they'll be sending, e.g., 64 bytes and it'll be largely wasted if there's only a few bytes of payload data.) ---Joel |