Back in My Day when people had POTS modems , I once downloaded the ~20 disks of the b'a'se and 'n'etwork slackware disk series in windows 95 and rebooted to install, hoping that none of the disks were bad.
It turned out that all of those disks were fine, so I continued downloading the other disks in the series by minicom'ing to my ISP's shell account, ftping them to the remote disk, and zmodem'ing them to my local disk. I played nethack on another virtual terminal while this was working.
Well, I switched back about 5 minutes later to check on the progress and it was just crawling, like 4KB every few seconds. I moved the mouse to hit the 'cancel' button on the zmodem transfer window, and the transfer rate shot up just then. I thought "well, okay..." and went back to nethack.
A few minutes later same thing happened. Move mouse, transfer speed goes up. I didn't understand IRQs at the time but I grasped apparent causality. I decided I'd try moving the modem to a different IRQ but that required a reboot. I wanted to finish the current disk set, so I sat there with a book in one hand, twirling the mouse in little circles with the other.
That's my hand-crank modem story.
To this day, whenever the network is slow, I twirl the mouse in little circles subconsciously.
I logged in to upvote this story because I encountered the same problem on a military communications system once (!) There was an interaction between the system beep() function and message processing throughput. If a large number of alerts ever queued up, communications slowed to a crawl as the CPU spent all its time going "beeeeeeep...beeeeeeep...beeeeeeep..." for a few minutes. Moving the mouse caused a rapid-fire "bebebebebebebebebebebeeep" as the buffers flushed and throughput returned to normal.