Interrupts?

[Spamlet]

Not seen much about interrupts, and not even entirely sue what they are.
But I've noticed - coincidentally or not - that since I did the delete of MS
Update software to get back to using the less processor hogging Windows
Update, I keep seeing interrupts flare up to a large percentage of the cpu.
This is on an old Inspiron 2600 laptop with only 260 meg of memory at the
moment. It was recently updated to an 80gig WD hard drive, which seems to
be running well, and this is with XPHome SP3 all up to date.

There seems to be no way of seeing what these interrupts are for, as they
change too quickly to open a properties window for them in Process Explorer.
How much of the cpu should they take up? Might they have been an underlying
problem that was interfering with MS Update?

Cheers,

S

 

[Tim Meddick]

"Interrupts" are used by programs to call hardware resources.

For instance : the ps2 mouse is typically Interrupt 12 and the operating
system (software in itself) and other programs will use interrupt 12 to
access the mouse.

All interrupts are allocated to a hardware resource.

To see what interrupts are allocated to what hardware on your PC -

type "devmgmt.msc" into the "Run"box on the Start Menu to start the Device
Manager.

Then in Device Manager, click on "View" from the top menus, and then select
"Resources by type" on the drop-down menu.

Then click on the + sign next to the item named "Interrupt Request (IRQ)" -
like on a folder in explorer, to see the expanded list of hardware and
there allocated interrupts.

==

Cheers, Tim Meddick, Peckham, London.




"Spamlet" <spam.morespam@invalid.invalid> wrote in message
news:i5ms93$lmo$1@news.eternal-september.org...
> Not seen much about interrupts, and not even entirely sue what they are.
> But I've noticed - coincidentally or not - that since I did the delete of
> MS Update software to get back to using the less processor hogging
> Windows Update, I keep seeing interrupts flare up to a large percentage
> of the cpu. This is on an old Inspiron 2600 laptop with only 260 meg of
> memory at the moment. It was recently updated to an 80gig WD hard drive,
> which seems to be running well, and this is with XPHome SP3 all up to
> date.
>
> There seems to be no way of seeing what these interrupts are for, as they
> change too quickly to open a properties window for them in Process
> Explorer. How much of the cpu should they take up? Might they have been
> an underlying problem that was interfering with MS Update?
>
> Cheers,
>
> S
>

 

[Spamlet]

Thanks Tim,

I've not looked at that part of the device manager before.

There are 16 'Interrupt Request' devices listed, and eight of them use the
same number: 9.

How do I work out which one or ones are hogging the CPU? And, if I
understand you right, which part of the system is trying to use that
interrupt device and causing it to hog the CPU.

