Seems like it would be a good thing to be running MariaDB as one of your backups, or test machines just (to show your Oracle support rep:) in case, so if one or the other starts to shine you've seen it working with (replicas of) your data, and know it's compatibility status.
If it's that easy now, and you had anything close to an important (or large) database someone should be booting both from time to time in testing. It could go either way...
I'm curious what's meant by drop in replacement, is it as simple as installing the other package, and just pointing it to your database folders, files, configs, SQL query, programs, whatever else is required (forgive me i have limited knowledge here) and launch it with your same scripts with simple swap_the_filename type mods...
or
Is there lots of scripting, reconfiguring, importing and testing that needs to be done to make it work the "same"?
What is meant by drop in replacement if someone was going to make the switch now?
I had some very large electroltytic caps in an variable out DC power supply I designed get switched around during a pilot build and make it through final inspection, and when I powered the first 8 of them up and those 10V caps saw 48V on our endurance stand the whole room was lit up like the 4th of July as molten aluminum and shrapnel blasted me in the face, it was quite exciting.
The coffee machine where I used to work would do that. I asked the vending machine guy about it, and he said it was adjustable, and set so every 50th cup was free. It was not a random 1 in 50 chance, simply every 50th cup.
There was a beat up old sticker by the bill validator that said "I will be giving away DRINKS ON THE HOUSE! Watch for the message, Listen for the beeps, IT MAY BE YOU"
Not everyone knew about it, so there was also about a 1 in 100 chance that their change would be left in the coin return:)
If they go for the market that wants a phone that respects the privacy of the user, and doesn't send every keystroke back to the mothership for datamining, they might do reasonably well!
In ten years, something equal to today's fastest supercomputer will fit in a passively cooled box the size of a shipping container, so densely packed they'll need a robot to go in and bring you the faulty board to repair or replace it.
It will also help with legacy systems...
A lot of what was said sounded to me like how to manage massive remote, lights-out datacenters (or other fully automated locations) for service and repair, and that IBM teamed up with someone having experience with complex factory automation to build the hardware.
You likely won't wanna service the computer of the future. Liquid cooled where it has to be, tightly packed and hot as hell everywhere else!
The cool aisle will be replaced by the hotter aisle, and no human would wanna spend more than 5 minutes in it, even with a proper burn resistant suit on!
For years I've been launching apps by pressing Control+Escape then "'R" then type the app name (CALC) at the run prompt.
I often have to use someone else's computer, and it's much easier to remember a few app names that haven't changed in over 10 years than to find my way around a strange start menu.
Everyone always asks how I got that program to open so fast! The newer launchers provide similar functionality without having to remember the exact executable name, so I'd think (haven't used Win8 or Gnome 3) that it would be something I could get used to (maybe even like) if I was forced to use those desktops. I'd hate to have to use a mouse to get there though!
One of my life long friends just made a baby in only 24 weeks! She was only 12 inches long and weighed just 22 ounces!
AND...
Just like any other project that was "pushed out" to production too soon, It took another 100 days of rework at the Neonatal Intensive Care Unit before she could go home, and at $13,000 a day (not including any diagnostic testing) it is far more cost effective, and much lower risk, to give the project the time it requires "up front".
BUT!!!
Thanks to the dedication of all the nurses and doctors, and the wonders of modern technology, they are now both home and perfectly healthy:)
I've had that happen twice, and both times I was listening to air traffic control and the crew on the headphones. What happened to me was they had another plane coming in for a landing in the opposite direction right above us, and the other plane was coming in too low, and our plane had to chop the throttles, and drop 500 feet because there was less than (the planned) 1000 feet between us and the plane above us! It's pretty f'n scary, you're right. All of the sudden the engines go from a roar to a whisper, and you drop like a stone for a few seconds, then it's Wide Open Throttle so we didn't end up in someone else's way!
I still remember the shadow of the 747 going over us and feeling our plane struggle as we went through their turbulence!
Looking backwards from my window, I could see it cross our path, and it was terrifying to think how close we really were to the other plane!
The pilot made it sound like it was no big deal, but the pants they were a shittin' that day!
It's crazy to fly past a busy airport and watch the planes take off and land from another plane. It looks like a busy freeway on ramp at rush hour!
That is one of the nice features of the Atmel XMega parts as well as FPGA, IE being able to have a value automagically transferred from one piece of hardware to RAM based on a hardware trigger from another interrupt source without having to service the interrupt generated from your hardware as soon as possible to move the value yourself.
For lots of other parts you have to rely on a fast context switch to your ISR and at least put that value somewhere where it won't get changed by the continuous stream of pulses being sent to the counter while your software gets around to using the value.
Every time you waste hi-priority foreground execution time on real time events, your real time system as a whole becomes less and less real time. Android also has nothing to deal with this, which makes it unsuitable for these types of real time control applications. There is nothing to guarantee that your 100 mSec hardware stored value will get read correctly by every asynchronous 100 mSec software loop, and the two will get out of phase enough that you will start reading one value twice on the same sample, and the control loop will begin missing every other sample from your hardware, or WORSE yet, one of your loops gets on the stack, and finally gets executed 10 mSec after the loop already ran again using the data from before as a new process input, and your autopilot was just informed it is now going backwards.
I've seen (fixed the problems caused by) software loops that relied on the value from a 100 mSec event scheduled to execute at 20 mSec intervals as forground tasks because that way the program would be sure to "not miss an update" because the software was too decoupled from the state of the hardware due to the OS selected. It was impossible to guarantee that two separate tasks set at 100 mSec intervals (one storing data, one using it in a control loop) would execute in the right order within the right timeframe to have any reasonable level of (stable long term) control over a process.
If you can live with stale or missed samples for the data in your control loops, by all means use WinCE, or Android (:and use lots of threads too:) If you need to do a proper job of real time process control (and monitoring) then you need a real RTOS with hard constraints on the resulting program execution. You have to be able to properly define the order of your software operations to match what's going on in the real world. Many things you just assume would have to happen correctly will not work correctly 100% of the time without an RTOS, and you might not notice it until you ship it, and your customers complain, and then you are really fucked because you have 2 years in band-aiding WinCE along, and you thought you had it working, but to really fix it right you have to start over (but expression blend made it easy to make a really pretty GUI) after you try to respin the hardware quick with a CPU that costs twice as much to cope with all the wasted cycles, and it still doesn't work right.
If it was THE embedded systems conference (ESC), in the early 00's it was sponsored largely by QNX, VxWorks and Mentor Graphics (Nucleus RTOS) they even provided your folders for the event at that time, and sponsored many of the classes they had. I remember attending (still have the handouts in the binders) many talks that mentioned Linux, used it for part of the demos, and either made note of it's increasing functionality and popularity, or gave hints that Linux based products were being developed by nearly all the big proprietary RTOS vendors, and by 2003 - 2004 Linux was Everywhere at ESC.
I first ran Linux in 2001 after some kind soul gave me a boxed copy (with manuals) of Mandrake Linux 8.0 at ESC. My boss and I spent the night installing it on our work laptops with partition magic and boot magic so we could play around with some of the demo code from class.
There was also lots of talk at that time about could you use GCC as a replacement for Green Hills etc. and we played around trying to get our ECU software and proprietary OS to build under GCC dreaming of the cost savings we would realize once we got it to work!
Lets say that your valve is from a 1987 Ford and it is for idle speed control. those valves run at 10 Hz so your best case 1 Msec response time will give you 1% increments from 0% - 100%. If you had a requirement to have better than 1% resolution, you couldn't get it. If your response time varied by 1 Msec as well, you couldn't hold better than 3% on the valve position giving your engine a roughly + - 2% window on the the idle speed. This in itself would be an objectionable level of idle stability on the slowest valve ever used for idle speed control.
But you might have a hardware PWM to help you gain accurate control of the valve by just loading a value to a register and calling it a day because the hardware timer will take care of giving you an accurate frequency and duty cycle, what could go wrong then?
The same issue would still manifest itself perhaps even to a greater extent because the PID calculations that you would be using for the speed control loop on your idle speed need to be taken at very exact intervals to get a good cause and effect relationship out of those calculations. At a 600 RPM idle on your 5.0L V-8 you will have 40 combustion events per second, and the PID would likely be calculated at the most every 50 mSec to get any kind of stability out of it. If your scheduling and task swapping caused that calculation time to vary + - 1 mSec that would also create a ~4% error in the PID output because it might have really measured the change over 49 - 51 mSec and now you not only have an invisible (to the software) amount of jitter to deal with you run the real risk of having 1 or 2 or 3 of the 25 mSec combustion events being used in your current idle speed calculation. If you got unlucky and just missed the 2nd combustion event in your calculation, you only have half of the "power in" you expected when you calculate what effect your valve position is having on your engine speed, your PID may say "hey, we need the valve open more!" so that calculation will drive the valve too far open. The next time the PID calculates it is likely to see the effects of 3 combustion events which will be driven by a valve that is now too far open and overcompensate again by closing the valve too much. The resulting engine speed will become very unstable.
You can see where you might want to be able to run that calculation faster say on a 10 mSec schedule. Now your 1 mSec jitter will result in a 20% variability in the time used in the PID calculation sometimes, so while you can run the calculation more often, and filter the output to the valve to keep your PID loop from essentially aliasing your combustion events, your increased time variance will somewhat negate any gains you had from running the calculation 5X faster increasing your CPU load (which will increase your 1 mSec response time jitter) and might make your system even harder to tune for a smooth idle.
Another Example:
If you were trying to monitor a 1 khz frequency by accumulating the pulses in a hardware counter and and were reading the result every 100 mSec, and you had 1 mSec jitter on the time you read your 1 mSec pulses. You would have a sample period of 99 - 101 mSec, this would automatically limit you to 10 hz resolution on your pulses (99 to 101 of them * 10) so your measured speed would best case read out 990 - 1010 hz and your control system would have to live with never knowing if it was really at 990 hz and read the frequency too soon, or it was at 1010 hz and read it a little too late. It would severely limit the control you would have on the process that was generating the pulses.
Thank You, I was (obviously) not aware that's what was done on EXT2. Is that also done with any of the other Linux filesystems?
It seems logical that leaving the extra space between files would help reduce fragmentation as the disk becomes full as well, because the more room you leave between files, the better chance you have of being able to fit a new file somewhere in one piece. You could write it near the end of the extra space to allow both files to still be modified without having to break the files into pieces. Even having to Dollie up a file into parts to fill space could be written on sequential tracks so the heads don't have to seek to read the file, just skip past the first file as it spins by.
It makes me wonder if it would be worth it to have a filesystem that was designed around the huge sizes of HDD's available today that would make an effort to write files as continuous blocks of data, and perhaps allow you to somehow define the approximate size of the file to automatically leave space around and even in the middle of it to be able to modify it and still minimize fragmentation. Something static like a PDF or image file could be set to not need this extra space, but if you were working on a large document you could do a "save as" or the first save the program could give you the option of defining how much space to set aside for the file, and create bins to store your documents in that would help to keep them sequential so you just skip a few deleted tracks instead of having to reposition the heads. That would help speeding up future reads and writes, and make it much easier to figure out if a particular file could go into any used space that is ready to be overwritten by knowing if what you are saving is likely to ever need more space than where you are storing it. Perhaps your image and document directories could be created in 200 MByte chunks to help speed up accessing the directories while previewing documents or flipping through your pictures as well.
I had some audio and video programs I used to use on my older PC's that would allow you to tell the program in advance how long of a recording you were going to make so that they could prepare a space to be able to write them as continuous files. On my older PC's it made the a huge difference in the quality of recording I was able to make without the occasional stutter, and the responsiveness of the system especially while recording video. Once the drive became close to full, it might take the program 5 - 10 minutes to prepare the disk buffer, but it would not have ever had the horsepower to do it while recording.
I remember the last XP computer I had at work. The hibernation and pagefile became very badly fragmented, and by turning them off, deleting them, defragmenting the hard drive, and forcing them to be a certain size when I recreated them, the computer was much more responsive when it started having to swap, and it cut the time to hibernation down from 3 - 4 minutes down to 20 - 30 seconds.
Perhaps it's something the drive firmware could also do, but I think a little guidance from a competent user and some smarter software could help speed up file access times through the OS as well.
I'd bet that they have gotten much faster as a result of the ever increasing density of the platters as well. With the higher density drives putting bits past the heads twice as fast every time the density doubles, the additional ~40% increase in RPM is likely becoming less important, and for most people it's a better investment increasing the capacity.
Slashdot Mirror
You can has some of my cheezburger since I blew all 15 of mine already...
Tomorrows another day...
Quick someone figure out the cost per revolution of a wheel if the rover only completes the primary mission...
Please
I wonder if this impacts the strength of the wheel any with all those dashes, perhaps just saying hi would make them more durable.
Seems like it would be a good thing to be running MariaDB as one of your backups, or test machines just (to show your Oracle support rep:) in case, so if one or the other starts to shine you've seen it working with (replicas of) your data, and know it's compatibility status.
If it's that easy now, and you had anything close to an important (or large) database someone should be booting both from time to time in testing. It could go either way...
I'm curious what's meant by drop in replacement, is it as simple as installing the other package, and just pointing it to your database folders, files, configs, SQL query, programs, whatever else is required (forgive me i have limited knowledge here) and launch it with your same scripts with simple swap_the_filename type mods...
or
Is there lots of scripting, reconfiguring, importing and testing that needs to be done to make it work the "same"?
What is meant by drop in replacement if someone was going to make the switch now?
Cheers / Thanks!
"fear of an armed negro"
This requirement would make the sensor design much easier...
The end with the hammer must look whiter than the end with the hole....
Of course I kid!
Cheers!
I had some very large electroltytic caps in an variable out DC power supply I designed get switched around during a pilot build and make it through final inspection, and when I powered the first 8 of them up and those 10V caps saw 48V on our endurance stand the whole room was lit up like the 4th of July as molten aluminum and shrapnel blasted me in the face, it was quite exciting.
Cheers
Same as it ever was...
The coffee machine where I used to work would do that. I asked the vending machine guy about it, and he said it was adjustable, and set so every 50th cup was free. It was not a random 1 in 50 chance, simply every 50th cup.
There was a beat up old sticker by the bill validator that said "I will be giving away DRINKS ON THE HOUSE! Watch for the message, Listen for the beeps, IT MAY BE YOU"
Not everyone knew about it, so there was also about a 1 in 100 chance that their change would be left in the coin return:)
Cheers!
For sperd ansd accuryacy nithimgncan beeat thenresl keyboa5d on my mOtoropla Pho5on Q 4G LTE!1
yp'ucfe m7sta never teiwd a good keybopard beforew!
sen4g from my Q
If they go for the market that wants a phone that respects the privacy of the user, and doesn't send every keystroke back to the mothership for datamining, they might do reasonably well!
Sometimes I really miss WinMo 6.5...
In ten years, something equal to today's fastest supercomputer will fit in a passively cooled box the size of a shipping container, so densely packed they'll need a robot to go in and bring you the faulty board to repair or replace it.
It will also help with legacy systems...
A lot of what was said sounded to me like how to manage massive remote, lights-out datacenters (or other fully automated locations) for service and repair, and that IBM teamed up with someone having experience with complex factory automation to build the hardware.
You likely won't wanna service the computer of the future. Liquid cooled where it has to be, tightly packed and hot as hell everywhere else!
The cool aisle will be replaced by the hotter aisle, and no human would wanna spend more than 5 minutes in it, even with a proper burn resistant suit on!
Cheers!
.
For years I've been launching apps by pressing Control+Escape then "'R" then type the app name (CALC) at the run prompt.
I often have to use someone else's computer, and it's much easier to remember a few app names that haven't changed in over 10 years than to find my way around a strange start menu.
Everyone always asks how I got that program to open so fast! The newer launchers provide similar functionality without having to remember the exact executable name, so I'd think (haven't used Win8 or Gnome 3) that it would be something I could get used to (maybe even like) if I was forced to use those desktops. I'd hate to have to use a mouse to get there though!
Cheers!
+2
That's so true it's funny.
I wonder how much power the millions of Visa and Mastercard point of sale card swipers consume in comparison?
Anyone have access to one they can plug into a Kill-A-Watt for a few minutes?
Cheers!
One of my life long friends just made a baby in only 24 weeks! She was only 12 inches long and weighed just 22 ounces!
AND...
Just like any other project that was "pushed out" to production too soon, It took another 100 days of rework at the Neonatal Intensive Care Unit before she could go home, and at $13,000 a day (not including any diagnostic testing) it is far more cost effective, and much lower risk, to give the project the time it requires "up front".
BUT!!!
Thanks to the dedication of all the nurses and doctors, and the wonders of modern technology, they are now both home and perfectly healthy :)
Cheers
I've had that happen twice, and both times I was listening to air traffic control and the crew on the headphones. What happened to me was they had another plane coming in for a landing in the opposite direction right above us, and the other plane was coming in too low, and our plane had to chop the throttles, and drop 500 feet because there was less than (the planned) 1000 feet between us and the plane above us! It's pretty f'n scary, you're right. All of the sudden the engines go from a roar to a whisper, and you drop like a stone for a few seconds, then it's Wide Open Throttle so we didn't end up in someone else's way!
I still remember the shadow of the 747 going over us and feeling our plane struggle as we went through their turbulence!
Looking backwards from my window, I could see it cross our path, and it was terrifying to think how close we really were to the other plane!
The pilot made it sound like it was no big deal, but the pants they were a shittin' that day!
It's crazy to fly past a busy airport and watch the planes take off and land from another plane. It looks like a busy freeway on ramp at rush hour!
Cheers:)
This seems like something that powerline networking was made for!
That is one of the nice features of the Atmel XMega parts as well as FPGA, IE being able to have a value automagically transferred from one piece of hardware to RAM based on a hardware trigger from another interrupt source without having to service the interrupt generated from your hardware as soon as possible to move the value yourself.
For lots of other parts you have to rely on a fast context switch to your ISR and at least put that value somewhere where it won't get changed by the continuous stream of pulses being sent to the counter while your software gets around to using the value.
Every time you waste hi-priority foreground execution time on real time events, your real time system as a whole becomes less and less real time. Android also has nothing to deal with this, which makes it unsuitable for these types of real time control applications. There is nothing to guarantee that your 100 mSec hardware stored value will get read correctly by every asynchronous 100 mSec software loop, and the two will get out of phase enough that you will start reading one value twice on the same sample, and the control loop will begin missing every other sample from your hardware, or WORSE yet, one of your loops gets on the stack, and finally gets executed 10 mSec after the loop already ran again using the data from before as a new process input, and your autopilot was just informed it is now going backwards.
I've seen (fixed the problems caused by) software loops that relied on the value from a 100 mSec event scheduled to execute at 20 mSec intervals as forground tasks because that way the program would be sure to "not miss an update" because the software was too decoupled from the state of the hardware due to the OS selected. It was impossible to guarantee that two separate tasks set at 100 mSec intervals (one storing data, one using it in a control loop) would execute in the right order within the right timeframe to have any reasonable level of (stable long term) control over a process.
If you can live with stale or missed samples for the data in your control loops, by all means use WinCE, or Android (:and use lots of threads too:) If you need to do a proper job of real time process control (and monitoring) then you need a real RTOS with hard constraints on the resulting program execution. You have to be able to properly define the order of your software operations to match what's going on in the real world. Many things you just assume would have to happen correctly will not work correctly 100% of the time without an RTOS, and you might not notice it until you ship it, and your customers complain, and then you are really fucked because you have 2 years in band-aiding WinCE along, and you thought you had it working, but to really fix it right you have to start over (but expression blend made it easy to make a really pretty GUI) after you try to respin the hardware quick with a CPU that costs twice as much to cope with all the wasted cycles, and it still doesn't work right.
Cheers!
If it was THE embedded systems conference (ESC), in the early 00's it was sponsored largely by QNX, VxWorks and Mentor Graphics (Nucleus RTOS) they even provided your folders for the event at that time, and sponsored many of the classes they had. I remember attending (still have the handouts in the binders) many talks that mentioned Linux, used it for part of the demos, and either made note of it's increasing functionality and popularity, or gave hints that Linux based products were being developed by nearly all the big proprietary RTOS vendors, and by 2003 - 2004 Linux was Everywhere at ESC.
I first ran Linux in 2001 after some kind soul gave me a boxed copy (with manuals) of Mandrake Linux 8.0 at ESC. My boss and I spent the night installing it on our work laptops with partition magic and boot magic so we could play around with some of the demo code from class.
There was also lots of talk at that time about could you use GCC as a replacement for Green Hills etc. and we played around trying to get our ECU software and proprietary OS to build under GCC dreaming of the cost savings we would realize once we got it to work!
Good Times!
Lets say that your valve is from a 1987 Ford and it is for idle speed control. those valves run at 10 Hz so your best case 1 Msec response time will give you 1% increments from 0% - 100%. If you had a requirement to have better than 1% resolution, you couldn't get it. If your response time varied by 1 Msec as well, you couldn't hold better than 3% on the valve position giving your engine a roughly + - 2% window on the the idle speed. This in itself would be an objectionable level of idle stability on the slowest valve ever used for idle speed control.
But you might have a hardware PWM to help you gain accurate control of the valve by just loading a value to a register and calling it a day because the hardware timer will take care of giving you an accurate frequency and duty cycle, what could go wrong then?
The same issue would still manifest itself perhaps even to a greater extent because the PID calculations that you would be using for the speed control loop on your idle speed need to be taken at very exact intervals to get a good cause and effect relationship out of those calculations. At a 600 RPM idle on your 5.0L V-8 you will have 40 combustion events per second, and the PID would likely be calculated at the most every 50 mSec to get any kind of stability out of it. If your scheduling and task swapping caused that calculation time to vary + - 1 mSec that would also create a ~4% error in the PID output because it might have really measured the change over 49 - 51 mSec and now you not only have an invisible (to the software) amount of jitter to deal with you run the real risk of having 1 or 2 or 3 of the 25 mSec combustion events being used in your current idle speed calculation. If you got unlucky and just missed the 2nd combustion event in your calculation, you only have half of the "power in" you expected when you calculate what effect your valve position is having on your engine speed, your PID may say "hey, we need the valve open more!" so that calculation will drive the valve too far open. The next time the PID calculates it is likely to see the effects of 3 combustion events which will be driven by a valve that is now too far open and overcompensate again by closing the valve too much. The resulting engine speed will become very unstable.
You can see where you might want to be able to run that calculation faster say on a 10 mSec schedule. Now your 1 mSec jitter will result in a 20% variability in the time used in the PID calculation sometimes, so while you can run the calculation more often, and filter the output to the valve to keep your PID loop from essentially aliasing your combustion events, your increased time variance will somewhat negate any gains you had from running the calculation 5X faster increasing your CPU load (which will increase your 1 mSec response time jitter) and might make your system even harder to tune for a smooth idle.
Another Example:
If you were trying to monitor a 1 khz frequency by accumulating the pulses in a hardware counter and and were reading the result every 100 mSec, and you had 1 mSec jitter on the time you read your 1 mSec pulses. You would have a sample period of 99 - 101 mSec, this would automatically limit you to 10 hz resolution on your pulses (99 to 101 of them * 10) so your measured speed would best case read out 990 - 1010 hz and your control system would have to live with never knowing if it was really at 990 hz and read the frequency too soon, or it was at 1010 hz and read it a little too late. It would severely limit the control you would have on the process that was generating the pulses.
Hope this helps!
Cheers
Thank You, I was (obviously) not aware that's what was done on EXT2. Is that also done with any of the other Linux filesystems?
It seems logical that leaving the extra space between files would help reduce fragmentation as the disk becomes full as well, because the more room you leave between files, the better chance you have of being able to fit a new file somewhere in one piece. You could write it near the end of the extra space to allow both files to still be modified without having to break the files into pieces. Even having to Dollie up a file into parts to fill space could be written on sequential tracks so the heads don't have to seek to read the file, just skip past the first file as it spins by.
It makes me wonder if it would be worth it to have a filesystem that was designed around the huge sizes of HDD's available today that would make an effort to write files as continuous blocks of data, and perhaps allow you to somehow define the approximate size of the file to automatically leave space around and even in the middle of it to be able to modify it and still minimize fragmentation. Something static like a PDF or image file could be set to not need this extra space, but if you were working on a large document you could do a "save as" or the first save the program could give you the option of defining how much space to set aside for the file, and create bins to store your documents in that would help to keep them sequential so you just skip a few deleted tracks instead of having to reposition the heads. That would help speeding up future reads and writes, and make it much easier to figure out if a particular file could go into any used space that is ready to be overwritten by knowing if what you are saving is likely to ever need more space than where you are storing it. Perhaps your image and document directories could be created in 200 MByte chunks to help speed up accessing the directories while previewing documents or flipping through your pictures as well.
I had some audio and video programs I used to use on my older PC's that would allow you to tell the program in advance how long of a recording you were going to make so that they could prepare a space to be able to write them as continuous files. On my older PC's it made the a huge difference in the quality of recording I was able to make without the occasional stutter, and the responsiveness of the system especially while recording video. Once the drive became close to full, it might take the program 5 - 10 minutes to prepare the disk buffer, but it would not have ever had the horsepower to do it while recording.
I remember the last XP computer I had at work. The hibernation and pagefile became very badly fragmented, and by turning them off, deleting them, defragmenting the hard drive, and forcing them to be a certain size when I recreated them, the computer was much more responsive when it started having to swap, and it cut the time to hibernation down from 3 - 4 minutes down to 20 - 30 seconds.
Perhaps it's something the drive firmware could also do, but I think a little guidance from a competent user and some smarter software could help speed up file access times through the OS as well.
I'd bet that they have gotten much faster as a result of the ever increasing density of the platters as well. With the higher density drives putting bits past the heads twice as fast every time the density doubles, the additional ~40% increase in RPM is likely becoming less important, and for most people it's a better investment increasing the capacity.