h a l f b a k e r y"Look on my works, ye Mighty, and despair!"
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Because of the self-clocking modulation schemes used on CD-ROM and hard disk drives, it is possible to read data at a very wide range of speeds (analyzing the data pattern will tell the drive how fast it needs to subdivide the incoming data into bits). On most if not all systems I've seen, though, attempting
to access a drive which has 'spun down' will force the drive to return to full speed before any data may be read.
I would suggest that allowing reading to commence as soon as the drive had reached 1/10 speed would in many cases substantially reduce the latency time imposed by drive startup, especially in applications which require small amounts of data (it's not uncommon to wait a few seconds for a drive to spin up so it can spend 0.1 seconds reading data; adding the ability to read data at 1/10 speed might allow a drive to complete such reads faster than a drive without such feature could even begin them.
As a further enhancement to this idea, drives which are "somewhat idle" could be left running at a fraction of normal speed. This would produce much less wear than full-speed operation, but still allow for semi-fast immediate access.
[link]
|
|
"...still allow for semi-fast immediate access."
While what? The system boots up? |
|
|
Or are you talking about a laptop that allows it's drive to 'rest' for power saving? In which case one could just adding more cache to buffer data until the drive spins up. |
|
|
I am talking about times the drive is idle while the system is otherwise up and running. And adding a cache will only help if the system happens to have the appropriate data in it when needed. |
|
|
Currently, if the system is running with the hard disk or CD powered down, accessing even the tiniest bit of data 'unexpectedly'. As a simple example, consider a paint program with a thousand plug-ins totalling 100 megs. Although it would be possible to pre-load all the plug-ins, this would use 100 megs of RAM to hold many objects that would never be used at all. Given the comparatively small size of the objects (100K or so) loading the objects on-demand from a hard drive which provided nearly-immediate 1/10-speed or a CD-ROM that provided nearly-immediate "single speed" access would allow the objects to be loaded in under a second. |
|
|
BTW, the notion that slower, but immediate data transfer is sometimes better than faster data transfer with a longer setup time is also applicable to modem connections. Things like credit card terminals use 2400 baud not because 14K4 or faster modems would cost too much, but because they take so much longer to connect that a 2400 baud modem could complete the transaction before a 14K4 modem even connected. |
|
|
"Ready?""Set?""No, wait!""Shucks."
My gut tells me this would play havoc with firmware's routine calls. I'm only guessing. |
|
|
Courtesy of Western Digital Tech Support: |
|
|
Spindle Start Time
- From Power-on to Drive Ready* = 9.0s average
- From Power-on to Rotational Speed = 7.0s average |
|
|
which is longer than I would have suspected (this is a 20GB drive going to 7200 RPM). |
|
|
I'm good with the notion, I'm just trying to justify (to myself) the underlying infrastructure of what you're proposing. It seems like an awful lot of work for very little return. You're saving yourself a few seconds (max) in exchange for $xx added to the cost of all future laptops. |
|
|
croissant for saving me 7 seconds when I access my mail. My home pc has 2 hard drives. One little one that came with it and stores the OS and most apps and a big one for lots of data. The big one goes to sleep quite often and takes somewher between 5 and 10 seconds to spin up before it can access the data. |
|
|
It does look like an implementation nightmare, though, unless you implement the sleep mode inside the hard drive itself and forget all these silly system calls. |
|
|
//It does look like an implementation nightmare, though, unless you implement the sleep mode inside the hard drive itself and forget all these silly system calls.// |
|
|
I don't see why. Currently, what happens is that the system asks the drive to retrieve some data, and until the drive has spun up it simply keeps saying "not yet". The system shouldn't generally care whether the drive is at full speed when it starts returning data; the only place there might be trouble is that streaming audio or video might start to play back before the drive is running fast enough to stream it without hiccups. Many applications of streaming audio/video, however, will be satisfied with data rates which are a fraction of what most CD-ROM or hard drives can produce. |
|
|
Another way of doing it for a CD is to only spin the thing up to a speed necessary for the job. For a game, where it's got to keep loading stuff from the CD for new areas, run at 56x or whatever; for the tiny 'Ok, the CD is in the drive' copy protection, run it up to 1x. My home system has a 56x drive that sounds like a jet taking off and takes up to 20 seconds to get it's shit together, long enough for it to realize that A) the CD is in the drive and B) all the game data is on the HD, so it doesn't need to run, and shut itself off again. This would be great for it. |
|
|
My solution to everything. "Put a spring in it!" The hard drive/CD-ROM drive would take its normal long period of time to start up at first, because the spring would be wound by the motor and then the drive would turn. But when it was time to go to sleep, the spring would continue to wind until it was tight. Then when it was time to wake up, the spring would power the drive and the motor would catch up. Think of it like this. The center of the spiral spring would turn the drive, while the other end of the spring would be connected to a barrel which would be turned by the motor. The hard drive spindle would be connected to a governor that would regulate it at 10,000 RPM. |
|
|
sweet jesus, this is genius. |
|
|
I definitely see the need for this device. reducing HD startup latency means you can put the HD to sleep more, saving power. |
|
|
The only half-baked thing about it is gaining access to a the firmware necessary to implement it. Can you patch a hard disk's firmware in the field? |
|
|
//The only half-baked thing about it is gaining access to a the firmware necessary to implement it. Can you patch a hard disk's firmware in the field?// |
|
|
It would require hardware changes, not just firmware, and the drive would be limitted to read-only access until the drive speed stabilized (if the data extraction hardware misjudges the drive speed while reading, the block will generate a bad read and automatic retry; if the speed is misjudged on writing, the data put on the disk may not be readable). |
|
|
On the other hand, it should be noted that this really wouldn't be a problem in most cases; data to be written could be cached immediately and the computer could do other things while the data sat in the cache pending disk spin-up. |
|
| |