Presumably as I don't have much RAM, the hard drive will get a lot of
activity, but this is fairly new and much quicker than the old one so far
(Though I don't know why I have two IDE channels and only one hard drive?)

Cheers,

S



"Tim Meddick" <timmeddick@o2.co.uk> wrote in message
news:ubA1N9jSLHA.5716@TK2MSFTNGP02.phx.gbl...
> "Interrupts" are used by programs to call hardware resources.
>
> For instance : the ps2 mouse is typically Interrupt 12 and the operating
> system (software in itself) and other programs will use interrupt 12 to
> access the mouse.
>
> All interrupts are allocated to a hardware resource.
>
> To see what interrupts are allocated to what hardware on your PC -
>
> type "devmgmt.msc" into the "Run"box on the Start Menu to start the Device
> Manager.
>
> Then in Device Manager, click on "View" from the top menus, and then
> select "Resources by type" on the drop-down menu.
>
> Then click on the + sign next to the item named "Interrupt Request
> (IRQ)" - like on a folder in explorer, to see the expanded list of
> hardware and there allocated interrupts.
>
> ==
>
> Cheers, Tim Meddick, Peckham, London.
>
>
>
>
> "Spamlet" <spam.morespam@invalid.invalid> wrote in message
> news:i5ms93$lmo$1@news.eternal-september.org...
>> Not seen much about interrupts, and not even entirely sue what they are.
>> But I've noticed - coincidentally or not - that since I did the delete of
>> MS Update software to get back to using the less processor hogging
>> Windows Update, I keep seeing interrupts flare up to a large percentage
>> of the cpu. This is on an old Inspiron 2600 laptop with only 260 meg of
>> memory at the moment. It was recently updated to an 80gig WD hard drive,
>> which seems to be running well, and this is with XPHome SP3 all up to
>> date.
>>
>> There seems to be no way of seeing what these interrupts are for, as they
>> change too quickly to open a properties window for them in Process
>> Explorer. How much of the cpu should they take up? Might they have been
>> an underlying problem that was interfering with MS Update?
>>
>> Cheers,
>>
>> S
>>
>

 

[Tim Meddick]

To answer you last question, first.

The reason you have two IEDE channels is that each channel can take two IDE
drives each. So, with two channels, that's space for 4 drives.

Usually drives are arranged thus :

Primary IDE Channel [position 1] = Master:- Hard Drive [C
[position 2] = Slave:- Hard Drive [D

Secondary IDE Channel [position 1] = Master:- CD/DVD Drive [E
[position 2] = Slave:- Hard Drive
[D

.....a cd/dvd drive (when present in a new machine) occupying the 1st
position on the Secondary IDE channel. If a purchaser of a new PC buys an
additional Hard drive for extra media content or space for backups, it
would normally be connected to position 2 of the Primary IDE channel,
making it slave to the system or [c drive. While position 2 of the
Secondary IDE channel, would be for a second cd/dvd or maybe a cd/dvd
re-writer. The whole idea behind the PC, is that there is lots of room,
built-in, to accommodate additions, expansions and upgrades....

As I may have said in a previous post (or many of them), the way to see
what application or "running process" is "hogging" system resources - and
by resources I really mean RAM - is to open the Window's Task Manager.

Click on an empty area of the taskbar and right-click on it.

Choose "Task Manager" from the pop-up menu.

Click on the column heading "Memory Usage" to make the process-list get in
order, similar to doing the same with files in Explorer. You may need to
click on the heading twice to get them in order - largest mem usage at the
top down to lowest at the bottom.

The task or process-list, refreshes itself once every five seconds by
default (but you can change that) so by arranging the columns in order of
size of memory usage - then the application or service[es] that are
taking up most RAM are always going to be at the top of the list.

This is how I found out that Window's Update takes up so much RAM when it's
running, that I can do nothing else on the PC till it's finished (seeing
how I need it, I have to let it run). So, when I feel the system starting
to run a bit slow, I open up Task Manager and if I see the process
"wuauclt.exe" listed, I can go and get a cup of tea and have a sit down
until then.



One is obviously going to be for the system [c drive, and an other

==

Cheers, Tim Meddick, Peckham, London.




"Spamlet" <spam.morespam@invalid.invalid> wrote in message
news:i5ok6m$1vi$1@news.eternal-september.org...
> Thanks Tim,
>
> I've not looked at that part of the device manager before.
>
> There are 16 'Interrupt Request' devices listed, and eight of them use
> the same number: 9.
>
> How do I work out which one or ones are hogging the CPU? And, if I
> understand you right, which part of the system is trying to use that
> interrupt device and causing it to hog the CPU.
>
> Presumably as I don't have much RAM, the hard drive will get a lot of
> activity, but this is fairly new and much quicker than the old one so far
> (Though I don't know why I have two IDE channels and only one hard
> drive?)
>
> Cheers,
>
> S
>
>
>
> "Tim Meddick" <timmeddick@o2.co.uk> wrote in message
> news:ubA1N9jSLHA.5716@TK2MSFTNGP02.phx.gbl...
>> "Interrupts" are used by programs to call hardware resources.
>>
>> For instance : the ps2 mouse is typically Interrupt 12 and the
>> operating system (software in itself) and other programs will use
>> interrupt 12 to access the mouse.
>>
>> All interrupts are allocated to a hardware resource.
>>
>> To see what interrupts are allocated to what hardware on your PC -
>>
>> type "devmgmt.msc" into the "Run"box on the Start Menu to start the
>> Device Manager.
>>
>> Then in Device Manager, click on "View" from the top menus, and then
>> select "Resources by type" on the drop-down menu.
>>
>> Then click on the + sign next to the item named "Interrupt Request
>> (IRQ)" - like on a folder in explorer, to see the expanded list of
>> hardware and there allocated interrupts.
>>
>> ==
>>
>> Cheers, Tim Meddick, Peckham, London.
>>
>>
>>
>>
>> "Spamlet" <spam.morespam@invalid.invalid> wrote in message
>> news:i5ms93$lmo$1@news.eternal-september.org...
>>> Not seen much about interrupts, and not even entirely sue what they
>>> are. But I've noticed - coincidentally or not - that since I did the
>>> delete of MS Update software to get back to using the less processor
>>> hogging Windows Update, I keep seeing interrupts flare up to a large
>>> percentage of the cpu. This is on an old Inspiron 2600 laptop with only
>>> 260 meg of memory at the moment. It was recently updated to an 80gig
>>> WD hard drive, which seems to be running well, and this is with XPHome
>>> SP3 all up to date.
>>>
>>> There seems to be no way of seeing what these interrupts are for, as
>>> they change too quickly to open a properties window for them in Process
>>> Explorer. How much of the cpu should they take up? Might they have
>>> been an underlying problem that was interfering with MS Update?
>>>
>>> Cheers,
>>>
>>> S
>>>
>>
>
>

 

[Paul]

Spamlet wrote:
> Thanks Tim,
>
> I've not looked at that part of the device manager before.
>
> There are 16 'Interrupt Request' devices listed, and eight of them use the
> same number: 9.
>
> How do I work out which one or ones are hogging the CPU? And, if I
> understand you right, which part of the system is trying to use that
> interrupt device and causing it to hog the CPU.
>
> Presumably as I don't have much RAM, the hard drive will get a lot of
> activity, but this is fairly new and much quicker than the old one so far
> (Though I don't know why I have two IDE channels and only one hard drive?)
>
> Cheers,
>
> S

If you see 16 entries, your machine is handling interrupts using PIC
(programmable interrupt controller). The other option, is APIC (which
may be a BIOS option). APIC has a couple features, such as being able
to forward interrupts to a particular processor on a multiprocessor
(or multicore) machine. APIC interrupt numbers also go a bit higher,
and the PCI bus INTA/B/C/D signals may be listed in 16..23 . APIC
can even be used on a single core computer, but in that case, there
is no need to steer the interrupts because they all go to the same
place.

http://en.wikipedia.org/wiki/Intel_APIC_Architecture

This is my Device Manager summary report in the interrupt section.
I'm running APIC. You can see there is still sharing going on.
On IRQ 18, my WinTV card (on PCI bus), the network interface (on PCI Express
bus), and the chipset, are all sharing the same IRQ. Interrupt
handlers have to be able to deal with this sharing.

******************** IRQ SUMMARY ********************
IRQ Usage Summary:
(ISA) 0 System timer
(ISA) 1 Standard 101/102-Key or Microsoft Natural PS/2 Keyboard
(ISA) 6 Standard floppy disk controller
(ISA) 8 System CMOS/real time clock
(ISA) 9 Microsoft ACPI-Compliant System
(ISA) 13 Numeric data processor
(PCI) 15 Hauppauge WinTV 878/9 WDM Aux Driver
(PCI) 15 Intel(R) ICH9 Family SMBus Controller - 2930
(PCI) 16 Intel(R) X38/X48 Express Chipset PCI Express Root Port - 29E9
(PCI) 16 NVIDIA GeForce 7900 GT/GTO
(PCI) 16 Intel(R) ICH9 Family USB Universal Host Controller - 2937
(PCI) 16 Standard Dual Channel PCI IDE Controller
(PCI) 17 Intel(R) ICH9 Family PCI Express Root Port 1 - 2940
(PCI) 17 Intel(R) ICH9 Family PCI Express Root Port 5 - 2948
(PCI) 18 Intel(R) ICH9 Family USB Universal Host Controller - 2939
(PCI) 18 Intel(R) ICH9 Family USB2 Enhanced Host Controller - 293C
(PCI) 18 Intel(R) ICH9 Family PCI Express Root Port 3 - 2944 <---
(PCI) 18 Marvell Yukon 88E8056 PCI-E Gigabit Ethernet Controller <---
(PCI) 18 Intel(R) ICH9 Family USB Universal Host Controller - 2936
(PCI) 18 Hauppauge WinTV 878/9 WDM Video Driver <---
(PCI) 19 Intel(R) ICH9 Family USB Universal Host Controller - 2935
(PCI) 19 VIA OHCI Compliant IEEE 1394 Host Controller
(PCI) 21 Intel(R) ICH9 Family USB Universal Host Controller - 2938
(PCI) 22 Microsoft UAA Bus Driver for High Definition Audio
(PCI) 22 Intel(R) ICH9R/DO/DH 4 port Serial ATA Storage Controller 1 - 29
(PCI) 22 Intel(R) ICH9 Family 2 port Serial ATA Storage Controller 2 - 29
(PCI) 23 Intel(R) ICH9 Family USB Universal Host Controller - 2934
(PCI) 23 Intel(R) ICH9 Family USB2 Enhanced Host Controller - 293A

I don't know of a tool for logging specific interrupt counts in Windows. In Linux,
you can use /proc/interrupts to get the info. I still haven't figured
out how to do the equivalent of this in Windows.

http://www.linuxtopia.org/online_bo...istration_guide/centos5_s1-proc-topfiles.html

"3.2.11. /proc/interrupts

For a multi-processor machine, this file may look slightly different:

CPU0 CPU1
0: 1366814704 0 XT-PIC timer
1: 128 340 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
8: 0 1 IO-APIC-edge rtc
12: 5323 5793 IO-APIC-edge PS/2 Mouse
13: 1 0 XT-PIC fpu
16: 11184294 15940594 IO-APIC-level Intel EtherExpress Pro 10/100 Ethernet
20: 8450043 11120093 IO-APIC-level megaraid
30: 10432 10722 IO-APIC-level aic7xxx
31: 23 22 IO-APIC-level aic7xxx
NMI: 0
ERR: 0 "

In that example, APIC is able to steer interrupts to a particular CPU.
CPU0 is getting all the timer interrupts. A high count there would
not be a cause for concern, because the timer is being used by
the OS a lot.

I had great hopes for an article with this title, but in fact
the facilities available look pretty poor. "Disabling hardware"
is a pathetic way to debug things, especially in a case where
the hardware cannot be physically removed, to be sure it is
not affecting system state.

"Debugging an Interrupt Storm"
http://msdn.microsoft.com/en-us/library/ff540586(VS.85).aspx

According to this, when things share an IRQ, an ISR (interrupt
service routine) chain is used to sequentially attempt to service
the interrupt. Different ISRs are tried until the interrupt is cleared.
To get some idea what hardware is interrupting, you'd need
the ISR routine to count how many times it successfully
handled an interrupt. An ISR may queue up a DPC, to finish
handling the interrupt - a DPC runs at user level, rather
than interrupt level, and that allows the ISR to be fast
and lightweight. Process Explorer can show you the level of
DPC activity, which might be proof that real interrupt
events are happening (since they finish the servicing
needed by the hardware). If there was something wrong
with interrupts, perhaps you'd see a mismatch between
the time spent handling interrupts, and the amount of
DPC activity.

http://www.microsoft.com/whdc/archive/apic.mspx

"4. The operating system calls the first ISR in the chain.
5. The ISR probes the hardware and attempts to handle the interrupt.
6. If there are additional ISRs, the operating system goes on to
the next one and returns to step 5."

HTH,
Paul

>
>
>
> "Tim Meddick" <timmeddick@o2.co.uk> wrote in message
> news:ubA1N9jSLHA.5716@TK2MSFTNGP02.phx.gbl...
>> "Interrupts" are used by programs to call hardware resources.
>>
>> For instance : the ps2 mouse is typically Interrupt 12 and the operating
>> system (software in itself) and other programs will use interrupt 12 to
>> access the mouse.
>>
>> All interrupts are allocated to a hardware resource.
>>
>> To see what interrupts are allocated to what hardware on your PC -
>>
>> type "devmgmt.msc" into the "Run"box on the Start Menu to start the Device
>> Manager.
>>
>> Then in Device Manager, click on "View" from the top menus, and then
>> select "Resources by type" on the drop-down menu.
>>
>> Then click on the + sign next to the item named "Interrupt Request
>> (IRQ)" - like on a folder in explorer, to see the expanded list of
>> hardware and there allocated interrupts.
>>
>> ==
>>
>> Cheers, Tim Meddick, Peckham, London.
>>
>>
>>
>>
>> "Spamlet" <spam.morespam@invalid.invalid> wrote in message
>> news:i5ms93$lmo$1@news.eternal-september.org...
>>> Not seen much about interrupts, and not even entirely sue what they are.
>>> But I've noticed - coincidentally or not - that since I did the delete of
>>> MS Update software to get back to using the less processor hogging
>>> Windows Update, I keep seeing interrupts flare up to a large percentage
>>> of the cpu. This is on an old Inspiron 2600 laptop with only 260 meg of
>>> memory at the moment. It was recently updated to an 80gig WD hard drive,
>>> which seems to be running well, and this is with XPHome SP3 all up to
>>> date.
>>>
>>> There seems to be no way of seeing what these interrupts are for, as they
>>> change too quickly to open a properties window for them in Process
>>> Explorer. How much of the cpu should they take up? Might they have been
>>> an underlying problem that was interfering with MS Update?
>>>
>>> Cheers,
>>>
>>> S
>>>
>
>

 

[Spamlet]

Thanks Tim,

I'm already using Process Explorer: which is how I could see the interrupts
taking up cpu in the handy little graphs that are displayed in the
notification area once you replace Task Manager with Process Explorer as I
recommend you do, as TM is pretty crude once you have tried PE. In this
case the interrupts are taking up cpu not ram, and they are too transient to
get any info from other than they can sometimes take as much as 80% of the
cpu.

I discovered this, like you, after I began looking into windows update
taking all my ram, and, apparently, solved that problem, through a comment
made by PA Bear. He had asked me to look at how my laptop was accessing the
update site. Interestingly, it appeared that I was using windows update as
it was going via a link that had something like 'msupdate/windowsudate' in
it, but paging down on that site I still found the tick box to uninstall ms
update components from my computer. I was surprised to see this, but ticked
it and tried again, and the next time I accessed the link there was no tick
box at the bottom of the page. Since then the laptop has not hung on
updates taking up ram (I haven't actually noticed any updates at all
mind...), but I have noticed these interrupts taking up cpu which I had not
noticed before. I did wonder if they might represent something still
looking for that old update process. (Incidentally I've also deleted all
the google updating files from my computer, as I suspected they might be
getting in the way too, and had an irritating habit of turning themselves
back on no matter how many times I 'disabled' them)

Cheers,

S




"Tim Meddick" <timmeddick@o2.co.uk> wrote in message
news:%23CoZ7UsSLHA.456@TK2MSFTNGP06.phx.gbl...
> To answer you last question, first.
>
> The reason you have two IEDE channels is that each channel can take two
> IDE drives each. So, with two channels, that's space for 4 drives.
>
> Usually drives are arranged thus :
>
> Primary IDE Channel [position 1] = Master:- Hard Drive [C
> [position 2] = Slave:- Hard Drive [D
>
> Secondary IDE Channel [position 1] = Master:- CD/DVD Drive [E
> [position 2] = Slave:- Hard Drive
> [D
>
> ....a cd/dvd drive (when present in a new machine) occupying the 1st
> position on the Secondary IDE channel. If a purchaser of a new PC buys
> an additional Hard drive for extra media content or space for backups, it
> would normally be connected to position 2 of the Primary IDE channel,
> making it slave to the system or [c drive. While position 2 of the
> Secondary IDE channel, would be for a second cd/dvd or maybe a cd/dvd
> re-writer. The whole idea behind the PC, is that there is lots of room,
> built-in, to accommodate additions, expansions and upgrades....
>
> As I may have said in a previous post (or many of them), the way to see
> what application or "running process" is "hogging" system resources - and
> by resources I really mean RAM - is to open the Window's Task Manager.
>
> Click on an empty area of the taskbar and right-click on it.
>
> Choose "Task Manager" from the pop-up menu.
>
> Click on the column heading "Memory Usage" to make the process-list get in
> order, similar to doing the same with files in Explorer. You may need to
> click on the heading twice to get them in order - largest mem usage at the
> top down to lowest at the bottom.
>
> The task or process-list, refreshes itself once every five seconds by
> default (but you can change that) so by arranging the columns in order of
> size of memory usage - then the application or service[es] that are
> taking up most RAM are always going to be at the top of the list.
>
> This is how I found out that Window's Update takes up so much RAM when
> it's running, that I can do nothing else on the PC till it's finished
> (seeing how I need it, I have to let it run). So, when I feel the system
> starting to run a bit slow, I open up Task Manager and if I see the
> process "wuauclt.exe" listed, I can go and get a cup of tea and have a sit
> down until then.
>
>
>
> One is obviously going to be for the system [c drive, and an other
>
> ==
>
> Cheers, Tim Meddick, Peckham, London.
>
>
>
>
> "Spamlet" <spam.morespam@invalid.invalid> wrote in message
> news:i5ok6m$1vi$1@news.eternal-september.org...
>> Thanks Tim,
>>
>> I've not looked at that part of the device manager before.
>>
>> There are 16 'Interrupt Request' devices listed, and eight of them use
>> the same number: 9.
>>
>> How do I work out which one or ones are hogging the CPU? And, if I
>> understand you right, which part of the system is trying to use that
>> interrupt device and causing it to hog the CPU.
>>
>> Presumably as I don't have much RAM, the hard drive will get a lot of
>> activity, but this is fairly new and much quicker than the old one so far
>> (Though I don't know why I have two IDE channels and only one hard
>> drive?)
>>
>> Cheers,
>>
>> S
>>
>>
>>
>> "Tim Meddick" <timmeddick@o2.co.uk> wrote in message
>> news:ubA1N9jSLHA.5716@TK2MSFTNGP02.phx.gbl...
>>> "Interrupts" are used by programs to call hardware resources.
>>>
>>> For instance : the ps2 mouse is typically Interrupt 12 and the
>>> operating system (software in itself) and other programs will use
>>> interrupt 12 to access the mouse.
>>>
>>> All interrupts are allocated to a hardware resource.
>>>
>>> To see what interrupts are allocated to what hardware on your PC -
>>>
>>> type "devmgmt.msc" into the "Run"box on the Start Menu to start the
>>> Device Manager.
>>>
>>> Then in Device Manager, click on "View" from the top menus, and then
>>> select "Resources by type" on the drop-down menu.
>>>
>>> Then click on the + sign next to the item named "Interrupt Request
>>> (IRQ)" - like on a folder in explorer, to see the expanded list of
>>> hardware and there allocated interrupts.
>>>
>>> ==
>>>
>>> Cheers, Tim Meddick, Peckham, London.
>>>
>>>
>>>
>>>
>>> "Spamlet" <spam.morespam@invalid.invalid> wrote in message
>>> news:i5ms93$lmo$1@news.eternal-september.org...
>>>> Not seen much about interrupts, and not even entirely sue what they
>>>> are. But I've noticed - coincidentally or not - that since I did the
>>>> delete of MS Update software to get back to using the less processor
>>>> hogging Windows Update, I keep seeing interrupts flare up to a large
>>>> percentage of the cpu. This is on an old Inspiron 2600 laptop with only
>>>> 260 meg of memory at the moment. It was recently updated to an 80gig
>>>> WD hard drive, which seems to be running well, and this is with XPHome
>>>> SP3 all up to date.
>>>>
>>>> There seems to be no way of seeing what these interrupts are for, as
>>>> they change too quickly to open a properties window for them in Process
>>>> Explorer. How much of the cpu should they take up? Might they have
>>>> been an underlying problem that was interfering with MS Update?
>>>>
>>>> Cheers,
>>>>
>>>> S
>>>>
>>>
>>
>>
>

 

[Tim Meddick]

I see that you are focussing on interrupts as a cause of resource hogging -
this is not the case.

Interrupts are just "hooks" that software uses to access hardware. Of
course, when it does, the PC and CPU are limited by the speed of the
attached device.

But it's very rare, or never, that software stops when a device paused or
stops responding.

No, it just keeps on processing data and, when it's tried enough times,
will simply give up on hardware Interrupts requests.

It's usually more likely the case that it's when an application has been
asked to do something right at the limits of what is reasonable to expect
of it, that problems, including apparent "resource hogging" occur.

The simplest and best way to see which process is taking up what percentage
of system resources, is to use the Task Manager.

==

Cheers, Tim Meddick, Peckham, London.




"Paul" <nospam@needed.com> wrote in message
news:i5oq5b$osd$1@speranza.aioe.org...
> Spamlet wrote:
>> Thanks Tim,
>>
>> I've not looked at that part of the device manager before.
>>
>> There are 16 'Interrupt Request' devices listed, and eight of them use
>> the same number: 9.
>>
>> How do I work out which one or ones are hogging the CPU? And, if I
>> understand you right, which part of the system is trying to use that
>> interrupt device and causing it to hog the CPU.
>>
>> Presumably as I don't have much RAM, the hard drive will get a lot of
>> activity, but this is fairly new and much quicker than the old one so
>> far (Though I don't know why I have two IDE channels and only one hard
>> drive?)
>>
>> Cheers,
>>
>> S
>
> If you see 16 entries, your machine is handling interrupts using PIC
> (programmable interrupt controller). The other option, is APIC (which
> may be a BIOS option). APIC has a couple features, such as being able
> to forward interrupts to a particular processor on a multiprocessor
> (or multicore) machine. APIC interrupt numbers also go a bit higher,
> and the PCI bus INTA/B/C/D signals may be listed in 16..23 . APIC
> can even be used on a single core computer, but in that case, there
> is no need to steer the interrupts because they all go to the same
> place.
>
> http://en.wikipedia.org/wiki/Intel_APIC_Architecture
>
> This is my Device Manager summary report in the interrupt section.
> I'm running APIC. You can see there is still sharing going on.
> On IRQ 18, my WinTV card (on PCI bus), the network interface (on PCI
> Express
> bus), and the chipset, are all sharing the same IRQ. Interrupt
> handlers have to be able to deal with this sharing.
>
> ******************** IRQ SUMMARY ********************
> IRQ Usage Summary:
> (ISA) 0 System timer
> (ISA) 1 Standard 101/102-Key or Microsoft Natural PS/2 Keyboard
> (ISA) 6 Standard floppy disk controller
> (ISA) 8 System CMOS/real time clock
> (ISA) 9 Microsoft ACPI-Compliant System
> (ISA) 13 Numeric data processor
> (PCI) 15 Hauppauge WinTV 878/9 WDM Aux Driver
> (PCI) 15 Intel(R) ICH9 Family SMBus Controller - 2930
> (PCI) 16 Intel(R) X38/X48 Express Chipset PCI Express Root Port - 29E9
> (PCI) 16 NVIDIA GeForce 7900 GT/GTO
> (PCI) 16 Intel(R) ICH9 Family USB Universal Host Controller - 2937
> (PCI) 16 Standard Dual Channel PCI IDE Controller
> (PCI) 17 Intel(R) ICH9 Family PCI Express Root Port 1 - 2940
> (PCI) 17 Intel(R) ICH9 Family PCI Express Root Port 5 - 2948
> (PCI) 18 Intel(R) ICH9 Family USB Universal Host Controller - 2939
> (PCI) 18 Intel(R) ICH9 Family USB2 Enhanced Host Controller - 293C
> (PCI) 18 Intel(R) ICH9 Family PCI Express Root Port 3 - 2944
> <---
> (PCI) 18 Marvell Yukon 88E8056 PCI-E Gigabit Ethernet Controller
> <---
> (PCI) 18 Intel(R) ICH9 Family USB Universal Host Controller - 2936
> (PCI) 18 Hauppauge WinTV 878/9 WDM Video Driver
> <---
> (PCI) 19 Intel(R) ICH9 Family USB Universal Host Controller - 2935
> (PCI) 19 VIA OHCI Compliant IEEE 1394 Host Controller
> (PCI) 21 Intel(R) ICH9 Family USB Universal Host Controller - 2938
> (PCI) 22 Microsoft UAA Bus Driver for High Definition Audio
> (PCI) 22 Intel(R) ICH9R/DO/DH 4 port Serial ATA Storage Controller 1 -
> 29
> (PCI) 22 Intel(R) ICH9 Family 2 port Serial ATA Storage Controller 2 -
> 29
> (PCI) 23 Intel(R) ICH9 Family USB Universal Host Controller - 2934
> (PCI) 23 Intel(R) ICH9 Family USB2 Enhanced Host Controller - 293A
>
> I don't know of a tool for logging specific interrupt counts in Windows.
> In Linux,
> you can use /proc/interrupts to get the info. I still haven't figured
> out how to do the equivalent of this in Windows.
>
> http://www.linuxtopia.org/online_bo...istration_guide/centos5_s1-proc-topfiles.html
>
> "3.2.11. /proc/interrupts
>
> For a multi-processor machine, this file may look slightly different:
>
> CPU0 CPU1
> 0: 1366814704 0 XT-PIC timer
> 1: 128 340 IO-APIC-edge keyboard
> 2: 0 0 XT-PIC cascade
> 8: 0 1 IO-APIC-edge rtc
> 12: 5323 5793 IO-APIC-edge PS/2 Mouse
> 13: 1 0 XT-PIC fpu
> 16: 11184294 15940594 IO-APIC-level Intel EtherExpress Pro
> 10/100 Ethernet
> 20: 8450043 11120093 IO-APIC-level megaraid
> 30: 10432 10722 IO-APIC-level aic7xxx
> 31: 23 22 IO-APIC-level aic7xxx
> NMI: 0
> ERR: 0 "
>
> In that example, APIC is able to steer interrupts to a particular CPU.
> CPU0 is getting all the timer interrupts. A high count there would
> not be a cause for concern, because the timer is being used by
> the OS a lot.
>
> I had great hopes for an article with this title, but in fact
> the facilities available look pretty poor. "Disabling hardware"
> is a pathetic way to debug things, especially in a case where
> the hardware cannot be physically removed, to be sure it is
> not affecting system state.
>
> "Debugging an Interrupt Storm"
> http://msdn.microsoft.com/en-us/library/ff540586(VS.85).aspx
>
> According to this, when things share an IRQ, an ISR (interrupt
> service routine) chain is used to sequentially attempt to service
> the interrupt. Different ISRs are tried until the interrupt is cleared.
> To get some idea what hardware is interrupting, you'd need
> the ISR routine to count how many times it successfully
> handled an interrupt. An ISR may queue up a DPC, to finish
> handling the interrupt - a DPC runs at user level, rather
> than interrupt level, and that allows the ISR to be fast
> and lightweight. Process Explorer can show you the level of
> DPC activity, which might be proof that real interrupt
> events are happening (since they finish the servicing
> needed by the hardware). If there was something wrong
> with interrupts, perhaps you'd see a mismatch between
> the time spent handling interrupts, and the amount of
> DPC activity.
>
> http://www.microsoft.com/whdc/archive/apic.mspx
>
> "4. The operating system calls the first ISR in the chain.
> 5. The ISR probes the hardware and attempts to handle the interrupt.
> 6. If there are additional ISRs, the operating system goes on to
> the next one and returns to step 5."
>
> HTH,
> Paul
>
>>
>>
>>
>> "Tim Meddick" <timmeddick@o2.co.uk> wrote in message
>> news:ubA1N9jSLHA.5716@TK2MSFTNGP02.phx.gbl...
>>> "Interrupts" are used by programs to call hardware resources.
>>>
>>> For instance : the ps2 mouse is typically Interrupt 12 and the
>>> operating system (software in itself) and other programs will use
>>> interrupt 12 to access the mouse.
>>>
>>> All interrupts are allocated to a hardware resource.
>>>
>>> To see what interrupts are allocated to what hardware on your PC -
>>>
>>> type "devmgmt.msc" into the "Run"box on the Start Menu to start the
>>> Device Manager.
>>>
>>> Then in Device Manager, click on "View" from the top menus, and then
>>> select "Resources by type" on the drop-down menu.
>>>
>>> Then click on the + sign next to the item named "Interrupt Request
>>> (IRQ)" - like on a folder in explorer, to see the expanded list of
>>> hardware and there allocated interrupts.
>>>
>>> ==
>>>
>>> Cheers, Tim Meddick, Peckham, London.
>>>
>>>
>>>
>>>
>>> "Spamlet" <spam.morespam@invalid.invalid> wrote in message
>>> news:i5ms93$lmo$1@news.eternal-september.org...
>>>> Not seen much about interrupts, and not even entirely sue what they
>>>> are. But I've noticed - coincidentally or not - that since I did the
>>>> delete of MS Update software to get back to using the less processor
>>>> hogging Windows Update, I keep seeing interrupts flare up to a large
>>>> percentage of the cpu. This is on an old Inspiron 2600 laptop with
>>>> only 260 meg of memory at the moment. It was recently updated to an
>>>> 80gig WD hard drive, which seems to be running well, and this is with
>>>> XPHome SP3 all up to date.
>>>>
>>>> There seems to be no way of seeing what these interrupts are for, as
>>>> they change too quickly to open a properties window for them in
>>>> Process Explorer. How much of the cpu should they take up? Might they
>>>> have been an underlying problem that was interfering with MS Update?
>>>>
>>>> Cheers,
>>>>
>>>> S
>>>>
>>

 

[Tim Meddick]

I agree, PE is brilliant and you could ask no more of it.

But I quote Task Manager because everyone has it, and it conveys the
message of analysing resource usage by processes.

==

Cheers, Tim Meddick, Peckham, London.




"Spamlet" <spam.morespam@invalid.invalid> wrote in message
news:i5osqq$beg$1@news.eternal-september.org...
> Thanks Tim,
>
> I'm already using Process Explorer: which is how I could see the
> interrupts taking up cpu in the handy little graphs that are displayed in
> the notification area once you replace Task Manager with Process Explorer
> as I recommend you do, as TM is pretty crude once you have tried PE. In
> this case the interrupts are taking up cpu not ram, and they are too
> transient to get any info from other than they can sometimes take as much
> as 80% of the cpu.
>
> I discovered this, like you, after I began looking into windows update
> taking all my ram, and, apparently, solved that problem, through a
> comment made by PA Bear. He had asked me to look at how my laptop was
> accessing the update site. Interestingly, it appeared that I was using
> windows update as it was going via a link that had something like
> 'msupdate/windowsudate' in it, but paging down on that site I still
> found the tick box to uninstall ms update components from my computer. I
> was surprised to see this, but ticked it and tried again, and the next
> time I accessed the link there was no tick box at the bottom of the page.
> Since then the laptop has not hung on updates taking up ram (I haven't
> actually noticed any updates at all mind...), but I have noticed these
> interrupts taking up cpu which I had not noticed before. I did wonder if
> they might represent something still looking for that old update process.
> (Incidentally I've also deleted all the google updating files from my
> computer, as I suspected they might be getting in the way too, and had an
> irritating habit of turning themselves back on no matter how many times I
> 'disabled' them)
>
> Cheers,
>
> S
>
>
>
>
> "Tim Meddick" <timmeddick@o2.co.uk> wrote in message
> news:%23CoZ7UsSLHA.456@TK2MSFTNGP06.phx.gbl...
>> To answer you last question, first.
>>
>> The reason you have two IEDE channels is that each channel can take two
>> IDE drives each. So, with two channels, that's space for 4 drives.
>>
>> Usually drives are arranged thus :
>>
>> Primary IDE Channel [position 1] = Master:- Hard Drive [C
>> [position 2] = Slave:- Hard Drive [D
>>
>> Secondary IDE Channel [position 1] = Master:- CD/DVD Drive [E
>> [position 2] = Slave:- Hard Drive
>> [D
>>
>> ....a cd/dvd drive (when present in a new machine) occupying the 1st
>> position on the Secondary IDE channel. If a purchaser of a new PC buys
>> an additional Hard drive for extra media content or space for backups,
>> it would normally be connected to position 2 of the Primary IDE channel,
>> making it slave to the system or [c drive. While position 2 of the
>> Secondary IDE channel, would be for a second cd/dvd or maybe a cd/dvd
>> re-writer. The whole idea behind the PC, is that there is lots of
>> room, built-in, to accommodate additions, expansions and upgrades....
>>
>> As I may have said in a previous post (or many of them), the way to see
>> what application or "running process" is "hogging" system resources -
>> and by resources I really mean RAM - is to open the Window's Task
>> Manager.
>>
>> Click on an empty area of the taskbar and right-click on it.
>>
>> Choose "Task Manager" from the pop-up menu.
>>
>> Click on the column heading "Memory Usage" to make the process-list get
>> in order, similar to doing the same with files in Explorer. You may
>> need to click on the heading twice to get them in order - largest mem
>> usage at the top down to lowest at the bottom.
>>
>> The task or process-list, refreshes itself once every five seconds by
>> default (but you can change that) so by arranging the columns in order
>> of size of memory usage - then the application or service[es] that
>> are taking up most RAM are always going to be at the top of the list.
>>
>> This is how I found out that Window's Update takes up so much RAM when
>> it's running, that I can do nothing else on the PC till it's finished
>> (seeing how I need it, I have to let it run). So, when I feel the
>> system starting to run a bit slow, I open up Task Manager and if I see
>> the process "wuauclt.exe" listed, I can go and get a cup of tea and have
>> a sit down until then.
>>
>>
>>
>> One is obviously going to be for the system [c drive, and an other
>>
>> ==
>>
>> Cheers, Tim Meddick, Peckham, London.
>>
>>
>>
>>
>> "Spamlet" <spam.morespam@invalid.invalid> wrote in message
>> news:i5ok6m$1vi$1@news.eternal-september.org...
>>> Thanks Tim,
>>>
>>> I've not looked at that part of the device manager before.
>>>
>>> There are 16 'Interrupt Request' devices listed, and eight of them use
>>> the same number: 9.
>>>
>>> How do I work out which one or ones are hogging the CPU? And, if I
>>> understand you right, which part of the system is trying to use that
>>> interrupt device and causing it to hog the CPU.
>>>
>>> Presumably as I don't have much RAM, the hard drive will get a lot of
>>> activity, but this is fairly new and much quicker than the old one so
>>> far (Though I don't know why I have two IDE channels and only one hard
>>> drive?)
>>>
>>> Cheers,
>>>
>>> S
>>>
>>>
>>>
>>> "Tim Meddick" <timmeddick@o2.co.uk> wrote in message
>>> news:ubA1N9jSLHA.5716@TK2MSFTNGP02.phx.gbl...
>>>> "Interrupts" are used by programs to call hardware resources.
>>>>
>>>> For instance : the ps2 mouse is typically Interrupt 12 and the
>>>> operating system (software in itself) and other programs will use
>>>> interrupt 12 to access the mouse.
>>>>
>>>> All interrupts are allocated to a hardware resource.
>>>>
>>>> To see what interrupts are allocated to what hardware on your PC -
>>>>
>>>> type "devmgmt.msc" into the "Run"box on the Start Menu to start the
>>>> Device Manager.
>>>>
>>>> Then in Device Manager, click on "View" from the top menus, and then
>>>> select "Resources by type" on the drop-down menu.
>>>>
>>>> Then click on the + sign next to the item named "Interrupt Request
>>>> (IRQ)" - like on a folder in explorer, to see the expanded list of
>>>> hardware and there allocated interrupts.
>>>>
>>>> ==
>>>>
>>>> Cheers, Tim Meddick, Peckham, London.
>>>>
>>>>
>>>>
>>>>
>>>> "Spamlet" <spam.morespam@invalid.invalid> wrote in message
>>>> news:i5ms93$lmo$1@news.eternal-september.org...
>>>>> Not seen much about interrupts, and not even entirely sue what they
>>>>> are. But I've noticed - coincidentally or not - that since I did the
>>>>> delete of MS Update software to get back to using the less processor
>>>>> hogging Windows Update, I keep seeing interrupts flare up to a large
>>>>> percentage of the cpu. This is on an old Inspiron 2600 laptop with
>>>>> only 260 meg of memory at the moment. It was recently updated to an
>>>>> 80gig WD hard drive, which seems to be running well, and this is with
>>>>> XPHome SP3 all up to date.
>>>>>
>>>>> There seems to be no way of seeing what these interrupts are for, as
>>>>> they change too quickly to open a properties window for them in
>>>>> Process Explorer. How much of the cpu should they take up? Might
>>>>> they have been an underlying problem that was interfering with MS
>>>>> Update?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> S
>>>>>
>>>>
>>>
>>>
>>
>
>

 

[Spamlet]

"Paul" <nospam@needed.com> wrote in message
news:i5oq5b$osd$1@speranza.aioe.org...
> Spamlet wrote:
>> Thanks Tim,
>>
>> I've not looked at that part of the device manager before.
>>
>> There are 16 'Interrupt Request' devices listed, and eight of them use
>> the same number: 9.
>>
>> How do I work out which one or ones are hogging the CPU? And, if I
>> understand you right, which part of the system is trying to use that
>> interrupt device and causing it to hog the CPU.
>>
>> Presumably as I don't have much RAM, the hard drive will get a lot of
>> activity, but this is fairly new and much quicker than the old one so far
>> (Though I don't know why I have two IDE channels and only one hard
>> drive?)
>>
>> Cheers,
>>
>> S
>
> If you see 16 entries, your machine is handling interrupts using PIC
> (programmable interrupt controller). The other option, is APIC (which
> may be a BIOS option). APIC has a couple features, such as being able
> to forward interrupts to a particular processor on a multiprocessor
> (or multicore) machine. APIC interrupt numbers also go a bit higher,
> and the PCI bus INTA/B/C/D signals may be listed in 16..23 . APIC
> can even be used on a single core computer, but in that case, there
> is no need to steer the interrupts because they all go to the same
> place.
>
> http://en.wikipedia.org/wiki/Intel_APIC_Architecture
>
> This is my Device Manager summary report in the interrupt section.
> I'm running APIC. You can see there is still sharing going on.
> On IRQ 18, my WinTV card (on PCI bus), the network interface (on PCI
> Express
> bus), and the chipset, are all sharing the same IRQ. Interrupt
> handlers have to be able to deal with this sharing.
>
> ******************** IRQ SUMMARY ********************
> IRQ Usage Summary:
> (ISA) 0 System timer
> (ISA) 1 Standard 101/102-Key or Microsoft Natural PS/2 Keyboard
> (ISA) 6 Standard floppy disk controller
> (ISA) 8 System CMOS/real time clock
> (ISA) 9 Microsoft ACPI-Compliant System
> (ISA) 13 Numeric data processor
> (PCI) 15 Hauppauge WinTV 878/9 WDM Aux Driver
> (PCI) 15 Intel(R) ICH9 Family SMBus Controller - 2930
> (PCI) 16 Intel(R) X38/X48 Express Chipset PCI Express Root Port - 29E9
> (PCI) 16 NVIDIA GeForce 7900 GT/GTO
> (PCI) 16 Intel(R) ICH9 Family USB Universal Host Controller - 2937
> (PCI) 16 Standard Dual Channel PCI IDE Controller
> (PCI) 17 Intel(R) ICH9 Family PCI Express Root Port 1 - 2940
> (PCI) 17 Intel(R) ICH9 Family PCI Express Root Port 5 - 2948
> (PCI) 18 Intel(R) ICH9 Family USB Universal Host Controller - 2939
> (PCI) 18 Intel(R) ICH9 Family USB2 Enhanced Host Controller - 293C
> (PCI) 18 Intel(R) ICH9 Family PCI Express Root Port 3 - 2944
> <---
> (PCI) 18 Marvell Yukon 88E8056 PCI-E Gigabit Ethernet Controller
> <---
> (PCI) 18 Intel(R) ICH9 Family USB Universal Host Controller - 2936
> (PCI) 18 Hauppauge WinTV 878/9 WDM Video Driver
> <---
> (PCI) 19 Intel(R) ICH9 Family USB Universal Host Controller - 2935
> (PCI) 19 VIA OHCI Compliant IEEE 1394 Host Controller
> (PCI) 21 Intel(R) ICH9 Family USB Universal Host Controller - 2938
> (PCI) 22 Microsoft UAA Bus Driver for High Definition Audio
> (PCI) 22 Intel(R) ICH9R/DO/DH 4 port Serial ATA Storage Controller 1 -
> 29
> (PCI) 22 Intel(R) ICH9 Family 2 port Serial ATA Storage Controller 2 -
> 29
> (PCI) 23 Intel(R) ICH9 Family USB Universal Host Controller - 2934
> (PCI) 23 Intel(R) ICH9 Family USB2 Enhanced Host Controller - 293A
>
> I don't know of a tool for logging specific interrupt counts in Windows.
> In Linux,
> you can use /proc/interrupts to get the info. I still haven't figured
> out how to do the equivalent of this in Windows.
>
> http://www.linuxtopia.org/online_bo...istration_guide/centos5_s1-proc-topfiles.html
>
> "3.2.11. /proc/interrupts
>
> For a multi-processor machine, this file may look slightly different:
>
> CPU0 CPU1
> 0: 1366814704 0 XT-PIC timer
> 1: 128 340 IO-APIC-edge keyboard
> 2: 0 0 XT-PIC cascade
> 8: 0 1 IO-APIC-edge rtc
> 12: 5323 5793 IO-APIC-edge PS/2 Mouse
> 13: 1 0 XT-PIC fpu
> 16: 11184294 15940594 IO-APIC-level Intel EtherExpress Pro
> 10/100 Ethernet
> 20: 8450043 11120093 IO-APIC-level megaraid
> 30: 10432 10722 IO-APIC-level aic7xxx
> 31: 23 22 IO-APIC-level aic7xxx
> NMI: 0
> ERR: 0 "
>
> In that example, APIC is able to steer interrupts to a particular CPU.
> CPU0 is getting all the timer interrupts. A high count there would
> not be a cause for concern, because the timer is being used by
> the OS a lot.
>
> I had great hopes for an article with this title, but in fact
> the facilities available look pretty poor. "Disabling hardware"
> is a pathetic way to debug things, especially in a case where
> the hardware cannot be physically removed, to be sure it is
> not affecting system state.
>
> "Debugging an Interrupt Storm"
> http://msdn.microsoft.com/en-us/library/ff540586(VS.85).aspx
>
> According to this, when things share an IRQ, an ISR (interrupt
> service routine) chain is used to sequentially attempt to service
> the interrupt. Different ISRs are tried until the interrupt is cleared.
> To get some idea what hardware is interrupting, you'd need
> the ISR routine to count how many times it successfully
> handled an interrupt. An ISR may queue up a DPC, to finish
> handling the interrupt - a DPC runs at user level, rather
> than interrupt level, and that allows the ISR to be fast
> and lightweight. Process Explorer can show you the level of
> DPC activity, which might be proof that real interrupt
> events are happening (since they finish the servicing
> needed by the hardware). If there was something wrong
> with interrupts, perhaps you'd see a mismatch between
> the time spent handling interrupts, and the amount of
> DPC activity.
>
> http://www.microsoft.com/whdc/archive/apic.mspx
>
> "4. The operating system calls the first ISR in the chain.
> 5. The ISR probes the hardware and attempts to handle the interrupt.
> 6. If there are additional ISRs, the operating system goes on to
> the next one and returns to step 5."
>
> HTH,
> Paul

Thanks Paul, that is more interesting background for me - if a little over
my head in places.
I'll have a look at the bios next time I restart, though I doubt if this old
laptop will give many options.

Cheers,

S

>
>>
>>
>>
>> "Tim Meddick" <timmeddick@o2.co.uk> wrote in message
>> news:ubA1N9jSLHA.5716@TK2MSFTNGP02.phx.gbl...
>>> "Interrupts" are used by programs to call hardware resources.
>>>
>>> For instance : the ps2 mouse is typically Interrupt 12 and the
>>> operating system (software in itself) and other programs will use
>>> interrupt 12 to access the mouse.
>>>
>>> All interrupts are allocated to a hardware resource.
>>>
>>> To see what interrupts are allocated to what hardware on your PC -
>>>
>>> type "devmgmt.msc" into the "Run"box on the Start Menu to start the
>>> Device Manager.
>>>
>>> Then in Device Manager, click on "View" from the top menus, and then
>>> select "Resources by type" on the drop-down menu.
>>>
>>> Then click on the + sign next to the item named "Interrupt Request
>>> (IRQ)" - like on a folder in explorer, to see the expanded list of
>>> hardware and there allocated interrupts.
>>>
>>> ==
>>>
>>> Cheers, Tim Meddick, Peckham, London.
>>>
>>>
>>>
>>>
>>> "Spamlet" <spam.morespam@invalid.invalid> wrote in message
>>> news:i5ms93$lmo$1@news.eternal-september.org...
>>>> Not seen much about interrupts, and not even entirely sue what they
>>>> are. But I've noticed - coincidentally or not - that since I did the
>>>> delete of MS Update software to get back to using the less processor
>>>> hogging Windows Update, I keep seeing interrupts flare up to a large
>>>> percentage of the cpu. This is on an old Inspiron 2600 laptop with only
>>>> 260 meg of memory at the moment. It was recently updated to an 80gig
>>>> WD hard drive, which seems to be running well, and this is with XPHome
>>>> SP3 all up to date.
>>>>
>>>> There seems to be no way of seeing what these interrupts are for, as
>>>> they change too quickly to open a properties window for them in Process
>>>> Explorer. How much of the cpu should they take up? Might they have
>>>> been an underlying problem that was interfering with MS Update?
>>>>
>>>> Cheers,
>>>>
>>>> S
>>>>
>>

 

[Paul]

Tim Meddick wrote:
> I see that you are focussing on interrupts as a cause of resource
> hogging - this is not the case.
>
> Interrupts are just "hooks" that software uses to access hardware. Of
> course, when it does, the PC and CPU are limited by the speed of the
> attached device.
>
> But it's very rare, or never, that software stops when a device paused
> or stops responding.
>
> No, it just keeps on processing data and, when it's tried enough times,
> will simply give up on hardware Interrupts requests.
>
> It's usually more likely the case that it's when an application has been
> asked to do something right at the limits of what is reasonable to
> expect of it, that problems, including apparent "resource hogging" occur.
>
> The simplest and best way to see which process is taking up what
> percentage of system resources, is to use the Task Manager.
>
> ==
>
> Cheers, Tim Meddick, Peckham, London.
>

Of course it can be the case. At least in the case of hardware interrupts,
the hardware asserts a hardware signal. (On a PCI card, it might be the
INTA# signal dropping to logic zero, to indicate the card needs service.)

The motherboard has some kind of logic, to collect up all the interrupt
reasons, prioritize them, and deliver them to the processor. There is the
ability to "mask" to a certain interrupt level, for orderly servicing.
(If you lift the mask all the way up, then no regular interrupts get
to the processor - such a system could only continue to function, if
there was a provision for running "polled" instead of in "interrupt"
mode. Polling is less efficient and would result in a slower system.)

If a piece of hardware keeps asserting its interrupt signal, on a badly
designed computer, such an activity could completely block a response
at the user level. The keyboard wouldn't work, the cursor might not
move when you move the mouse. And that would be, because there are no longer
any cycles available to run activities at a user level. All the cycles
are spent "taking interrupts".

There are other extremes as well, but this would have been more common
twenty years ago. At one time, the operation of a hardware subsystem
might stop, if even one interrupt was "lost". Say, for example, the
design team misses a detail, and somehow an interrupt is cleared
before it triggers the service routine. (We used to call those
spurious interrupts, because the spurious interrupt handler would get
called and something would be printed on the console screen as a result.)
If it happened on a network interface card, the result might be no working
TCP/IP service all of a sudden. Modern systems have a lot more recovery
features, both for too many interrupts and too few interrupts, for
this kind of thing to be visible now.

There are other ways to affect the real time behavior of a system,
such as make a computer useless for building an audio workstation.
This is an example of a mechanism - the OS is actually defenseless
to this hardware feature and can't do anything about it. This feature
has also been proposed as a means of hacking systems.

http://en.wikipedia.org/wiki/System_Management_Mode

and this is how you (indirectly) come to the conclusion that might
be causing a problem. Within the last few years, there were some
motherboards that needed a BIOS update, to stop doing that. This
program was valuable for detecting that the motherboard BIOS
needed work (i.e. shorten the interval of whatever was running
as an SMM).

http://www.thesycon.de/deu/latency_check.shtml

The red bars here are bad, and indicate the computer may have problems
handling latency sensitive things like audio. If the delays noted
here were long enough, you might lose clock tick interrupts, causing
the Windows clock to lose time.

http://www.thesycon.de/dpclat/dpclat2.jpg

Interrupts are more than hooks. They *can* drop a system to its
knees, depending on the OS, and depending on the interrupt level.
For example, what happens if you ground the NMI# signal ?
By the very nature of the name of this signal, the system
is defenseless to this as well.

http://en.wikipedia.org/wiki/Non_maskable_interrupt

This article has more info, and addresses things like software
interrupts.

http://en.wikipedia.org/wiki/Interrupt

"Software interrupt is an interrupt generated within a processor
by executing an instruction. Software interrupts are often used
to implement system calls because they implement a subroutine call
with a CPU ring level change."

http://en.wikipedia.org/wiki/Interrupt_storm

"In operating systems, an interrupt storm is an event during which a
processor receives an inordinate number of interrupts that consume
the majority of the processor's time. Interrupt storms are typically
caused by hardware devices that do not support interrupt rate limiting."

Paul

 

[Tim Meddick]

An interrupt is simply an assigned "handle" - a "hook", if you will, that's
all it is.

Software uses these "handles" or "hooks" to call hardware resources.

If there is a problem, it is in the software process or a piece of
hardware - it cannot be in an interrupt request!

==

Cheers, Tim Meddick, Peckham, London.




"Paul" <nospam@needed.com> wrote in message
news:i5p10e$4c7$1@speranza.aioe.org...
> Tim Meddick wrote:
>> I see that you are focussing on interrupts as a cause of resource
>> hogging - this is not the case.
>>
>> Interrupts are just "hooks" that software uses to access hardware. Of
>> course, when it does, the PC and CPU are limited by the speed of the
>> attached device.
>>
>> But it's very rare, or never, that software stops when a device paused
>> or stops responding.
>>
>> No, it just keeps on processing data and, when it's tried enough times,
>> will simply give up on hardware Interrupts requests.
>>
>> It's usually more likely the case that it's when an application has been
>> asked to do something right at the limits of what is reasonable to
>> expect of it, that problems, including apparent "resource hogging"
>> occur.
>>
>> The simplest and best way to see which process is taking up what
>> percentage of system resources, is to use the Task Manager.
>>
>> ==
>>
>> Cheers, Tim Meddick, Peckham, London.
>>
>
> Of course it can be the case. At least in the case of hardware
> interrupts,
> the hardware asserts a hardware signal. (On a PCI card, it might be the
> INTA# signal dropping to logic zero, to indicate the card needs service.)
>
> The motherboard has some kind of logic, to collect up all the interrupt
> reasons, prioritize them, and deliver them to the processor. There is the
> ability to "mask" to a certain interrupt level, for orderly servicing.
> (If you lift the mask all the way up, then no regular interrupts get
> to the processor - such a system could only continue to function, if
> there was a provision for running "polled" instead of in "interrupt"
> mode. Polling is less efficient and would result in a slower system.)
>
> If a piece of hardware keeps asserting its interrupt signal, on a badly
> designed computer, such an activity could completely block a response
> at the user level. The keyboard wouldn't work, the cursor might not
> move when you move the mouse. And that would be, because there are no
> longer
> any cycles available to run activities at a user level. All the cycles
> are spent "taking interrupts".
>
> There are other extremes as well, but this would have been more common
> twenty years ago. At one time, the operation of a hardware subsystem
> might stop, if even one interrupt was "lost". Say, for example, the
> design team misses a detail, and somehow an interrupt is cleared
> before it triggers the service routine. (We used to call those
> spurious interrupts, because the spurious interrupt handler would get
> called and something would be printed on the console screen as a result.)
> If it happened on a network interface card, the result might be no
> working
> TCP/IP service all of a sudden. Modern systems have a lot more recovery
> features, both for too many interrupts and too few interrupts, for
> this kind of thing to be visible now.
>
> There are other ways to affect the real time behavior of a system,
> such as make a computer useless for building an audio workstation.
> This is an example of a mechanism - the OS is actually defenseless
> to this hardware feature and can't do anything about it. This feature
> has also been proposed as a means of hacking systems.
>
> http://en.wikipedia.org/wiki/System_Management_Mode
>
> and this is how you (indirectly) come to the conclusion that might
> be causing a problem. Within the last few years, there were some
> motherboards that needed a BIOS update, to stop doing that. This
> program was valuable for detecting that the motherboard BIOS
> needed work (i.e. shorten the interval of whatever was running
> as an SMM).
>
> http://www.thesycon.de/deu/latency_check.shtml
>
> The red bars here are bad, and indicate the computer may have problems
> handling latency sensitive things like audio. If the delays noted
> here were long enough, you might lose clock tick interrupts, causing
> the Windows clock to lose time.
>
> http://www.thesycon.de/dpclat/dpclat2.jpg
>
> Interrupts are more than hooks. They *can* drop a system to its
> knees, depending on the OS, and depending on the interrupt level.
> For example, what happens if you ground the NMI# signal ?
> By the very nature of the name of this signal, the system
> is defenseless to this as well.
>
> http://en.wikipedia.org/wiki/Non_maskable_interrupt
>
> This article has more info, and addresses things like software
> interrupts.
>
> http://en.wikipedia.org/wiki/Interrupt
>
> "Software interrupt is an interrupt generated within a processor
> by executing an instruction. Software interrupts are often used
> to implement system calls because they implement a subroutine call
> with a CPU ring level change."
>
> http://en.wikipedia.org/wiki/Interrupt_storm
>
> "In operating systems, an interrupt storm is an event during which a
> processor receives an inordinate number of interrupts that consume
> the majority of the processor's time. Interrupt storms are typically
> caused by hardware devices that do not support interrupt rate
> limiting."
>
> Paul

 

[Paul]

Tim Meddick wrote:
> An interrupt is simply an assigned "handle" - a "hook", if you will,
> that's all it is.
>
> Software uses these "handles" or "hooks" to call hardware resources.
>
> If there is a problem, it is in the software process or a piece of
> hardware - it cannot be in an interrupt request!
>
> ==
>
> Cheers, Tim Meddick, Peckham, London.

Nope.

The process starts with a hardware signal. As long as the particular interrupt
level is not masked, the processor stacks the current context (whatever is
running) and "takes an interrupt". That is a context switch, and means the
current process is no longer running. The interrupt handler is running.

A short time later, the interrupt handler has looked at hardware registers
in the chip, and concluded it needs to be serviced. Using whatever feature
the chip has for clearing the interrupt, the handler attempts to clear
the interrupt. The hardware interrupt signal rises to the de-asserted
state.

Interrupt signal ---------- -----------------------
|_______________|

Interrupt Handler
Handler Clears
Triggered Interrupt
(Context switch)

Context user_level -------- ------------------
interrupt_level | |
----------------------
(return from
interrupt
handler)

DPC ------------------------------------------------| |----

Queued DPC
finishes interrupt
cleanup at user level

Some time after the interrupt is cleared, the interrupt handler returns
control to the next thing on the stack, which was that user process that
was running.

Since the interrupt handler, also queued a DPC to be run later, once the
DPC queue has been drained, eventually that DPC will get serviced. It
runs at a lower priority (same priority as other user processes), and
is allowed to spend more time dealing with the hardware. The
interrupt handler itself is not allowed to spend a lot of time
handling an interrupt, because of the effect this has on
real time performance. The execution of the DPC, is allowed to be
interrupted at any time, just like a user process can be interrupted.

In summary:

1) It's not a "hook".

2) It's practically a mechanical process. Interrupt signal drops (asserted state).
Processor drops what it is doing, and the interrupt handler runs as
soon as the execution pipeline can be drained enough to allow it
(nanoseconds). Processors have out-of-order execution, and the
execution pipeline has to be clean enough, for the interrupt handler
to start running. But the time to do that is pretty short.

3) The interrupt handler only does enough work, so that the interrupt
can be cleared. The queuing of a DPC, allows the OS to be effectively
notified that an event has happened on the device (like a packet
arrived on the Ethernet chip and has been automatically moved into
system memory via DMA, into one of the memory areas defined by the
ring buffer), and that further processing is required.

4) By returning very quickly, the interrupt handler allows other devices
with a similar priority, to have their interrupts handled.

5) The queuing of a DPC, allows milliseconds to be spent later, cleaning
up ring buffers (adding new buffers to the ring) and the like, so there
is room for new packets to be received. Or for new commands to be
sent to the hardware.

The purpose of an interrupt, is so the processor doesn't have to keep
checking that a piece of hardware is "ready". The hardware delivers
a signal, which "wakes" up the processor to the good news. The processor
can be running your copy of Firefox, so all its effort goes into
rendering a web page. But when the hardware finishes some task you
gave it, the hardware interrupt signal causes the processor to immediately
pay attention to the good news (even if a picture is half-painted in
Firefox, the interrupt will still be "taken"). The interrupt is efficient,
because no processor cycles are wasted checking "are you ready yet".
The processor is alerted immediately by a hardware signal.

You can find other diagrams of this sort of thing, but it's pretty
hard for me to find a nice diagram I can write words around.

http://prex.sourceforge.net/doc/img/irq.gif

In the event of an "interrupt storm", there is a defect in this
process, where the processor is getting interrupted way more often
than it should. If a hardware defect allows the interrupt signal
to stay in the asserted state, on older computer designs, the
system would effectively be frozen (since user processes would
be starved of cycles). The terminology is common enough, to have
its own Wikipedia article.

http://en.wikipedia.org/wiki/Interrupt_storm

And a lack of interrupt rate limiting, is not the only reason for
storms. There is at least one common peripheral chip in computers,
where a small percentage of shipped parts had a timing problem,
and would create their own "storms". It resulted in some users
experiencing slowdowns or freezing, while other users of the same
brand of equipment, wouldn't see any problems. And this is the
reason "Spamlet", the original poster, is interested in what
is going on in Process Explorer.

Paul

 

[Yousuf Khan]

On 9/2/2010 4:03 PM, Spamlet wrote:
> Thanks Paul, that is more interesting background for me - if a little over
> my head in places.
> I'll have a look at the bios next time I restart, though I doubt if this old
> laptop will give many options.
>
> Cheers,
>
> S

Another interesting thing to note is that Windows XP doesn't use APIC
interrupts very well. In XP, at most it'll use upto 25 separate
interrupts for all of your hardware onboard. It'll usually even share
several pieces of hardware on the same interrupt number. This is fine if
you got for example two separate USB controllers, and they are on the
same interrupt, as they are doing the same thing. But when you start
sharing USB interrupts with video interrupts, and hard disk interrupts,
then you're going to have a lot of contention.

Windows 7 (and I gather Vista as well, but who cares?) can use tens of
thousands of different interrupt numbers using the same APIC hardware.
Almost no need to share any interrupts at all.

Yousuf Khan

 

[Paul]

Yousuf Khan wrote:
> On 9/2/2010 4:03 PM, Spamlet wrote:
>> Thanks Paul, that is more interesting background for me - if a little
>> over
>> my head in places.
>> I'll have a look at the bios next time I restart, though I doubt if
>> this old
>> laptop will give many options.
>>
>> Cheers,
>>
>> S
>
> Another interesting thing to note is that Windows XP doesn't use APIC
> interrupts very well. In XP, at most it'll use upto 25 separate
> interrupts for all of your hardware onboard. It'll usually even share
> several pieces of hardware on the same interrupt number. This is fine if
> you got for example two separate USB controllers, and they are on the
> same interrupt, as they are doing the same thing. But when you start
> sharing USB interrupts with video interrupts, and hard disk interrupts,
> then you're going to have a lot of contention.
>
> Windows 7 (and I gather Vista as well, but who cares?) can use tens of
> thousands of different interrupt numbers using the same APIC hardware.
> Almost no need to share any interrupts at all.
>
> Yousuf Khan

Perhaps something like this.

http://en.wikipedia.org/wiki/Message_Signaled_Interrupts

I wonder if any of the hardware in my computer supports that ?
And how would I know if it was being used ? Device manager
shows the same old boring 0..23 IRQs of Intel APIC.
(AMD did a version with 32, that never caught on.)
If there were MSIs on my system (with WinXP SP3),
where would they be documented ?

Paul

 

[Yousuf Khan]

On 9/4/2010 1:26 AM, Paul wrote:
> Perhaps something like this.
>
> http://en.wikipedia.org/wiki/Message_Signaled_Interrupts
>
> I wonder if any of the hardware in my computer supports that ?
> And how would I know if it was being used ? Device manager
> shows the same old boring 0..23 IRQs of Intel APIC.
> (AMD did a version with 32, that never caught on.)
> If there were MSIs on my system (with WinXP SP3),
> where would they be documented ?
>
> Paul

No, MSI is simply how PCI-express (which is a serial data interface)
gets the attention of the CPU, without having its own dedicated
interrupt pin. In the old days, of PCI and earlier, all hardware
produced its own interrupts through a special pin. With serial
interfaces they do not have a separate pin for that, so it sends a
special message to the PCI-express chipset asking it to assert an
interrupt for it on the CPU. However, this has nothing to do with how
many interrupt numbers you can have.

As for the AMD Open PIC system, it was a system for distributing
interrupts around to multiple processors, upto 32 of them in total.
Intel's multi-processor PIC system was called MPIC. AMD eventually
abandoned OpenPIC for MPIC. Again, it has nothing to do with how many
interrupt numbers you have, just how many processors can receive interrupts.

Yousuf Khan

 

[Tim Meddick]

Fine - you go ahead and blame your PIC for excessive resource hogging -
don't bother investigating which processes are actually involved in taking
up to much cpu time / memory!

==

Cheers, Tim Meddick, Peckham, London.




"Paul" <nospam@needed.com> wrote in message
news:i5rq6h$15c$1@speranza.aioe.org...
> Tim Meddick wrote:
>> An interrupt is simply an assigned "handle" - a "hook", if you will,
>> that's all it is.
>>
>> Software uses these "handles" or "hooks" to call hardware resources.
>>
>> If there is a problem, it is in the software process or a piece of
>> hardware - it cannot be in an interrupt request!
>>
>> ==
>>
>> Cheers, Tim Meddick, Peckham, London.
>
> Nope.
>
> The process starts with a hardware signal. As long as the particular
> interrupt
> level is not masked, the processor stacks the current context (whatever
> is
> running) and "takes an interrupt". That is a context switch, and means
> the
> current process is no longer running. The interrupt handler is running.
>
> A short time later, the interrupt handler has looked at hardware
> registers
> in the chip, and concluded it needs to be serviced. Using whatever
> feature
> the chip has for clearing the interrupt, the handler attempts to clear
> the interrupt. The hardware interrupt signal rises to the de-asserted
> state.
>
> Interrupt signal ---------- -----------------------
> |_______________|
>
> Interrupt Handler
> Handler Clears
> Triggered Interrupt
> (Context switch)
>
> Context user_level -------- ------------------
> interrupt_level | |
> ----------------------
> (return from
> interrupt
> handler)
>
> DPC ------------------------------------------------|
> |----
>
> Queued DPC
> finishes
> interrupt
> cleanup at
> user level
>
> Some time after the interrupt is cleared, the interrupt handler returns
> control to the next thing on the stack, which was that user process that
> was running.
>
> Since the interrupt handler, also queued a DPC to be run later, once the
> DPC queue has been drained, eventually that DPC will get serviced. It
> runs at a lower priority (same priority as other user processes), and
> is allowed to spend more time dealing with the hardware. The
> interrupt handler itself is not allowed to spend a lot of time
> handling an interrupt, because of the effect this has on
> real time performance. The execution of the DPC, is allowed to be
> interrupted at any time, just like a user process can be interrupted.
>
> In summary:
>
> 1) It's not a "hook".
>
> 2) It's practically a mechanical process. Interrupt signal drops
> (asserted state).
> Processor drops what it is doing, and the interrupt handler runs as
> soon as the execution pipeline can be drained enough to allow it
> (nanoseconds). Processors have out-of-order execution, and the
> execution pipeline has to be clean enough, for the interrupt handler
> to start running. But the time to do that is pretty short.
>
> 3) The interrupt handler only does enough work, so that the interrupt
> can be cleared. The queuing of a DPC, allows the OS to be effectively
> notified that an event has happened on the device (like a packet
> arrived on the Ethernet chip and has been automatically moved into
> system memory via DMA, into one of the memory areas defined by the
> ring buffer), and that further processing is required.
>
> 4) By returning very quickly, the interrupt handler allows other devices
> with a similar priority, to have their interrupts handled.
>
> 5) The queuing of a DPC, allows milliseconds to be spent later, cleaning
> up ring buffers (adding new buffers to the ring) and the like, so
> there
> is room for new packets to be received. Or for new commands to be
> sent to the hardware.
>
> The purpose of an interrupt, is so the processor doesn't have to keep
> checking that a piece of hardware is "ready". The hardware delivers
> a signal, which "wakes" up the processor to the good news. The processor
> can be running your copy of Firefox, so all its effort goes into
> rendering a web page. But when the hardware finishes some task you
> gave it, the hardware interrupt signal causes the processor to
> immediately
> pay attention to the good news (even if a picture is half-painted in
> Firefox, the interrupt will still be "taken"). The interrupt is
> efficient,
> because no processor cycles are wasted checking "are you ready yet".
> The processor is alerted immediately by a hardware signal.
>
> You can find other diagrams of this sort of thing, but it's pretty
> hard for me to find a nice diagram I can write words around.
>
> http://prex.sourceforge.net/doc/img/irq.gif
>
> In the event of an "interrupt storm", there is a defect in this
> process, where the processor is getting interrupted way more often
> than it should. If a hardware defect allows the interrupt signal
> to stay in the asserted state, on older computer designs, the
> system would effectively be frozen (since user processes would
> be starved of cycles). The terminology is common enough, to have
> its own Wikipedia article.
>
> http://en.wikipedia.org/wiki/Interrupt_storm
>
> And a lack of interrupt rate limiting, is not the only reason for
> storms. There is at least one common peripheral chip in computers,
> where a small percentage of shipped parts had a timing problem,
> and would create their own "storms". It resulted in some users
> experiencing slowdowns or freezing, while other users of the same
> brand of equipment, wouldn't see any problems. And this is the
> reason "Spamlet", the original poster, is interested in what
> is going on in Process Explorer.
>
> Paul