Downloading makes 7 really slow

Here's the laptops IRQs. I've read somewhere that IRQ sharing isn't that big of a deal anymore as it was in earlier operating systems.

My computer was working fine for about 5 months until out of no where, this problem showed up.

Does your sister's computer produces crackling noise too?
Anyway, download DPC latency checker over here, see if your sister's computer does have the same problem as yours too... (check with the tool).

zzz2496

Edit:

Processing of streaming data in real-time is a very challenging task for Windows based applications and device drivers. This is because by design Windows is not a real-time operating system. There is no guarantee that certain (periodic) actions can be executed in a timely manner.

Audio or video data streams transferred from or to an external device are typically handled by a kernel-mode device driver. Data processing in such device drivers is interrupt-driven. Typically, the external hardware periodically issues interrupts to request the driver to transfer the next block of data. In Windows NT based systems (Windows 2000 and better) there is a specific interrupt handling mechanism. A device driver cannot process data immediately in its interrupt routine. It has to schedule a Deferred Procedure Call (DPC) which basically is a callback routine that will be called by the operating system as soon as possible. Any data transfer performed by the device driver takes place in the context of this callback routine, named DPC for short.

The operating system maintains DPCs scheduled by device drivers in a queue. There is one DPC queue per CPU available in the system. At certain points the kernel checks the DPC queue and if no interrupt is to be processed and no DPC is currently running the first DPC will be un-queued and executed. DPC queue processing happens before the dispatcher selects a thread and assigns the CPU to it. So, a Deferred Procedure Call has a higher priority than any thread in the system.

Note that the Deferred Procedure Call concept exists in kernel mode only. Any user-mode code (Windows applications) runs in the context of a thread. Threads are managed and scheduled for execution by the dispatcher.

While there is a pre-emptive multitasking for threads, DPCs are executed sequentially according to the first in, first out nature of a DPC queue. Thus, a sort of cooperative multitasking scheme exists for Deferred Procedure Calls. If any DPC runs for an excessive amount of time then other DPCs will be delayed by that amount of time. Consequently, the latency of a particular DPC is defined as the sum of the execution time of all DPCs queued in front of that DPC. In order to achieve reasonable DPC latencies, in the Windows Device Driver Kit (DDK) documentation Microsoft recommends to return from a DPC routine as quick as possible. Any lengthy operation and specifically loops that wait for a hardware state change (polling) are strongly discouraged.

Unfortunately, many existing device drivers do not conform to this advice. Such drivers spend an excessive amount of time in their DPC routines, causing an exceptional large latency for any other driver's DPCs. For a device driver that handles data streams in real-time it is crucial that a DPC scheduled from its interrupt routine is executed before the hardware issues the next interrupt. If the DPC is delayed and runs after the next interrupt occurred, typically a hardware buffer overrun occurs and the flow of data is interrupted. A drop-out occurs.

We know that one of your hardware is screwing up, just need to pin point at one...

Yep, latency problem. (laptop)

Yikes, according to that site, try disabling devices from your device manager to see which one is the culprit (DO NOT DISABLE ANY SYSTEM DEVICES INCLUDING BUT NOT LIMITED TO KEYBOARDS, DISPLAY ADAPTERS, MOUSE(s), COMPUTER). Read the site for the complete warning.

zzz2496

It doesn't make sense, why would this be happening on two different machines? Both that have been clean installed? I've tried disabling drivers one by one on my desktop but I couldn't find the culprit. I had similar DPC latency checker results on a clean install format with nothing installed and everything on default.

As I said before, IRQ sharing can cause this. If a clean install doesn't resolve it, then you got a (or several?) bad driver(s). Read my quote from the site 2 posts up.

zzz2496

As I said before, IRQ sharing can cause this. If a clean install doesn't resolve it, then you got a (or several?) bad driver(s). Read my quote from the site 2 posts up.

Personally,, I want to believe this .. I really do.
But similar or same exact problems on 2 completely different PC's on one network, leads me to other places.

As I said before,, fixing IRQ's and/or fixing drivers,, might fix the problem on the 2 PC's, but I would like to see a third dropped ont aht network and see if it has problems. If it does, then IRQ's and Drivers are not the problem.

I don't want to steer away from a potential fix, but it is very odd to have this issue on 2 different PC's and have it be IRQ and Driver issues.

Unfortunately I don't have a third machine to test out and the laptop is not here anymore.

My school laptop also has red bars in DPC latency checker under Windows XP at school.