I worked in IBM's hardware division for over a decade before I (voluntarily) left, so I know what it's like there.
The problem isn't hardware, there's plenty of money there, just ask Intel, Broadcomm, or TI.
IBM's problem is IBM. Look at the SEC 10K filings for IBM and you'll see that IBM has the highest SG&A expenses (sales, general, and administrative) of any tech company, and has had that for 40 years. That means that IBM's legendary internal bureaucracy and management wastes far more cash than anybody else.
When you look at the SG&A you can see why IBM's present strategy is almost forced on it. Since their internal structure burns cash at a terrific rate they need to find lower risk, lower expense projects. That pretty much means software where you don't need to invest as much money in infrastructure (semiconductor fabs run $3B+) and where a dumb decision (an upper level IBM management specialty -- the PPC615 would be a classic study in mismanagement if they'd ever admit details about the development, but I saw it firsthand) doesn't cost as much. And when you can replace expensive US workers with off-shored workers you lower expenses still more.
It's been "not news" now for at least 20 years. Tsvidis did significant work on subthreshold FETs for neural networks back in the 80s and early 90s. Subthreshold design isn't common, but it's by no means a new field.
Subthreshold has its place, but it's not a pleasant place to work. Mismatch between transistors is about 4x higher, gate leakage is a huge factor below 130nm, the models you get from your foundry aren't reliable or accurate, etc.
I make subthreshold circuits all the time when I need bandwidth and have no headroom (hello 32nm, how unpleasant to meet you when doing analog design!). But I'm not doing low power subthreshold design, rather it's for very, very, high speed analog signal processing designs.
You guys are somewhat right. Bits ARE written to disk as 1's and 0's logially, but as +1 and -1 in a magnetic sense since the direction switches as you go over each magnetic pole. Note that those signals interfere and destroy each other's signal if they get too close, a phenomenon known as high frequency zeros in the business -- write a 101010 pattern to the disk and if you put those bits too close together you get 000000 back out when you read it.
The UBD (user bit density) is the number of bits stored in an area of 50% of the width of an isolated pulse.
Old drives (pre-'96 or so) used peak detectors to find patterns. There we used high frequency "boost" or pulse slimming to read 1s and 0s and get around the high frequency zeros problem, but the UBD was limited to less than 1.
About '95 or so IBM introduced a much more complicated technology called PRML, for Partial Response, Maximum Likelihood detectors. These use intersymbol interference in a controlled way using things like Viterbi detectors and even more complicated backends. This more sophisticated technology allows drives to get UBDs to above 3+. It's not totally unlike QAM, but most of the details are pretty different. Besides, when I was doing QAM systems the data rate (not the carrier frequency) is much, much lower than it is in a drive, so it was a heck of a lot easier to do.
Oh, and writing exactly what you want to a drive is almost impossible anyway. You remember that PRML stuff? That requires coding, meaning that only certain patterns are allowed (this has to be a DC-neutral system). Further, in the more modern systems parity bits are written to the disk, special radomizers are added to improve coding efficiency and spread the spectrum, etc. You could no more write an arbitrary pattern to the disk than you could use a soldering iron to patch an i7's microcode.
Nobody in the drive industry has built a stand-alone controller for the last 8 years (longer in some cases). These days all the controllers are integrated into SoCs that consist of the controller, the read channel, SATA (these days), and memory controller. You can't chain controllers nor easily overwrite the ROM code for them.
Further, the software required to control the read channel part of the SoC is very difficult to write, so even if you could manage to get to the controller knowing what to control to get a proper write is very difficult without documentation.
Good Karmic to me. I had a BIOSTAR TA790GXB motherboard with built-in Radeon HD 3300 graphics I was using as a HTPC. I never could get graphics to be smooth under Jaunty, and DVD playback was a nightmare.
I did an install of Karmic (not an upgrade) and it went cleanly and the graphics worked flawlessly. I'm a strong believer in reinstalls and not upgrades, but considering I started at Slackware 1.0 I've been trained to never believe a company when they claim that an in-place upgrade will be trouble free.
Depends on the cable system. When I had Comcast I had internet only (the company was paying and I used Dish for TV) they put a trap on the signal to block all the channels. Of course, when I had internet related issues they pulled the trap off to fix it. After many calls and before they finally realized they had to replace the cable coming into the house the techs gave up and pulled the trap. Not that I cared...
Your problem is your circuit. You're doing an analog circuit and you're using PWM which means you're driving the fets into and out of saturation, which means that you've just increased your simulation time 10x. Plot the actual solution points sometime and you'll see why full swing circuits like PWM, ADCs, and most synthesizers are CPU hogs. Throw in the fact that you've likely got many different time constants and you're asking for something that takes a long time to simulate.
Depending on whether you're doing this for a class or for business there are workarounds for the time constant issues, but full swing analog is always going to be slow.
Personally, I remember when an 8-MHz machine was considered fast, and 1 MB of memory was da bomb. But then again in those days you cut your own rubylith:-) These days near tapeout I'll keep 4-20 Core7 boxes busy for a couple of months. My bosses don't care too much since hardware and software are cheaper than people and time to market.
If the class teaches the design techniques and not the application, the maybe students can use whatever they want.
You've not taught classes, right? What happens when the student comes in and asks about why he's got a problem with his circuit? If the teacher is familiar with the tool he can generally figure out quickly if it's the tool or the student that's causing the problem. But with 25 different students coming in with 10 different simulators with their own quirks you're way too overloaded.
Then there's the issue of checking the circuit when a student comes in with a "unique" solution that would never work and you've got to figure out what the heck they did and how much partial credit they might get. Tracking down the simulator to see if they got the right answer in that case is a big waste of time.
As to "buy the machine that runs the software" that's what Cadence used to do: you'd get the University license and they'd throw in the Sun workstations for "free." The software was pricey enough that throwing in the hardware was an afterthought and it removed many of the support issues. Now that Cadence runs under Red Hat, though, it's a different story. But it's a still royal pain trying to figure out exactly what rev and what patches you need for the exact version of Cadence you've got since Cadence is pretty touchy about RH versions.
SPICE isn't perfect, but it is perfectly workable. HSPICE is better at converging, and Spectre better yet. None of them are particularly "brittle." That usually comes because you've extracted too much reality from your circuit (ideal elements, etc), or you have bad models with nonlinear 2nd derivatives.
As to the tendency to run to look for the simulator that converges the best, what's the saw about the poor workman? For circuits at the level this poster wants pretty much any of the better known simulators will work fine.
I've taught circuit courses. When it's undergrad I generally use LTSpice since it's cheap (free), relatively unlimited, and pretty robust. That it runs so well under WINE is a bonus since that means I can run it at home on my Ubuntu box. I'm not a big fan of the interface, though, since I was exposed to the various big, full commercial CAD packages before I ever tried it. Still, for undergrad stuff LTSpice is the best of the packages I've seen.
When I've taught grad-level courses (analog integrated circuits) I tend to like to teach with Cadence tools, which is definitely not free but the cost is pretty low for the department. It's nicer to not have to go to multiple environments, and besides, the grad students could use Cadence for their MOSIS designs.
I've done both languages, but I come at them from an analog perspective.
I do ADCs, so there's quite a bit of analog and digital interaction and the digital is fairly good sized but not enormous. From that standpoint, I prefer Verilog since what you get out more closely matches what someone who doesn't do digital 100% of the time expects. There are fewer chances for derived states and things like that.
But back when I first started I got pulled into a digital design group to "save a project" and they taught us VHDL. I can see why VHDL is popular in that for large groups (as ours was) since it has structures that help integrate larger design teams together without the need for as many stylistic rules.
Personally, I'd teach Verilog first. In my experience it's more friendly to a variety of disciplines and better for small groups and projects.
That's not to say that VHDL isn't without its good points, with its stronger typing and other requirements.
Both are good languages and you really shouldn't go too far wrong with either.
There's been a long history of liquid nitrogen cooling. NCR was looking to do it for their mainframes back in the 80s.
Yes, there are problems with condensation (usually attacked with stainless steel connections to keep the heat flow down), and sometimes boards will crack, but rarely packages.
But the worst thing is that the life of your chip is vastly shortened. There are hot electron effects that shift the threshold voltage on the NMOS devices. Hot-e effect arise from the very high electric fields at the drain side of the device, that causes very high speed electrons to be generated, and those will periodically hit the oxide causing permanent degradation via charge trapping.
Hot-e effects are bad because they're not uniform (they're pattern dependent since the time that the circuit spends in a transition is one of the biggest factors), so you can wind up altering the timing paths on the chip, and if they become skewed enough, you're screwed.
Yes, hot-e effects are there at room temperature, but the way most folks design chips means that under worst case conditions you've got a life of 10 years. And running at high temperatures actually lowers hot-e effects (but don't get me started on metal migration!). But running at full supply in an LN2 immersion system will typically take your 10-year lifetime down to much less than 3 years.
Not really. I work on these things. Drive manufacturers maintain many tracks of spare blocks. When a TA or other error occurs we use an escalating set of recovery techniques -- I've seen as many as 20 strategies applied to a drive. If the recovery was successful, and generally it is given the RS and other ECC used, the sector is remapped to one of the spare tracks and the bad sector is marked as not to be used.
And this is why I tell folks that if they start to see read errors for any reason, it's time to buy a new drive since yours is not long for this world.
They're not so freaky. They blow all the time. We had ours burn out spectacularly two years ago. And when I was at NASA we managed to do a power spike that took out a half dozen relay stations from Ohio to Tennessee with a rather spectacular failure in a wind tunnel, not to mention what it did to our own facilities.
In modern HDDs when a bad sector is detected for whatever reason (TA, etc) the drive heads into recovery mode and generally tries a set of increasingly aggressive recovery methods until it manages to recover the data. At that point, the sector is silently remapped into one of the spare tracks. The data in the original sector is still there (we managed to read it once, right?), but you'll never see it nor be able to erase it.
This is one of the reasons I tell my friends that if you EVER see a bad sector message you know your disk is not long for this world. If you've managed to burn through all the spare tracks your lifetime is in the toilet.
No, you can pick up the old signals even in new drives. It's more complicated now, since you need to know the encoding schemes and ECC strategy (there are some wild ones out there now with fancy LDPC structures and the like), the fact that media noise is actually the dominant factor in modern encoding schemes, and tracks are pretty tight. But if you're willing to go the distance you can pull stuff off. And if you're the NSA or a drive manufacturer you can go great guns and use a interferometer controlled spin stand to read the off track footprint from the slight servo misalignment of the head and track when you did the erase. Not cheap, not quick, but it'll usually work. We do stuff like that to make sure that overwriting performance is "good enough" to dominate the signal, but you can still see the old signal down in the noise if you need it badly enough.
Yeah, I work on the things. So what's your point? Nothing's changed so badly that a single write can wipe out the data completely unless you're very (un)lucky if you want it badly enough. You still have to overwrite a fair number of times to really wipe your disk.
And before you CS types go all whacko on best theoretical patterns for erasure, we encode your bits ourselves into our own codespaces and usually use sequencers to scramble the bits to whiten out the frequency bands for more typical input patterns, so without knowing what we're doing your efforts to optimize erasure are dubious at best.
It's unlikely that IBM can invalidate the agreement without direct action against IBM by MS, MS fraud in the agreement, etc. Most cross licensing agreements are written that way. So IBM can't lean on MS unless MS comes after IBM, which is a highly unlikely situation given IBM's attitude to IP, which SCO found out to its dismay.
Since you asked (and since I design the things), you gain a lot with better ECC codes, and those codes (which are multi-bit optimized) prefer bigger sectors on which to operate. Further, there are format overheads to sectors. Each sector is preceeded by a small (4-32 byte) training field to allow each sector to get good timing and gain adjustments, as well as to servo correctly over the data. And there is some "slop" in where you can drop the read/write gate signal that you have to allow for since the controllers are *much* slower than the read channels (controllers typically run less than 800 MHz, while channels typically can run up to almost 3 GHz).
How hard do we push density now? How about splitting even today's sectors around servo zones to squeeze out more bytes?
So yes, 4K sectors will help efficiency in many ways. You can use better ECC algorithms to help increase density (bigger sectors allow more correction to be done, which means more error recovery). There will be some physical recovery of space, too, on the hard drives.
Yes, Intel is lying through its teeth. Pre-2001 there were 500K electrical engineering jobs in this country. Now there are 400K. A growth industry, hungry for new talent? HARDLY! The only place that's growing is hiring outside the US.
Why would they keep the price for so high for so long?
Internal politics. You had different groups fighting for different products. The uDrive group had to try and make up all the NRE on early adopters and whatnot. That's not a strategy for market dominance and for quick adoption. Most companies selling into the consumer market know to take a hit early on so that they can get the volumes up to where they'll make a profit, but IBM isn't into consumer electronics directly and didn't know how to structure the business to compete well there. For examples, see LexMark and the sales after the Hitachi buyout. No disrespect, but many groups in IBM have attempted the consumer market only to be slammed by the corporate structure and costs.
(Yes, I worked there and even worked on the uDrive and several other of their attempted forays into consumer electronics. IBM will be an indirect supplier of tech for consumers (and a durn good one), but doing consumer electronics isn't something that's in the cards without a massive reorganization that'll never happen.)
Re:"Orthogonal Frequency Division Multiplexing"
on
Is 3G Irrelevant?
·
· Score: 2, Insightful
OFDM? Dude, it's out there already. Check out the specs for 802.11g. It's not rocket science and similar signal processing has been used for a long time in other environments.
I worked at IBM in the hardware area, not software, but I the attitude was the same. I had to have training on how to use the GNU stuff, how I had to be careful mixing in the software, etc. And that was just if you wanted to run a Linux box! If you were doing software the rules were even more strict and you often required heavy duty review if you'd even been "exposed" to GPL source. So I can say with pretty good certainty that IBM *management* was very, very careful not to allow violations of NDA, the GPL, or any other agreement we had to make. There may be instances where something occured, but IBM certainly went to every length to keep anything like that from happening, had policies in place to prevent it, and actively discouraged the possibility of events as described happening.
From my experience, I can say that we were *very* *very* careful not to cross Chinese firewalls and to respect very clearly IP boundaries. We had folks working on the same technology with different customers that I was *never* allowed to talk to even in the cafeteria. We had patent reviews to make sure that we weren't stomping on other folks' patents when we shipped products. And the only time someone tried to come after us for hitting their patent we found prior art for their patent, then they wound up paying a nice hefty sum because the IBM lawyers came to attention to their products -- do you have any clue how much money IBM makes off patents? It's awesome!
Yes, they do explain the key and why it is necessary in the documentation, which is almost required since you need the key to get everything set up. The setup program tells you how to figure out the default key and when you run the configuration program for the router you're clearly shown how to set a new key if you want to. They even tell you how to set 64 vs. 128 bit encryption!
All in all, they're nice units for relatively nontechnical folks in my experience.
You haven't tried an Orinoco setup then. They ship by default with WEP turned on and with the latest drivers they avoid the weak keys problems of WEP. A very nice setup, even out of the box, for your average user.
And in the home? Try networking the second floor of your home with the basement and watch the data rate fall. 5 GHz does really nasty things to signals in an obstacle rich environment: if you're not in the same room you'll rarely do better (and many times worse than) 11b.
Most of the good stuff in 11a is migrating down to 11g like OFDM and cell handoff. Yes, there are all those nasty 2.4 GHz phones and whatnot, but realitically speaking they're nothing compared to a few floors of building materials' effects on 11a.
My conclusion? Hey, it's your money, but they guys in the next aisle who design the RF stuff and me are sticking with 11b until 11g starts going, at least at home. The 11a stuff in cube farm works fine if you've got enough repeaters and a high enough ceiling.
Nice in theory, but it won't fly. Two arms means replicating some of the most expesive parts of the drive all over again. Double electronics (servo, preamp, channel) because you wouldn't get reaonable SNR trying to share them, more flex cables, more of those nasty suspension systems, arm motors, etc. You could share the backend of the uprocessor (although it'd require a serious upgrade of the processors we use now since none of them have the umph to do a read and servo calcs at the same time), buffer RAM (although you'd need an increase in that, too, to handle two streams), motor driver, platter, motor, and the controller, but other than that you need to replicate many very expensive parts again. I'd guess you'd increase the cost by 50% or more. The idea's floated around the industry before and prototypes have been built, but in the end the performance boost for the cost wasn't there and no such drive had made it into production.
WD made the bigger buffer because it was cheap. Adding RAM isn't hard and with RAM prices its cheap. Doubling the front end is a nasty, expensive business.
Slashdot Mirror
I worked in IBM's hardware division for over a decade before I (voluntarily) left, so I know what it's like there.
The problem isn't hardware, there's plenty of money there, just ask Intel, Broadcomm, or TI.
IBM's problem is IBM. Look at the SEC 10K filings for IBM and you'll see that IBM has the highest SG&A expenses (sales, general, and administrative) of any tech company, and has had that for 40 years. That means that IBM's legendary internal bureaucracy and management wastes far more cash than anybody else.
When you look at the SG&A you can see why IBM's present strategy is almost forced on it. Since their internal structure burns cash at a terrific rate they need to find lower risk, lower expense projects. That pretty much means software where you don't need to invest as much money in infrastructure (semiconductor fabs run $3B+) and where a dumb decision (an upper level IBM management specialty -- the PPC615 would be a classic study in mismanagement if they'd ever admit details about the development, but I saw it firsthand) doesn't cost as much. And when you can replace expensive US workers with off-shored workers you lower expenses still more.
It's been "not news" now for at least 20 years. Tsvidis did significant work on subthreshold FETs for neural networks back in the 80s and early 90s. Subthreshold design isn't common, but it's by no means a new field.
Subthreshold has its place, but it's not a pleasant place to work. Mismatch between transistors is about 4x higher, gate leakage is a huge factor below 130nm, the models you get from your foundry aren't reliable or accurate, etc.
I make subthreshold circuits all the time when I need bandwidth and have no headroom (hello 32nm, how unpleasant to meet you when doing analog design!). But I'm not doing low power subthreshold design, rather it's for very, very, high speed analog signal processing designs.
You guys are somewhat right. Bits ARE written to disk as 1's and 0's logially, but as +1 and -1 in a magnetic sense since the direction switches as you go over each magnetic pole. Note that those signals interfere and destroy each other's signal if they get too close, a phenomenon known as high frequency zeros in the business -- write a 101010 pattern to the disk and if you put those bits too close together you get 000000 back out when you read it.
The UBD (user bit density) is the number of bits stored in an area of 50% of the width of an isolated pulse.
Old drives (pre-'96 or so) used peak detectors to find patterns. There we used high frequency "boost" or pulse slimming to read 1s and 0s and get around the high frequency zeros problem, but the UBD was limited to less than 1.
About '95 or so IBM introduced a much more complicated technology called PRML, for Partial Response, Maximum Likelihood detectors. These use intersymbol interference in a controlled way using things like Viterbi detectors and even more complicated backends. This more sophisticated technology allows drives to get UBDs to above 3+. It's not totally unlike QAM, but most of the details are pretty different. Besides, when I was doing QAM systems the data rate (not the carrier frequency) is much, much lower than it is in a drive, so it was a heck of a lot easier to do.
Oh, and writing exactly what you want to a drive is almost impossible anyway. You remember that PRML stuff? That requires coding, meaning that only certain patterns are allowed (this has to be a DC-neutral system). Further, in the more modern systems parity bits are written to the disk, special radomizers are added to improve coding efficiency and spread the spectrum, etc. You could no more write an arbitrary pattern to the disk than you could use a soldering iron to patch an i7's microcode.
Nobody in the drive industry has built a stand-alone controller for the last 8 years (longer in some cases). These days all the controllers are integrated into SoCs that consist of the controller, the read channel, SATA (these days), and memory controller. You can't chain controllers nor easily overwrite the ROM code for them.
Further, the software required to control the read channel part of the SoC is very difficult to write, so even if you could manage to get to the controller knowing what to control to get a proper write is very difficult without documentation.
Good Karmic to me. I had a BIOSTAR TA790GXB motherboard with built-in Radeon HD 3300 graphics I was using as a HTPC. I never could get graphics to be smooth under Jaunty, and DVD playback was a nightmare.
I did an install of Karmic (not an upgrade) and it went cleanly and the graphics worked flawlessly. I'm a strong believer in reinstalls and not upgrades, but considering I started at Slackware 1.0 I've been trained to never believe a company when they claim that an in-place upgrade will be trouble free.
Depends on the cable system. When I had Comcast I had internet only (the company was paying and I used Dish for TV) they put a trap on the signal to block all the channels. Of course, when I had internet related issues they pulled the trap off to fix it. After many calls and before they finally realized they had to replace the cable coming into the house the techs gave up and pulled the trap. Not that I cared...
Your problem is your circuit. You're doing an analog circuit and you're using PWM which means you're driving the fets into and out of saturation, which means that you've just increased your simulation time 10x. Plot the actual solution points sometime and you'll see why full swing circuits like PWM, ADCs, and most synthesizers are CPU hogs. Throw in the fact that you've likely got many different time constants and you're asking for something that takes a long time to simulate.
Depending on whether you're doing this for a class or for business there are workarounds for the time constant issues, but full swing analog is always going to be slow.
Personally, I remember when an 8-MHz machine was considered fast, and 1 MB of memory was da bomb. But then again in those days you cut your own rubylith :-) These days near tapeout I'll keep 4-20 Core7 boxes busy for a couple of months. My bosses don't care too much since hardware and software are cheaper than people and time to market.
You've not taught classes, right? What happens when the student comes in and asks about why he's got a problem with his circuit? If the teacher is familiar with the tool he can generally figure out quickly if it's the tool or the student that's causing the problem. But with 25 different students coming in with 10 different simulators with their own quirks you're way too overloaded.
Then there's the issue of checking the circuit when a student comes in with a "unique" solution that would never work and you've got to figure out what the heck they did and how much partial credit they might get. Tracking down the simulator to see if they got the right answer in that case is a big waste of time.
As to "buy the machine that runs the software" that's what Cadence used to do: you'd get the University license and they'd throw in the Sun workstations for "free." The software was pricey enough that throwing in the hardware was an afterthought and it removed many of the support issues. Now that Cadence runs under Red Hat, though, it's a different story. But it's a still royal pain trying to figure out exactly what rev and what patches you need for the exact version of Cadence you've got since Cadence is pretty touchy about RH versions.
SPICE isn't perfect, but it is perfectly workable. HSPICE is better at converging, and Spectre better yet. None of them are particularly "brittle." That usually comes because you've extracted too much reality from your circuit (ideal elements, etc), or you have bad models with nonlinear 2nd derivatives.
As to the tendency to run to look for the simulator that converges the best, what's the saw about the poor workman? For circuits at the level this poster wants pretty much any of the better known simulators will work fine.
I've taught circuit courses. When it's undergrad I generally use LTSpice since it's cheap (free), relatively unlimited, and pretty robust. That it runs so well under WINE is a bonus since that means I can run it at home on my Ubuntu box. I'm not a big fan of the interface, though, since I was exposed to the various big, full commercial CAD packages before I ever tried it. Still, for undergrad stuff LTSpice is the best of the packages I've seen.
When I've taught grad-level courses (analog integrated circuits) I tend to like to teach with Cadence tools, which is definitely not free but the cost is pretty low for the department. It's nicer to not have to go to multiple environments, and besides, the grad students could use Cadence for their MOSIS designs.
I've done both languages, but I come at them from an analog perspective.
I do ADCs, so there's quite a bit of analog and digital interaction and the digital is fairly good sized but not enormous. From that standpoint, I prefer Verilog since what you get out more closely matches what someone who doesn't do digital 100% of the time expects. There are fewer chances for derived states and things like that.
But back when I first started I got pulled into a digital design group to "save a project" and they taught us VHDL. I can see why VHDL is popular in that for large groups (as ours was) since it has structures that help integrate larger design teams together without the need for as many stylistic rules.
Personally, I'd teach Verilog first. In my experience it's more friendly to a variety of disciplines and better for small groups and projects.
That's not to say that VHDL isn't without its good points, with its stronger typing and other requirements.
Both are good languages and you really shouldn't go too far wrong with either.
There's been a long history of liquid nitrogen cooling. NCR was looking to do it for their mainframes back in the 80s.
Yes, there are problems with condensation (usually attacked with stainless steel connections to keep the heat flow down), and sometimes boards will crack, but rarely packages.
But the worst thing is that the life of your chip is vastly shortened. There are hot electron effects that shift the threshold voltage on the NMOS devices. Hot-e effect arise from the very high electric fields at the drain side of the device, that causes very high speed electrons to be generated, and those will periodically hit the oxide causing permanent degradation via charge trapping.
Hot-e effects are bad because they're not uniform (they're pattern dependent since the time that the circuit spends in a transition is one of the biggest factors), so you can wind up altering the timing paths on the chip, and if they become skewed enough, you're screwed.
Yes, hot-e effects are there at room temperature, but the way most folks design chips means that under worst case conditions you've got a life of 10 years. And running at high temperatures actually lowers hot-e effects (but don't get me started on metal migration!). But running at full supply in an LN2 immersion system will typically take your 10-year lifetime down to much less than 3 years.
Not really. I work on these things. Drive manufacturers maintain many tracks of spare blocks. When a TA or other error occurs we use an escalating set of recovery techniques -- I've seen as many as 20 strategies applied to a drive. If the recovery was successful, and generally it is given the RS and other ECC used, the sector is remapped to one of the spare tracks and the bad sector is marked as not to be used.
And this is why I tell folks that if they start to see read errors for any reason, it's time to buy a new drive since yours is not long for this world.
They're not so freaky. They blow all the time. We had ours burn out spectacularly two years ago. And when I was at NASA we managed to do a power spike that took out a half dozen relay stations from Ohio to Tennessee with a rather spectacular failure in a wind tunnel, not to mention what it did to our own facilities.
In modern HDDs when a bad sector is detected for whatever reason (TA, etc) the drive heads into recovery mode and generally tries a set of increasingly aggressive recovery methods until it manages to recover the data. At that point, the sector is silently remapped into one of the spare tracks. The data in the original sector is still there (we managed to read it once, right?), but you'll never see it nor be able to erase it.
This is one of the reasons I tell my friends that if you EVER see a bad sector message you know your disk is not long for this world. If you've managed to burn through all the spare tracks your lifetime is in the toilet.
No, you can pick up the old signals even in new drives. It's more complicated now, since you need to know the encoding schemes and ECC strategy (there are some wild ones out there now with fancy LDPC structures and the like), the fact that media noise is actually the dominant factor in modern encoding schemes, and tracks are pretty tight. But if you're willing to go the distance you can pull stuff off. And if you're the NSA or a drive manufacturer you can go great guns and use a interferometer controlled spin stand to read the off track footprint from the slight servo misalignment of the head and track when you did the erase. Not cheap, not quick, but it'll usually work. We do stuff like that to make sure that overwriting performance is "good enough" to dominate the signal, but you can still see the old signal down in the noise if you need it badly enough.
Yeah, I work on the things. So what's your point? Nothing's changed so badly that a single write can wipe out the data completely unless you're very (un)lucky if you want it badly enough. You still have to overwrite a fair number of times to really wipe your disk.
And before you CS types go all whacko on best theoretical patterns for erasure, we encode your bits ourselves into our own codespaces and usually use sequencers to scramble the bits to whiten out the frequency bands for more typical input patterns, so without knowing what we're doing your efforts to optimize erasure are dubious at best.
It's unlikely that IBM can invalidate the agreement without direct action against IBM by MS, MS fraud in the agreement, etc. Most cross licensing agreements are written that way. So IBM can't lean on MS unless MS comes after IBM, which is a highly unlikely situation given IBM's attitude to IP, which SCO found out to its dismay.
Since you asked (and since I design the things), you gain a lot with better ECC codes, and those codes (which are multi-bit optimized) prefer bigger sectors on which to operate. Further, there are format overheads to sectors. Each sector is preceeded by a small (4-32 byte) training field to allow each sector to get good timing and gain adjustments, as well as to servo correctly over the data. And there is some "slop" in where you can drop the read/write gate signal that you have to allow for since the controllers are *much* slower than the read channels (controllers typically run less than 800 MHz, while channels typically can run up to almost 3 GHz).
How hard do we push density now? How about splitting even today's sectors around servo zones to squeeze out more bytes?
So yes, 4K sectors will help efficiency in many ways. You can use better ECC algorithms to help increase density (bigger sectors allow more correction to be done, which means more error recovery). There will be some physical recovery of space, too, on the hard drives.
Yes, Intel is lying through its teeth. Pre-2001 there were 500K electrical engineering jobs in this country. Now there are 400K. A growth industry, hungry for new talent? HARDLY! The only place that's growing is hiring outside the US.
Internal politics. You had different groups fighting for different products. The uDrive group had to try and make up all the NRE on early adopters and whatnot. That's not a strategy for market dominance and for quick adoption. Most companies selling into the consumer market know to take a hit early on so that they can get the volumes up to where they'll make a profit, but IBM isn't into consumer electronics directly and didn't know how to structure the business to compete well there. For examples, see LexMark and the sales after the Hitachi buyout. No disrespect, but many groups in IBM have attempted the consumer market only to be slammed by the corporate structure and costs.
(Yes, I worked there and even worked on the uDrive and several other of their attempted forays into consumer electronics. IBM will be an indirect supplier of tech for consumers (and a durn good one), but doing consumer electronics isn't something that's in the cards without a massive reorganization that'll never happen.)
OFDM? Dude, it's out there already. Check out the specs for 802.11g. It's not rocket science and similar signal processing has been used for a long time in other environments.
I worked at IBM in the hardware area, not software, but I the attitude was the same. I had to have training on how to use the GNU stuff, how I had to be careful mixing in the software, etc. And that was just if you wanted to run a Linux box! If you were doing software the rules were even more strict and you often required heavy duty review if you'd even been "exposed" to GPL source. So I can say with pretty good certainty that IBM *management* was very, very careful not to allow violations of NDA, the GPL, or any other agreement we had to make. There may be instances where something occured, but IBM certainly went to every length to keep anything like that from happening, had policies in place to prevent it, and actively discouraged the possibility of events as described happening.
From my experience, I can say that we were *very* *very* careful not to cross Chinese firewalls and to respect very clearly IP boundaries. We had folks working on the same technology with different customers that I was *never* allowed to talk to even in the cafeteria. We had patent reviews to make sure that we weren't stomping on other folks' patents when we shipped products. And the only time someone tried to come after us for hitting their patent we found prior art for their patent, then they wound up paying a nice hefty sum because the IBM lawyers came to attention to their products -- do you have any clue how much money IBM makes off patents? It's awesome!
Yes, they do explain the key and why it is necessary in the documentation, which is almost required since you need the key to get everything set up. The setup program tells you how to figure out the default key and when you run the configuration program for the router you're clearly shown how to set a new key if you want to. They even tell you how to set 64 vs. 128 bit encryption!
All in all, they're nice units for relatively nontechnical folks in my experience.
You haven't tried an Orinoco setup then. They ship by default with WEP turned on and with the latest drivers they avoid the weak keys problems of WEP. A very nice setup, even out of the box, for your average user.
And in the home? Try networking the second floor of your home with the basement and watch the data rate fall. 5 GHz does really nasty things to signals in an obstacle rich environment: if you're not in the same room you'll rarely do better (and many times worse than) 11b.
Most of the good stuff in 11a is migrating down to 11g like OFDM and cell handoff. Yes, there are all those nasty 2.4 GHz phones and whatnot, but realitically speaking they're nothing compared to a few floors of building materials' effects on 11a.
My conclusion? Hey, it's your money, but they guys in the next aisle who design the RF stuff and me are sticking with 11b until 11g starts going, at least at home. The 11a stuff in cube farm works fine if you've got enough repeaters and a high enough ceiling.
Nice in theory, but it won't fly. Two arms means replicating some of the most expesive parts of the drive all over again. Double electronics (servo, preamp, channel) because you wouldn't get reaonable SNR trying to share them, more flex cables, more of those nasty suspension systems, arm motors, etc. You could share the backend of the uprocessor (although it'd require a serious upgrade of the processors we use now since none of them have the umph to do a read and servo calcs at the same time), buffer RAM (although you'd need an increase in that, too, to handle two streams), motor driver, platter, motor, and the controller, but other than that you need to replicate many very expensive parts again. I'd guess you'd increase the cost by 50% or more. The idea's floated around the industry before and prototypes have been built, but in the end the performance boost for the cost wasn't there and no such drive had made it into production.
WD made the bigger buffer because it was cheap. Adding RAM isn't hard and with RAM prices its cheap. Doubling the front end is a nasty, expensive business.