This wasn't just restricted to COM port based I/O either.
Back then I had a Logitech bus mouse. The mouse was connected directly to an ISA card, and didn't use the COM ports as most mice did back then. (I needed the extra COM port/IRQ for my modems.)
I too witnessed the 'windows is running slow when installing' bug. I often would use the mouse cursor to 'mark' the position of the loading bar (we really are spoiled for speed these days). That way when I would walk-away from an install I could see if the progress meter moved while I was away. More often then not the progress bar would still be where it was when I had left. By moving the mouse activity would return and the installation would continue.
I always assumed it was the graphics that were not being updated. A small bug with the install would keep running but the lack of input interrupts caused the display to get 'stuck'. (That would explain the sudden 'jump' in progress bar movement as soon as I wiggled the mouse.)
When I implement progress bars I most often implement "pessimistic progress", so "considering all timeouts, worst case we are 46.5% (of the time) to some result", with an update every few hundreed milliseconds. As possible mix in data from completed subtasks.
Nobody ever complains if the process suddenly speeds up because progress was made before the timeout, as long as your initial estimate wasn't absurd (looks at Windows Explorer). Even a naive progress bar counting down the 60s timeout is more informative and satisfying to watch than an endless spinner.
Windows 95/98 used to occasionally do some particularly insane estimates. I took this screenshot many years ago of copying a tiny NetHack install between drives: https://i.imgur.com/q7tc9R1.png
Vista, I think it was Vista, "fixed" that by adding an estimation pass first, that often took longer than the copy itself, and was almost as bad at estimating. It sometimes took much longer. The fix was far worse than the problem, yet it survived unchanged.
It was so bad I ended up discovering Teracopy which was decent at estimation, and far faster at copying. Was a must-have until I migrated away from Windows.
How exactly do utilities like Teracopy implement high-performance copying? In other words, what are the performance bottlenecks in explorer.exe? Personally, I've observed that:
1. Explorer attempts to do a file enumeration prior to copying, which sometimes could waste a lot of time.
2. It seems tools like Teracopy use buffering aggressively, which can speed up the copying significantly based on my experience on Windows XP with slow HDDs.
Single pass and aggressive buffering seems to cover what I remember, but it worked better than it I expected, even on high speed drives or SSD to high speed drive. They may have had other tricks, it's been a while now.
The other thing that I liked is it's non-blocking - you can continue doing copies while one is in progress, if it's to the same destination it gets added to the queue in progress. If different destination it goes in a new queue that waits for the first to finish.
I find the Progress bar is usually about as accurate as the Time Remaining calculation. Both are better than nothing but more of a fiction than reality.
True! I know some of the people involved in the windows update bar. Since cpu and dusk are so different across devices it’s hard to know actual time it will take. Instead teams divided their packages into theoretical weights and the progress bar showed the percent of total “weights”. That’s why it can be choppy is packages with few subdivisions have little to interpolate.
With a process that happens on regular intervals like a Windows Update, I always wondered why the system doesn't store metrics on how long the process has historically taken on previous runs, and then just uses a weighted average of historical times as a time-based total estimate, converted into a divisor for work-based progress estimates (i.e. if previous runs took 60 minutes on average, then progress at 25% would say "45 minutes remaining", then if it suddenly jumped to 50% would immediately say "30 minutes remaining." Even if they're choppy, those time estimates would actually be correct if you sampled and averaged them.)
Not sure if anyone's mentioned this yet, but the old original Mac OSX boot screen had a progress bar that was based on the exact length of the previous boot time.
Progress indicators that moving perfectly and steadily are probably time based, but I'd have thought they've always been work based. Example: you know you have to copy 20GB across the network; update the progress bar with 'percent of data complete' periodically (on a timer, in the byte copying loop, whatever.)
I've seen dual progress bars: one for "overall progress" (each one of five tasks fills this bar 20%) and one for the current task (maybe downloading, maybe unpacking, maybe copying, maybe waiting for hardware to reply...)
I've written progress bars that combine all of the above. Each sub-task had a weight though, and adaptive interpolation was used to animate the progress bar between chunky updates from less granular tasks based on how far they usually increment over which time interval.
I guess what has changed is me, not the computing environment. When I was young, I easily grew impatient when things were going slow. Nowadays I still kinda feel nervous, but not to the point to warrant such bookkeeping methods.
My urge to measure everything has only grown with age. I don't chalk it up to nervousness though. I'd say it's driven by curiosity and and a desire to forecast.
Shit, I think I last used it last week! In my GUI wrapper for rsync while transferring some large files. It took about 45 minutes for one of the files.
But what newbies will bever know the heck of: dip switch settings for IRQ for modems.
Thats what literally got me into computers...
In order to dial up BBSs and play tthe Pit and dl warez.
—-
Ive told this story before, but in about 1992? Or so - i got grounded for a month because i had been calling in long distance to a bbs in san jose to play the pit - and racked up a long distance bill of $926 - my dad was livid.
He yelled at me and said “why are you wasting all this time with computers! Its never going to do anything for you!”
Years later after i became successful with yee olde computerz! He apologized to me and said “im sorry i yelled at you for that time you cost me all that money in long distance charges.”
"Years later after i became successful with yee olde computerz! He apologized to me and said “im sorry i yelled at you for that time you cost me all that money in long distance charges.”"
At which point you lit up your Havana Muy Gordo with a $1000 bill and said, "Don't sweat it?"
> Ive told this story before, but in about 1992? Or so - i got grounded for a month because i had been calling in long distance to a bbs in san jose to play the pit - and racked up a long distance bill of $926 - my dad was livid.
I had this problem until I discovered a bug in a Major BBS door game (TradeWars 2002) that let me have unlimited BBS credits. No more charges on my moms phone bill and even was able to trade those for other things in real life. Early bitcoin in a way.
Looking back on it, my need to get online overrode my ethics regarding either my moms bank account or the sysops running the BBS. Oh well.
Same here, except it was San Jose to San Jose. However still had a bill because I was in Zone 1 and the BBS was in Zone 3 (phone book tells you which zone) So.. charges. Dad wasn't mad, I think he realized I was going to get a job in the field.
I also got yelled at by my dad for racking up long distance charges in 1991 or 92 but in my case it was only about $150 for calling the Sierra BBS to download stuff for King's Quest games or something :)
Similar but earlier story... staying up late at night or waking up early before school to login to BBS's. First with a Practical Peripherals modem that my dad acquired to dial into his business (which still used teletype). I got myself a Hayes 2400[1] and convinced my dad to get the fixed calling within your area code which I mostly paid for with my part-time work. I tried to stay within my LATA which included Sherwood Forest, Camelot, some others with doors and FIDO that can't recall. And then I made a mistake and on the advice of another BBS'er tried one in what I thought was a neighboring LATA. It was great! Active! Doors! gFiles! Warez! But was actually zones away in Texas. I had a good old time until the bill came. My Dad was purple he was so angry and I worked a lot of odd jobs to pay that off.
.
.
[1] somehow just before college I got a used USR Courier HST. Then I sent it in with what was probably all of my hard earned beer money for upgrade to a Courier v.Everything... I still have that one, found it while moving https://v.gd/gF83mM)
>I too witnessed the 'windows is running slow when installing' bug. I often would use the mouse cursor to 'mark' the position of the loading bar (we really are spoiled for speed these days).
Most software doesn't feel any faster compared to Windows 95 (see Wirth's law). Also most shitware does not display a loading bar anymore, instead you get some spinning stuff that's just an animation.
> Also most shitware does not display a loading bar anymore, instead you get some spinning stuff that's just an animation.
In fairness, that's because users constantly complained about loading bars not being accurate (they'd freeze, change speeds, stop right at the end etc.), but having a "true" loading bar that proceeds smoothly basically requires solving the Halting Problem. So out it went.
One time I was installing Windows 95, I had to move the cursor the whole time because otherwise the installation got stuck. I discovered this after at least 30 tries.
I mean, I still do the mouse thing all the time, regardless of OS. Not because I actually expect it to go faster, mind you, but rather because I'm bored.
A somewhat similar effect is alive and well on Android: background processes run measurably faster while user holds/moves their finger across the screen, and couple of seconds thereafter.
Mechanism is a bit different though: SufraceFlinger process that is responsible for acquiring touchscreen input, temporarily boosts CPU and GPU frequencies to make sure screen animations are nice and fluid.
A previous employer of mine explicitly requested this behaviour in their app. The app showed a map, and could align map north with compass north; to save battery, it would drop to an incredibly low frame rate (1fps?) about one second after your finger left the screen. It achieves the power goal, and has a high rating in the App Store, so I learned something about user requirements and being humble from this experience.
Question (I don't know how Android works) -- how is there even a "frame rate" for a map that isn't moving? Shouldn't it not be doing anything at all when nobody is touching anything?
Most maps these days are rendered via OpenGL (or Metal) and in those cases you still manually flip buffers and order GPU to render a frame. It's possible to control this process to avoid exessive power usage.
Of course, for most developers that might mean to not update/invalidate() a map view constantly :)
> A somewhat similar effect is alive and well on Android: background processes run measurably faster while user holds/moves their finger across the screen
Only if they do not have enough load, that is. If you have an actually loaded background process on Android it by itself will keep the clocks high. If you have a process that has short bursts of work, though, then the duration of that burst will definitely vary in response to touch boost. This is all the same as "regular" linux as it's just an aspect of most governors (ondemand, interactive, etc...)
As in, touching the display will never make this loop go faster:
void busyLoop() {
Random rand = new Random();
int data[] = new int[1000];
for (int i = 0; i < data.length; i++) {
data[i] = rand.nextInt();
}
while (true) {
measure(() -> {
for (int i = 0; i < data.length; i++) {
data[i] = (data[i] * 4) % 1000;
}
});
}
}
The hypothetical measure will observe duration to normalize to a number and then it'll stay roughly there until thermal throttling kicks in.
If, however, the loop was to look more like this:
void busyLoop() {
Random rand = new Random();
int data[] = new int[1000];
for (int i = 0; i < data.length; i++) {
data[i] = rand.nextInt();
}
while (true) {
measure(() -> {
for (int i = 0; i < data.length; i++) {
data[i] = (data[i] * 4) % 1000;
}
});
try {
Thread.sleep(5);
} catch (InterruptedException ex) {}
}
}
Then you would see the measured duration decrease when your finger was on the screen vs. not, because the kernel will consistently see that the task is not keeping the CPU it's scheduled on loaded above a threshold, so the clocks will go down all the way to idle.
Further, when installing, it would hang at some point without any sign of a prompt but would instantly continue if the mouse were moved. You could easily test this - turn your mouse upside-down during install and wait (to avoid any incidental mouse motion due to desk vibration etc).
Told my IT friend who was loading my machine and he said "you're confused; I've installed hundreds of times and never seen that". So I turned his mouse upside down and waited. Voila! It hung.
I recall quite a few times having to send a message to the message queue in code I'd written for this reason. I forget why though - someone can probably remind me, if I didn't send a message it would just stop.
It looks like you're not the only one! From the comments on the top response:
> "If true, I owe some baby boomers apologies for things I said about 20 years ago"
Me too.
What a humbling slap-in-the-face, no?
Sometimes when an idea sounds silly, and comes from a less technical person, one might disregard it even though it's easily testable/provable.
One thing about the famous "500 miles" post that I realized doesn't make sense:
----
An odd feature of our campus network at the time was that it was 100%
switched. An outgoing packet wouldn't incur a router delay until hitting
the POP and reaching a router on the far side. So time to connect to a
lightly-loaded remote host on a nearby network would actually largely be
governed by the speed of light distance to the destination rather than by
incidental router delays.
Feeling slightly giddy, I typed into my shell:
$ units
1311 units, 63 prefixes
You have: 3 millilightseconds
You want: miles
* 558.84719
/ 0.0017893979
----
But surely for Sendmail to register a "connect" with a remote SMTP server would require at least one (or many?) round trips to the remote server, so one-way speed of light time doesn't seem like it would really be relevant. Am I missing something?
Possibly the introduction wherein the author says:
"The story is slightly altered in order to protect the guilty, elide over irrelevant and boring details, and generally make the whole thing more entertaining."
If memory serves he goes into further detail about the alterations and some common objections to the story in his FAQ:
I believe one version of this story explains that the math (and the situation) has been simplified for the sake of this story in order to make it readable.
Makes sense, I can share this story to people without any computer knowledge, but something explaining how connections are established would be wholly incomprehensible to them.
What in the world could possibly be the reason in that first story for the 'file' program to look for the string 'Tue' and change to the Jam filetype? That's gotta be a very niche case, right?
On that subject, don't make fun of people who paste screenshots into Word docs and email them. On Windows 95, that was a really good idea!
MS Word was one of the few ubiquitous tools that would compress images, and certainly one of the few that people could be counted on to know. MS Paint didn't support PNG until Win98, and even then wouldn't do it by default.
If you didn't go via Word, chances are you'd be emailing a 900kB BMP at a time when people used 28.8k modems to access Hotmail accounts with 2MB caps.
From a comment:
Try opening a large file with Notepad on a contemporary machine. The window must not be full screen. When loaded, mark all text using the mouse (the keyboard works as well, it just needs more manual skill). While still holding the button down (and marking) move the mouse down, so the text gets marked and scrolled. Now compare the scroll speed while holding the mouse still versus wiggling it. Depending on your machine the speed up can be several times faster.
It's not just Notepad :-) I do this often, when I have to mark a lot of things.
It's not clear that this is caused by the same effect. A commenter suggests that this behaviour is actually due to how mouse acceleration affects scrolling speed which I am more inclined to believe.
Yeah there is no way this has anything to do with the same behavior. What's likely happening is there's a delay in auto-scroll, and by generating new mouse events your triggering manual scrolls at a higher rate (or in addition to?) than auto-scroll.
I think you'll find that Shift + Page Down is the fastest way to mark a lot of text, since you're doing it page by page instead of character by character.
I've implemented the behavior of "scroll the field down while the user is holding something selected" before, and my initial implementation had this bug, so I think I can explain a likely reason this happens. My code listened to mouse movement events, and if a selection was present and the mouse was moved into the top or bottom regions of the scrollable area, then the area would scroll a bit, and a recurring timer for some number of milliseconds would be started (if already active, then it would be reset) which would case the area to scroll a bit more. (This timer would be canceled if the mouse was moved out of the auto-scroll region.) If you continually moved the mouse, then it's possible the application would get the mouse movement events at a higher rate than the timer would fire, so the scrollable area would scroll faster. I think I found out that the platform would emit the mouse movement events at up to 60fps, so I just tweaked the timer to match that. Not a perfect solution, maybe I'll update it eventually to check the system time and scroll slower if the mouse move events are arriving faster than the timer.
I don't know the reason for that, but like the cursor to mark the progress bar method above, I do this trick to this day. You don't have to highlight first, you can just highlight as you go, wiggle the mouse outside of the bounds of the window, and then deselect when you get where you're going. And it's not just in Notepad, I do this in a programmers editor too.
Isn't it funny that many of us learned these sames ways of interacting with computers without being explicitly taught. If this were on the Internet, I would say it's a way to gauge whether you're a robot, but otherwise, it's just a measure of my impatience. Maybe it's just an acquired skill from growing up playing video games.
This applies to Macs as well. Or at least it used to, in some situations — now that I think about it, I can't really recall the last time I did that. The standard behaviour now seems to be scrolling faster the farther the mouse is from the edge of the pane (which is clearly a deliberate, and useful, UI decision).
I had completely forgotten about the mouse-wiggling trick! It's just one of those things I used to do without thinking about it. It makes sense that an event loop was waiting for an event to fire.
Are you suggesting it’s faster or slower when you wiggle the mouse? If it’s slower it could be because you put more events in the event queue that have to be pumped.
When I used to hang out at Radio Shack in the mall to play on a TRS-80's after school, they would draw a pair of asterisks in the corner of the screen and occasionally flash one of them on and off, as they loaded from cassette tape.
One of the older kids who hung out there would tell us newer kids that we could speed up loading by repeatedly pressing the up arrow key on the keyboard.
Of course us new kids didn't realize that the loading speed was completely determined by the cassette tape speed, which the keyboard couldn't possibly affect.
But at least it gave us something to do while waiting, and the older kids something to laugh at.
Reminds me back in the day using a file sharing/community program called Caraccho (for Mac) - similar to Hotline. Often people would queue up on someone's server (running of their desktop computer) to download a file since the server admin could set how many concurrent downloads from all users were allowed. Folks would send messages to people saying that if they hit Command-Q it makes the client run in "quick mode" which will speed up their download. Of course some folks would fall for this and you'd see their name drop off the server, moving everyone up 1 spot in the queue. Super effective for users that had not setup an avatar indicating they were new to the system and would fall for anything once.
> Reminds me back in the day using a file sharing/community program called Caraccho (for Mac) - similar to Hotline. Often people would queue up on someone's server (running of their desktop computer) to download a file since the server admin could set how many concurrent downloads from all users were allowed. Folks would send messages to people saying that if they hit Command-Q it makes the client run in "quick mode" which will speed up their download. Of course some folks would fall for this and you'd see their name drop off the server, moving everyone up 1 spot in the queue. Super effective for users that had not setup an avatar indicating they were new to the system and would fall for anything once.
This was also common on IRC to get script kiddies to kick themselves.
I'm confident that the Alt+f4 cheat-code was around before Runescape ;) It was inevitably told to every new member at our LAN parties in the late 90s - the few who knew were often assigned admin duty to diagnose network/PC problems (which were frequent).
It is perhaps more appropriate to say the button frequently does nothing because you frequently lack the proper permissions... https://youtu.be/ZUvGfuLlZus
In my day, they told new people that Alt-F4 made all kinds of programs run faster, unlock cheat codes, etc. Especially the online games. You always knew the adventurers when you saw "has disconnected from game."
The mouse isr would cause a loop like this to execute at some point, processing all the messages on the queue. Win95 had preemption, but it ran at 100hz. Moving the mouse caused additional queue processing on top of the time sliced preemption.
I thought the windows clock defaulted to ~60Hz. I understand it could be pushed up by software to 1Khz for audio players to work correctly. I may be very wrong on the latter point though.
Linux's default varies per architecture & platform. For a long, long time on ARM it still defaulted to 100hz. I think it's more like 250hz or 500hz now? You'll also see x86 desktop-focused build set it to 1000hz.
But scheduling happens far more often than this tick rate, too, so it's only preemption for busy threads and controls the timing windows for things like DVFS.
To this day, when waiting for some long or compute-intensive operation, I tend to instinctively move the mouse around. I guess this may be why.
Ironically, even though I grew up on Windows, I don't remember any actual case of "moving the mouse speeds thing up" on this OS - I only remember the infamous Linux cases (mouse move regenerates entropy, unblocking processes that got stuck when generating a random number call). But there must have been something, and I must have experienced it early enough in my childhood.
While running emacs over a modem to arpanet or dialup, I got into the habit of regularly typing ^A ^E to pace my cursor back and forth across the current line, to keep the connection and emacs warm.
(Like a caged leopard or mad scientist pacing back and forth.)
I could feel how responsive the connection and emacs were over time by the delay between typing and seeing the cursor move. Both the network and emacs contributed to the feeling:
There was the overall "weather" of the network: sometimes sunny and fast, sometimes sprinkled with light delays, and sometimes stormy congestion. Then there were occasional incidents that came and went, like network hiccoughs and emacs paging and grinding. And then there was the overall load of the system, which gave you the baseline delay (which gave it a very tactile day -vs- night feeling, since you got more of the machine to yourself during the night when it felt snappy, but it felt sluggish during the day).
It really felt like either the network, emacs, or both would fall asleep if you didn't keep them warm and lavish them with attention.
A VAX 11/780 running Gosling Emacs over a dialup had a very different feel than a PDP-10 running ITS Emacs over the arpanet. The busy VAX was bursty and had a lot of bumpy paging -- you had to keep your buffers warm or they would all get paged out and it would take a long time to wake back up, but there was no network delay from the direct dialup. While the PDP-10 ran smoothly like a well lubricated steam locomotive, sometimes slowing down when busy, but hovering around same speed instead of bursting, and the delay was mostly the feel of arpanet congestion and imps dozing off.
(Or so I imagined. I had a lot of time to sit and think while waiting for the cursor to move again, and the mind wanders and wonders what's happening...)
TOPS-20 had a wonderful ^T keyboard interrupt that you could
type to instantly show the system load and time. (But of course you couldn't use that in emacs, which puts the tty into raw mode.)
Somebody at the university implemented ^T to 4.2 BSD on the cs department's busy VAX 11/780, by modifying the tty driver. But initially, there was no limit to how often you could type it, and calculating the current system load wasn't a trivial operation.
So on a fast terminal, if you held down and auto-repeated ^T, it would bring the entire system to its knees, and you could watch the load go up and up and up as you caused it to! Very satisfying indeed.
Eventually they put in a one-per-second limit on ^T.
> While running Emacs over a modem, I got into the habit of regularly typing ^A ^E to pace my cursor back and forth across the current line, to keep connection warm.
Huh. I got into that habit recently, because over the past year, I've been frequently working on the go, by SSH-ing to my home desktop and using Emacs terminal frame (emacsclient -t)[0]. I do regular "weather checks" with ^A and ^E - because the hardware has its weather, SSH has its weather, and the link I'm on has its own weather too (particularly when using an LTE hotspot, though I've noticed even when being in the same LAN, the response time is not always consistent).
What's old is new again :).
--
[0] - With terminal emulators supporting 256 colors, it looks very similar to the GUI Emacs. This mode of working is really quite good, and lets me use my underpowered sidearm 2-in-1 tablet/netbook to do things that would ordinarily require powerful hardware.
> > While running Emacs over a modem, I got into the habit of regularly typing ^A ^E to pace my cursor back and forth across the current line, to keep connection warm.
> Huh. I got into that habit recently, because over the past year, I've been frequently working on the go, by SSH-ing to my home desktop and using Emacs terminal frame (emacsclient -t)[0]. I do regular "weather checks" with ^A and ^E - because the hardware has its weather, SSH has its weather, and the link I'm on has its own weather too (particularly when using an LTE hotspot, though I've noticed even when being in the same LAN, the response time is not always consistent).
You may find mosh [0] to be useful, as it buffers input client side to remove input lag.
The ^T command is actually still around in Unix/Linux, but only when the program is reading input using canonical/cooked/non-raw mode. That's pretty uncommon these days, since input tends to be wrapped in readline or similar to allow for editing.
You can test it by running `ed`:
ed scratch.txt
2096
^T
load: 0.57 cmd: ed 74469 waiting 0.00u 0.00s
q
Running `stty -a` lists all of the characters that have special meaning when the TTY driver handles input this way, before the program sees it.
Sorry, but I'd just like to point out that top answer (about async I/O in Win95) is wrong and sounds like someone repeating something he (mis)heard once.
I actually wrote apps in the Win95 days, and I can say that async (i.e. overlapped) I/O, which seems to be what he's talking about in the rest of the answer about IO completions, basically does not exist at all on the Win9x series; it was an NT-exclusive feature. There were some bits and pieces that seemed to work somewhat from what I remember, but to quote my trusty old WIN32.HLP regarding the ReadFile function:
"Windows 95
For asynchronous read operations, hFile can be a communications resource, mailslot, or named pipe handle opened with the FILE_FLAG_OVERLAPPED flag by CreateFile, or a socket handle returned by the socket or accept functions. Windows 95 does not support asynchronous read operations on disk files."
...so his example about file copying and installers is invalidated. The correct answer(s) are of course lower down on the page and in the comments, where everyone talking about "pumping the message loop" gets it right.
The second anecdote about scrolling behaviour also hits vaguely beside the point; it has nothing to do with multitasking, is only tangentially related to "pumping the message loop", and can be explained very simply: moving the mouse causes a WM_MOUSEMOVE message to be sent to the window, containing the new coordinates of the cursor. The edit control that Notepad is composed of handles this message when in selection mode by checking if the position is outside of the control, and scrolls appropriately by a single amount if so. If you continue moving the mouse outside the control with a selection highlighted, the generation of WM_MOUSEMOVE continues, and thus the scrolling too. Stop moving the mouse, and the scrolling stops. There is nothing else to it. Other controls/windows (e.g. browsers) may handle this select-scroll behaviour differently; some will start a timer that continues to issue scroll messages as long as you hold down the button, and some even fancier ones will vary the rate of the timer depending on how far from the control's edge the current position is (so you can adjust the auto-scrolling speed easily.)
Only the third answer is when we start getting closer to an accurate explanation, the fourth answer about WM_TIMER is quite off-the-mark, and then the rest of them vary in accuracy between "close, but not quite" and "no, just no."
(Incidentally, this is also one of the reasons I don't use SE/SO.)
So in today's world... why do so many PCs emit a slight sound when moving the mouse. I know that there are high frequencies involved and periphery is one of the worst perpetrators of electromagnetic interference, but I still find that strange. And what exactly is emitting the sound here?
Generally it's cheap/poorly designed audio amplifier circuits. Even though modern PC audio is mostly digital, the final stage (getting sound out the speaker) is still analog. If the motherboard designer isn't careful about how they place/isolate/ground the analog audio circuitry, it can pick up some of the PC's stray high frequency noise which gets worse the more you turn up the volume since now the noise gets amplified too.
A work around if you have a motherboard that is particularly bad about this is to use the digital audio output (S/PDIF via an optical or RCA jack) to connect an external amplifier or you could stream it via software. This tends to only be an option if the machine is stationary and not terribly realistic for people with a laptop on the go.
You're assuming a precision in their post that I wasn't (i.e. that it's actually coming from the PCB, rather than 'the collection of parts called a PC sitting in front of me'... which would include the speakers for most people)
> You're assuming a precision in their post that I wasn't (i.e. that it's actually coming from the PCB, rather than 'the collection of parts called a PC sitting in front of me'... which would include the speakers for most people)
For what it's worth, this _is_ hacker news. I concede not everyone is tech savvy but I tend to respond to comments as if they are.
Making a huge selection with mouse in LibreOffice spreadsheets even today goes faster if you move the mouse while dragging one endpoint of the selection over the spreadsheet borders which causes the sheet to scroll. Likely the very same cause: there's a timer or other repeating tick to scroll content at a reasonable speed but the sheet is also scrolled when input events wake up the same loop.
I remember this with any selection in windows on at least 3.1/95/98/SE.
This happened if you kept the mouse just inside the window and moved it about 10-20px up and down in/out pf the window in the direction of the selection.
It was a way for me to scroll faster than with the wheel or cursors on web pages if you selected some text and then kept the selection on the end of the screen and moved the mouse wildly in the edge of the screen.
As I was younger then, there was probably a better solution to do this but I was not aware of it.
We had a milling machine that ran from Win95, and we had to discipline ourselves not to move the mouse when it was milling a complex shape. Otherwise the machine would stutter and give us a nasty finish on the machined part.
I remember writing documentation circa 2002 for a development environment that required Visual Studio 6.0 and as part of the install notes I wrote something along the lines of -
"During installation constantly move the mouse in a circular motion over the installation window. This speeds up installation roughly 2-3x"
In some applications with scrolling work areas, I'd end up trying to move it in pixel perfect straight lines when dragging stuff past the visible work area, so as to speed up the refresh and keep the mouse in the part of the border where you get maximum scrolling speed.
I always assumed that Windows95 was just scared of mice, so if you shook one at it, it would either run faster in fear, leaving a trail of random disc sectors, or suddenly hide under its special blue blanket and refuse to come out again.
I have a terrifically annoying bug that shows up somewhere between X and GTK and all Gecko-based browsers. While I'm scrolling down in a web page with the mouse wheel, within a few seconds the page will stop moving. The mouse will still move around, but it will stop changing its cursor based on hovered elements, and further mouse actions will do nothing. It will unjam itself something like 30 seconds later if I wait, or immediately if I press any key. Then all the queued mouse events will rush through at once, so if the key I hit was Ctrl, the page's contents zoom out and I have to reset it. If I hit Shift, it walks back through the history and I lose my place. So I was hitting Alt for a while, besides shopping for a distro.
I couldn't debug it normally, or even get a clue about which package needs to be downgraded, because I can't pop over to the terminal without unjamming it. So I'd need another machine with which to SSH in, and those are all unusable ATM (well, I probably just needed to suck it up and install SSH on the phone). But ${somehow} I found out that triggering a redraw with ${something} also unjams it, so I set the clock in the XFCE panel (also GTK, FWIW) to display seconds as well. Now it still jams but always for less than a second.
Sorry, something resurfaced-- I think I remember now that I switched on seconds for the sake of finding out more precisely how long a jam would last. Immediately it became obvious that they didn't last long anymore, and that the reason it used to be "30-ish seconds" was whenever the minutes finally changed, it broke loose just the same way.
Wow, I remember doing this as a kid and thinking to myself that I was being stupid because surely wiggling the mouse would make the computer have to process more input and actually slow down whatever I was impatiently waiting for. I still did it though, because I _felt_ like it made things go faster. Turns out that intuition was right. Funny how we can learn to do things that actually work even when our conscious mind doesn’t believe they do.
And this reminds me of when I accidentally figured out playing MOD sound files in DOS 6 with a new and especially beautiful STM/MOD player at the time would sound considerably better from my 486's PC speaker if I pressed the pause/break key to literally lock up the system. Apparently the player would buffer enough of the song that even though everything froze up, the sound would continue playing. I couldn't afford a dedicated Soundblaster/Gravis sound card but I still pined to hear all the amazing music coming out from the demo scene. The quality of course wasn't comparable to a dedicated soundcard but it was still a huge improvement over the typical beeps/bloops of the built-in PC speaker.
Galaxy 2.12 (glx212.zip) is my favorite for pre-386 machines. It'll do remarkable things with a covox or even pc speaker, and realtime FFT (not faux bouncing bars, either!) to boot!
The softness is precisely what made them a useful check, though. Tapping num lock has two important properties: Nothing should ever be blocking that process, and it's harmless to do and should never really affect what's happening.
In 1986, some computer graphics researchers in California (namely Conrad Huang, Ken Arnold, and Greg Couch at U. of California, San Francisco, Computer Graphics Lab) wrote a multi-player TTY game called hunt.
The game of hunt is clocked by the arrival of events. So that is to say, the arrival of packets from the game clients into the server drives the game forward. The more furiously people play and the more players there are, the more rapid is the movement of automatic objects, like shots traversing through the maze.
I last played this in 1995. I had a WYSE 50 terminal hooked up to a Linux box and played with a friend. One of us was on the console, one on the terminal.
I remember I had to patch something socket-related in the source code to get it working.
Entertaining, but probably unrelated: there was a systems paper from the late '90s or early 2000s (SOSP?) where the authors used an extremely low priority process recording timestamps to instrument system behavior. Basically, because the process wouldn't run if anything else was runnable, it wouldn't generate its periodic timestamps. As a result, they could easily see relatively low-level details about system CPU behavior.
One thing they discovered was that Windows 95 would enter a tight CPU polling loop if you held the mouse button down. So, don't do that.
[Edit: dammit, I cannot find the paper. Sorry. It was really interesting.]
I definitely remember seeing scrolling-is-faster-if-you-wiggle-the-mouse on Linux too, back in the day, and being surprised that a bug (? misfeature?) like that would show up on such different stacks.
Back in the day it wasn't a bug, but rather more of a cheat to make your system feel faster than it really was: if the system actually gave the UI a fair share of CPU cycles, the system would feel incredibly sluggish. Conversely, if it gave the UI the lions share of CPU, nothing would ever get done in the background. So it compromised and gave the UI preferential treatment when the user was active (i.e. when there was recent mouse/keyboard activity), and a more fair allocation when they weren't so other things could get done.
I had something that may have been related. In VLC with my old monitor (1920x1080) watching a film it would often flicker painfully. I found moving the mouse continually would make it smooth. A bit of python...
import ctypes, time
def move(x, y):
ctypes.windll.user32.SetCursorPos(x, y)
for x in range(10000000):
move(0, 0)
time.sleep(0.01)
move(1, 1)
... and all was well.
(When I upgraded to a 4K monitor things got worse and the cursor fiddle doesn't help).
One thing that also worked was to open and close the CD-ROM tray. It felt like HDD was waiting for something that open-close action on the CD-ROM drive would trigger some reaction.
Its like rage shake for mouse! If you are angry and shake your mouse in rage it moves things faster. I imagine this would be a very satisfying thing to be able to do.
Given all the me too's. How about this one, same basic problem in the mid 2000's with linux. We were running a few servers with a normal desktop distro. I got the bright idea that since no one was actually on the console we could save some ram/CPU by changing the default runlevel and not starting X/etc. Took about 2 days before someone complained we were running about 20% slower than normal.
I think in the end the solution was to just fire off a X/xdm pair as I wasted a few days looking at scheduling/numa/shared interrupts/etc trying to get a good solid solution that didn't require starting X. We ran it like that for a couple years until eventually someone tried it again (after a bunch of software/hardware upgrades) and the perf didn't fall off.
Try opening a large file with Notepad on a contemporary machine. The window must not be full screen. When loaded, mark all text using the mouse (the keyboard works as well, it just needs more manual skill). While still holding the button down (and marking) move the mouse down, so the text gets marked and scrolled. Now compare the scroll speed while holding the mouse still versus wiggling it. Depending on your machine the speed up can be several times faster.
I always thought that this scroll behavior is known and special in that it helps precise scrolling. I know winapi and why this happens, but never viewed it as a wild bug. Can’t recall now, but I think Mac and Linux behave the same way. Can someone confirm that?
“One danger of the MsgWaitForMultipleObjects function
is calling it when there are already messages waiting
to be processed, because MsgWaitForMultipleObjects
returns only when there is a new event in the queue.“
Wow, I always moved the cursor over the progress bar as I believed it made the installation go faster, but I never had actual proof. I guess I wasn't the only one.
I remember that with Windows 98SE, when it got stuck most of the times you can make it come back to life again by opening/closing the CD tray a lot of times...
We were doing some processing on a database and updating the progress bar every record. We processed the UI messages at that point as well so any click on Cancel could get through.
As customer databases grew, the processing began to exhibit this behaviour.
If I remember well, we fixed it by only updating the progress bar every 1%. It may have been more complicated than that though, I had moved on to another job when the fix was done.
Now the only thing left is to figure out why Dungeon Keeper II crashed roughly 50% of the time at startup. Don't ask about my procurance of said software; we do not speak of such things.
EDIT: And of course, a person who should not be named at the time remarked: "Computers always do the same thing, DKII can't be crashing sometimes and other times not..."
I think I remember (1980s/90s) if you were copying a file to/from a remote host (with ftp or something), you could improve the throughput speed by pinging the remote. Maybe ethernet, or maybe ppp/slip, I'm not sure.
What olden times are the article and the comments speaking of? Scrolling is still faster when selecting while wiggling the mouse, at least on Windows 7 with Firefox, for me. Just tried it right now to make sure.
Would it actually run more quickly or just feel like it was running faster? I thought moving the mouse gave more frequent feedback but I didn’t think it reduced the time it took to install an application.
i used to have an obsessive habit of right-clicking the desktop and selecting refresh. took me ages to exorcise that out of me when i switched to a linux. i remember not liking that it didn't have that option.
And when you click in Excel while it is stuck computing, does it prioritise the cell you are clicking on, or could it be that it actually does compute more quickly then?
In order to show the properly random and non-deterministic behavior (e.g. random BSODs) that Windows users have come to expect, MS Windows needs to continuously gather high-quality entropy from its surrounding environment. That's why it stops when you're not wiggling the mouse; it's just waiting for you to provide the additional entropy it needs.
No, it’s actually a little-known feature that allows Win95 to temporarily upclock the CPU during peak loads, using the power generated by vigorous mouse movements.
I too witnessed the 'windows is running slow when installing' bug. I often would use the mouse cursor to 'mark' the position of the loading bar (we really are spoiled for speed these days). That way when I would walk-away from an install I could see if the progress meter moved while I was away. More often then not the progress bar would still be where it was when I had left. By moving the mouse activity would return and the installation would continue.
I always assumed it was the graphics that were not being updated. A small bug with the install would keep running but the lack of input interrupts caused the display to get 'stuck'. (That would explain the sudden 'jump' in progress bar movement as soon as I wiggled the mouse.)