Collisions became a non-issue the moment low-cost 10BaseT switches came into existance, which was, what, over 15 years ago? Don't bother arguing about collisions, not even my home network uses hubs any more. There are no collisions.
Congestion is a lot easier to handle then people seem to realize. All modern switches have packet buffers. Even the CHEAP switches have a few megabytes of buffer. GiGE switches have flow control on top of that.
Buffering and flow control does NOT mean that you can just squirt out packets and let things back up. What it does mean is that a large chunk of the problem space has already been solved. If you use the traditional over-build methodology and gang the links in your trunks you might not even have to worry about congestion at all.
For those situations where you do have to worry about congestion you already have multiple feedback mechanisms available to you to control throttling. Even the simplest algorithms can make a huge difference, and that is the key.
There IS a need for the more complex forms of congestion control. But the simpler forms solve 90% of the problem space. In otherwords, there is an incremental solution space to the general problem and the effect of that incremental solution space will not only be ubiquitous network protocols but also very low costs and the ability to incrementally upgrade your infrastructure as you need it rather then have to spend millions up front for an infrastructure to handle your expected needs for the next X years.
Let me give you an example of a simple form of congestion control for a SAN device. Lets say the device can handle 256 simultanious requests and implementations a reservation protocol for those 256 slots. A simple protocol would be for the host wanting to use the device to request N slots. The device assigns it, say, 3 slots. The host then uses those 3 slots to queue up to 3 simultanious requests, and reuses those slots as long as it needs to or until the device tells it use fewer. Lets say any given request cannot have a payload larger then 8K, just for argument's sake.
Consider the consequences of such a mechanism. For one thing you have immediately put a control on the maximum amount of data that can be backed up in intermediate switches for that device. 3 requests, 8K... approximately 24K. That is a form of congestion control. For another the device has a limited number of slots for parallel operations (256). That is another form of congestion control. The device and/or host can revoke slots. That is another form of congestion control. The device can order which requests it responds to first. That is another form of congestion control.
Starting to get the idea? There are literally an INFINITE number of ways to control congestion, none of them require anything sophisticated at the physical layer. Even without smart switches you have hundreds of software solutions, all easily tunable.
In otherwords the problem is not only solvable, but even partial solutions will give system operators and network managers plenty of knobs they can tune to make their infrastructure work.
What are ethernet's two biggest strengths? Think about it a moment.
It is high speed at a very low cost, and the ubiquitousness of the technology.
It doesn't really matter that the technology is inferior to the numerous very fast low latency solutions available today because all of those solutions are also very high-cost, low-volume solutions relative to ethernet, and have no ability to be incrementally upgraded. It doesn't matter that there are congestion issues when pushing a packet-switched technology to its limit, because anyone who has lived with this stuff for the last few decades knows that you simply overbuild it for your needs and all those problems disappear. It doesn't matter that the price point is GiGE because the technology has proven over and over again that the price point moves very quickly with adoption. The price point will soon be 10GiGE, and after that 100GiGE. It is unarguable. It doesn't matter that ethernet traditionally has higher latencies then currently existing higher-cost solutions. Latency has never been a show stopper for anyone except the super-computing dweebs.
The price of hardware has dropped around the ears of the higher cost solutions to the point where only a very small application space can actually gain an advantage using them. It will only get worse over time.
So even though, GiGE isn't quite fast enough to match platter rates on the best disks, let alone transfer rates available from SSDs, it doesn't matter. The low cost and clear future trends for the technology will trump everything. And the people making the decisions have the choice: They can be early adopters of 100GiGE, or choose to spend more of a premium on 10GiGE, but with the flexibility of NOT having to rip up their entire infrastructure. The ability to piecemeal-replace infrastructure is its own trump card.
Hmm. It's really hard to say. Circuit boards are fairly well protected and the metalic contacts and solder joints will be in good shape if the equipment was powered down (they would be corroded if the equipment was powered on, depending on how long). But the electrolytic capacitors are probably in very bad shape. If the electronics have mold on them that means the water wasn't as clean as you might have thought and organic matter got caught up in there. The electrolytics might be unrecoverable meaning the board would be unrecoverable or only work for a short period of time. Similar HDs might work for a short while but don't count on them staying working.
You can try washing the circuit boards carefully in fresh water (someone mentioned distilled water but a Brita filter will work just fine, disolved minerals don't really hurt anything), but then you have to dry it completely and the only way to do that is in a very low humidity environment... for example, place the board in an oven at its lowest setting (~120 degrees F) for at least four hours. Air conditioning also helps on the humidity front but you also need the heat. e.g. using an oven in an air-conditioned room. You would have to be very careful to protect the board from the oven's heating coils since they tend to turn full on and then full off. And even being careful you might still destroy it.
If the circuit board is powered on while still wet any metalic surfaces the water touches will corrode over time and destroy the board. The board might work for a short period of time but then it would just die.
Since the protocol is effectively just a low-speed digital signal... almost a square wave, the keyboard cable will radiate broad-spectrum noise around the 16 KHz band (A PS/2 keyboard clocks at around 10-16 Khz from a quick google lookup).
That frequency might be too low for a ferrite bead to stop but its worth a try anyway. The keyboard cable is going to be too short to act as an Antenna at that frequency but because it is a square wave there are going to be a lot of harmonics. And because the base frequency is so low it could very well be that the noise generated from the computer itself would not interfere so much. So a ferrite bead might actually work.
They could also be measuring HF generated by the keyboard processor or matrix. The keyboard matrix itself is being scanned continuously, probably in the high KHz or MHz range, and those *ARE* long wires running in a matrix. Hitting a key will shortcut portions of the scan and produce discernable frequency spikes. Since the keyboard is constantly scanning it would be possible to resample multiple times to kick down the noise floor before the user lets go of the key.
I don't know any easy way to protect against that short of wrapping the whole keyboard in tinfoil, or typing very quickly. A keyboard designer could simply go with a 4-layer board with power and ground planes on the outside, that would put the scanning traces in a faraday cage.
It could be that other effects are being measured as well. When you type there is always a reaction from the computer, such as burning cpu cycles to process the interrupt as well as a reaction from the application being typed into. I doubt those could be translated into actual key codes though.
Well, once I was low on fuel but wanted to get home without stopping at a gas station, so I slipped into the wind shadow of a large truck (going at around 60 mph) and my MPH went up drastically. I don't remember how much but it was a lot.
Not sure I would recommend it for general purposes, though, since you almost have to be tail-gating the truck and can't really see what is in front of it. And he might get annoyed, but the guy in front of me didn't seem to mind. Make sure nobody is behind *you*, though, as you might have to hit your breaks hard if something goes wrong.
It should be noted that 'ultra capacitor' and 'higher current' don't mesh. All ultra-capacitors that I know of also have high internal resistances (30-100 ohms).
If you short even a small led-acid battery out you can get 200+ amps going through your wires. Oh yah, and the battery can blow up in your face.
Once one of our techs dropped a long screw-driver into a battery box full of led-acid batteries. The screw driver lasted less then a second. There was a bright flash, and that was the end of the screw driver. He never did that again.
If you short an ultra-capacitor out you'd be lucky to get 0.1 amp. It might get a little warm, but that's about as far as it will go, then its charge will run out. There is just no comparison.
Yes, massively folded. Similar technology has been in used for many years to produce multi-Farad 'dime' capacitors, whos surface areas start around the size of a tennis court and go up from there.
These sorts of capacitors have very high capacitances (in the multiples, even tens of Farads) and a 20-50 year life span (or longer depending on how they are built), but also tend to only be able to be charged to fairly low voltages (3v, 5v, etc), and also have fairly high internal resistances (though this might be different for the newer Graphene-based caps), limiting the discharge rate.
This means they won't be replacing batteries any time soon, but the advances we're seeing are pretty cool.
We mostly use these things to run real time clock chips and provide backup power for static ram... i.e. very low current applications.
It isn't the internet that is slow, not really. Three things have a disproportionate effect on users perception of the internet: (1) Web site load times and (2) Horrible packet management by your DSL/Cable modem for outgoing and (3) Massive packet backlogs on the ISP side of the router in the download direction, mainly due to YOUR devices advertising ridiculously huge TCP windows or otherwise not doing any management of the incoming bandwidth at all. Those three issues cover 90% of the problem space and none of them are really the ISP's fault.
* Web sites access all sorts of crap these days, mostly related to ad content. Many also run horrible javascript all over the page which slows the site way down even once the page has been loaded. Ad content sources often present a larger responsiveness issue then the site itself. Using ad site blockers will improve site responsiveness.
* Many home systems these days have more then a few devices accessing the internet. Very few of these devices do any sort of packet management or bandwidth control. The result is that your interactive traffic is not prioritized over all your other traffic.
* Most consumer (read: windows) boxes, and most cable and dsl modems either have no bandwidth management or have only very primitive bandwidth management for uplink data. They might be capable of separating out various types of traffic, such as VOIP, but they usually can't handle more then a few simultaneous connections and then only under very strict conditions. They simply do not have enough memory to buffer more then two or three packet streams.
* Programs like bittorrent will easily blow-out the downlink direction of an ISPs DSLAM or cable provider side router. It is virtually impossible to manage the downlink packet rate with a cable modem, even with the configuration options available. In fact, the many ways people use to mask bittorent traffic ends up making things worse by defeating attempts by ISPs to simply manage the packet stream (verses cutting it off).
None of these issues are really the ISP's fault. People who know what they are doing throw a unix-based (aka linux, bsd) router inbetween their home network and their cable/dsl modem. Simple QOS filtering doesn't do the job, you really need to run a full-blown fair-share sub-scheduler on top of your basic QOS separation and pre-restrict the bandwidth to move all the packet queues onto your router, for both directions. That will take care of the uplink direction at the very least.
Incoming bandwidth is harder to deal with because you often do not have direct control over the devices trying to downlink the data. The best you can do there is create an artificial bandwidth constriction between your unix-based router and the target devices in the incoming direction. This will shift the bulk of the packet backlog away from the ISP's DSLAM/router and onto your router. Your router has enough memory to deal with megabytes of stream backlog if necessary so you can control all incoming bulk data streams while letting all the interactive traffic bypass the queues.
Here's an example: Take a single TCP stream downloading a movie. If the TCP connection is advertising a very large data window, such as a megabyte, then what winds up happening is that a megabyte of data winds up getting backlogged on the ISP-side of your connection as the bandwidth is constricted down to your cable/dsl modem's capabilities. The ISP cannot handle that large a backlog, particularly if you are downlinking several things simultaneously (each with a megabyte of backlog). Traditionally ISPs have used RED or other congestion control algorithms but the plain truth of the matter is that THEY DO NOT WORK VERY WELL FROM THE POINT OF VIEW AND PERCEPTIONS OF THE END USER. It is far better to not have the backlog to deal with in the first place, at least not on the ISP side of the connection.
In anycase, the issue is more due to the many applications trying to use your pipe as if they owned the whole thing then it
I think all flash storage will have to wind up using that sort of model, it is the only way to really quantify the durability of flash-based SSD. In the world of filesystems there are plenty of people working on flash-specific filesystems, but they are so specialized that the result is always very highly restrictive and inflexible. We need to be able to run 'normal' filesystems (ZFS, HAMMER, etc) without having to worry about sector wear.
I got into a huge argument on the FreeBSD groups about the use of a general filesystem over a specifically flash-aware filesystem. I used your very argument, in fact. It is clearly the future but some people are too myopic to see it.
I still see a huge disparity between write bandwidth and total write capability before the flash dies. Hard drives do not have this disparity... you can write to a hard drive at the platter rate 24x7 for years without pause. You can't do that with a flash-based SSD.
Even if replacement time winds up being the same on average, the important thing here is properly quantifying what that time will be regardless of the load placed on the device. That is the only weakness of flash SSD (other then capacity).
This isn't correct. There is infact a drive flush command which all real hard drives support. This command flushes the drive's write cache and does not return until the data is on the physical media. ZFS and HAMMER both use this command, as do numerous other filesystems.
There used be a notion of 'ordered writes', that is the ability to issue several parallel writes but tell the disk the precise order in which they must be committed to the media. As filesystems have gotten better, though, this notion has pretty much been thrown away because it ruined disk performance. What filesystems do now is perform massively parallel non-order-dependant writes (allowing the drive to optimize head movement) and cache flush operations at critical points. Many modern filesystems have this ability.
A cache flush does not prevent new writes from being queued, it simply does not return until all writes already queued have completed. That is exactly the behavior that modern filesystems want.
You clearly haven't read my original posting very carefully because I in fact did mention that laptops were a good fit for SSDs for consumer use. A typical consumer uses the machine resources available to him or her so sparingly that the limited write cycles of a flash device are not an issue for the purposes of driving the market. But the storage requirements for even the typical consumer is changing at a very fast pace.
What you are trying to do is make the blanket statement that a SSD is a drop-in replacement for a hard drive. That isn't even close to being true. I would certainly consider a SSD for my laptop, because I do not use my laptop for write-heavy work and I don't store my entire life on it. A SSD is completely out of the question for any of my other half dozen machines, though.
Similarly, a SSD would not be appropriate for any consumer who puts his or her entire life on their laptop. My parents would be a good example of that. The generation in retirement is already using hundreds of gigabytes. People in their 40's are using hundreds more. People in their 20's and 30's are already hitting, and passing the terrabyte mark. Video, Music, Pictures, Voice Mail. You name it. People these days want access to all their information wherever they are. A piddly little 50G SSD drive does not do the job.
Write-heavy applications are on the rise too. The saving grace for the SSD market is that write-heavy applications are more specialized. For your typical consumer the problem is going to be storage capacity and not write use.
I don't think this is true any more. My parents already use several hundred gigabytes and the number keeps growing. The reason is that your typical consumer these days is using the storage in the same manner we used to use archival tapes... their entire lives are stored on their hard drive now. Not only are their entire lives stored, but they need backups as well (or in the case of Apple products, simply replicating the entire data set on multiple boxes).
In modern day, that means all the pictures you've ever taken with your digital camera, every CD you've ever bought, and in the next few years it is going to be every DVD or on-line video you've ever bought, too (if not already). Think Apple-TV. Think every email, every voice mail, every cell phone pic, EveryTHING.
I already have friends who use TiVO-like devices with terrabyte+ drives and don't delete anything. They want entire seasons of their favorite shows instantly accessible.
This is where consumers are going.
File-systems are also going through changes. Microsoft's little unwinding FIFO is nothing compared to the full history that a filesystem like HAMMER can retain, or using ZFS snapshots semi-permanently. These changes are going to multiply storage use. It isn't because the filesystems are becoming bloated, they aren't. It's because having access to a snapshot of your filesystem at virtually any point in the past is becoming more and more important in the larger scheme of things. Users *desire* that sort of access. For machine management, for undoing damage from viruses or badly written applications, for maintainance, for all sorts of things. Machines only appear to be fragile today because these features haven't yet made it down to typical consumer use. But they will. Very soon, they will.
Don't take manufacturer claims at face value, they never tell the whole story. 50 GBytes/day worth a block I/O operations is not the same as adding 50 GBytes/day in new files or data. It isn't even close.
A typical consumer machine running typical office software, or a game, or a typical laptop being used by a typical consumer might get in under the limit and such a claim might be reasonable in that context. Turn on paging to swap, though, and do any sort of moderate workload and you will blow out that 50 GBytes/day very quickly.
And a production server environment? Forget it. The flash drive will be dead in weeks if you are not very, VERY careful about how you use the drive. I also shudder to think of what a virus could do to a SSD. It would not be difficult to purposefully wreck a drive.
As I have said, and as the Subject line says SSDs have their place in read-heavy production environments, particularly for serving static web content. They have their place, but they are not file-and-forget drop-in replacements for hard drives.
I have high hopes that SSDs will overcome the write limitation. IBM's research is very promising. But current flash technology is crap for writing as far as I am concerned.
Write staging is virtually irrelevant with a modern filesystem. Any log-based, undo-baesd, or recursive-update (zfs) based filesystem has virtually no synchronous writing constraints. HAMMER for example can issue a ridiculous amount of write I/O asynchronously even when it is flushing or fsync()ing.
So there are two things going on: First, the OS is caching the write data and disconnecting it from the application. Second, a modern filesystem is further disconnecting writes by reducing write-write dependancies to a minimum, and allowing non-dependant writes (particularly bulk data) to run out even in the face of other parts of the filesystem needing an occassional write-write dependancy.
What it comes down really is fsync() time. Only databases really need to use fsync() and frankly most of that functionality is well covered by battery or dime-cap-backed static ram. You don't really need much more then a megabyte or two of that sort of ram to absorb nearly all the write latency of the backing store's hard drive.
I would agree that SSDs can take a large chunk out of the high-performance HD market, but only for read-heavy environments. I can already see it solving issues related to hybrid static and dynamic web content serving, for example. But in write-heavy environments the IOPS capabilities of flash becomes irrelevant because any write-heavy environment will also quickly wear the flash device out. That makes its usefulness questionable as a staging medium for things like database commits. It doesn't take much battery-backed (aka dime-cap-backed) static ram to greatly improve commit staging operations on a database, there is no need to use flash there.
Actually that isn't correct. Magnetic media has thermal bleeding and magnetic cells will deteriorate over time. However, many of the issues surrounding magnetic media are directly related to reading and writing, verses just sitting on a shelf, and if you really needed the data you would still be able to recover it many years down the line even after the bearing lubrication turned to mush.
With flash you are dead in the water once a cell dies. There is no way to recover the data. And flash cells will leak whether the flash is in use or not (though flash cells also have issues with adjacent writes). Rewriting a flash cell damages it, so the actual life of the data just sitting on a shelf is going to be all over the map depending on how heavily the flash device was used.
Still, the read-life of a flash cell can in fact be extended considerably if the temperature is kept low. I'm not sure that counts for archival storage (a HD isn't suitable either), but it should count for something.
The usefulness of SSDs is undeniable in small devices, but there isn't much of a point of actually using it as a high performance write-heavy device with the limited life of its flash cells. Any heavy write use will quickly wear the device out, and this has already been proven pretty much with people trying to use them as generic HD replacements on microsoft systems with swap enabled.
The amount of storage is also very tiny compared to a modern hard drive in the same form factor. Combine those two together and the usefulness of SSD for any application that writes a lot of data is going to be severely limited. I don't think I would trust it even as a staging device for database transactions.
Laptops and small devices are the only consumer devices that would have a clear advantage in the use of such storage. Laptops for the solid-state nature of SSDs (not the performance), and consumer devices for the same.
On the flip side, SSDs clearly have a major advantage for serving moderately-sized static or mostly-static data sets. Such data sets are often larger then the 2-16G of main memory a server has. Having 50G of 'fast' mostly-read-only SSD storage would greatly improve the performance of static web servers.
Any mostly-read application of moderate size would benefit from SSDs by reducing the need to cache data in main memory, leaving more memory available for dynamic data sets and operations. One would no longer have to separate static and dynamic web content in heavily loaded sites, for example. The static content could be served out of SSD with very little main memory impact and the same system's horse-power and memory could then be directed to the dynamic content.
I'm hoping the research IBM is doing will yield better non-volatile, high performance solid state storage.
Use your own bank's bill-pay service, if they have one. It's the only safe way to semi-automate the process, and it is best to not allow it to run fully automated. That is require that you at least review the bill and approve it before the bill is allowed to be paid. You have full control over when and how much is paid and to whom, and you can review your checking account balance at the same time to make sure you don't overdraft the account.
The other thing I would recommend is to use a separate checking account to pay your bills with. Do NOT pay your bills directly from an investment account. Ideally you want three accounts:
* Credit card account, preferably with the same bank you have your checking account with.
* Checking account for bill pay and check writing.
* Investment account for your savings.
* Retirement account, as appropriate for your situation.
All deposits go directly into your investment account. Set up an automatic transfer every 2 weeks from the investment account to the checking account to cover expected bills (this also has the side effect of giving you some spending discipline). Keep only enough money in the checking account to pay the bills, plus a little slop. Write checks off the checking account except for certain large non-monthly bills (such as your home insurance and property taxes). I would recommend folding the mortgage into the checking account too but it isn't a big deal. Pay the large bills with checks off the investment account. Use your credit card for as much as you can, since you get the most protection there, but pay it off every month and never use it for cash advances.
I recommend NOT getting overdraft protection for the checking account, and make sure the credit card account is not set up to autopay from your checking account without your monthly authorization. Do NOT get credit or debit cards connected to your investment account.
Here's the deal. EVEN THOUGH you get good fraud protection by law, the plain fact of the matter is that cleaning up after fraudulent use of your accounts can be a real mess. This is why you want to keep your investment, checking, and credit card accounts separated, and protect yourself on top of that by keeping limited funds in your checking account. Also do not let your bank increase your credit limit to values far beyond your monthly use... you can call them up and actually ask them to lower the credit limit. Believe it or not, this helps against fraud by making the credit card account less interesting.
Multiple credit card accounts are only useful if you need an additional card to receive some special benefit, such as airline miles. You can't run up balances on multiple cards any more these days without it triggering a credit event and causing the interest rate on ALL the cards to spike simultaniously, even if you pay some of them off. Frankly, it is best to have just one card, two at the most. I only have one.
Finally, if you are really paranoid, you can lock your credit report, preventing new accounts from being opened in your name without the express permission of some entity (a third party or your bank, typically). Banks have begun offering this service directly but either third-party or bank-offered services work, and offer the most protection against fraud. The most common type of fraud after credit card fraud is identity theft, where the thief opens up a new bank account or credit card in your name, runs up debt, then abandons it leaving a huge black mark on your credit report, liens on your possessions, and a mess for you to clean up.
Fake it. Install some big fans to pull the building air in and exhaust it through the machine room. That's about all you can do if you only have $600 to spend. Of course, if the building manager figures out what you are doing he isn't going to be too happy about it.
You might also want to consider replacing the machines with ones that use less power, or consolidating resources into fewer boxes.
Ignoring the license for the moment, ZFS has a lot of desirable features. But it also tries to throw in the kitchen sink, far more then I personally believe a file-system should deal with. I haven't tried it myself so I don't know how well it performs.
HAMMER takes a different approach to redundancy. HAMMER is eventually intended to operate in a replicated multi-master clustered environment. The first release only has the beginnings of that work (aka single-master/multi-slave replication), but the basic principle that HAMMER follows is that no single copy of a file-system can ever be considered safe, no matter how much redundancy you throw into it. Software bugs are far more likely to corrupt a file-system then hardware issues.
Up until now snapshots have always been fairly expensive affairs. They run the gauntlet from outright dangerous in UFS to fairly quick in ZFS, but of all the OSS offerings only HAMMER gives you a fine-grained (~30-60 second interval if you don't lift a finger) historical access to the entire filesystem. All you need is a transaction id and you cd directory@@transaction_id and, poof, you are looking at a file or the entire filesystem as of some point in the past. You have full administrative control over what historical data is kept and what is thrown away, independent for each of your mirrors, backup systems, whatever.
After all, we need to justify getting those cheap, terrabyte+ drives coming out now!
As far as we can tell VirtualBox does not properly emulate the 8254, which we use for timer interrupts. We run it in a different mode then linux does and my guess is that VB doesn't emulate that mode.
People have told me that DFly does run under VMWare and MS virtualization and QEmu. And natively, of course.
Sorry, you're wrong. It's a nice fantasy but I've lost enough drives to know that powering off a drive while it is writing has a good chance of destroying it. I'm not talking ancient drives here, I'm talking drives made in the last year.
If you think otherwise then go right ahead, try writing to your drive and pulling the power. Keep doing it, I doubt the drive will last more then a few power cycles before it becomes completely corrupted and you have bad sectors coming out your ears.
You actually believe that at most you'd lose one sector? Good luck with that!
Er, no. Not at the rate a HD consumes power, particularly while writing. 1/100 of a second is plenty doable (enough to finish a full-track write). Several seconds is not really doable. The HD can only handle a voltage drop of ~1V (if that) on the +12V bus, and less on the +5V bus.
If a hard drive loses power while it is writing to the platter there is a very high chance that you will lose the HD. Not only is the HD likely doing a full-track write, and thus touching sectors that aren't even part of the computer-directed write operation, but HD manufacturers skimp on the parts (basically just a few big capacitors) to detect the loss of power, finish the write out, and prevent the HD's heads from writing a swath of garbage across half the disk as they whip over to their parked position.
The result? data corruption and even physical damage.
Probably five out of the last six drives I've lost were due to uncontrolled power failures. One was even from a UPS, which worked just fine but the computers failed to get the shutdown signal and were still writing when the UPS finally ran out of battery time.
The really funny thing about this is that your typical RAID system is doing parallel writes. You can wind up losing several disks at once and if that happens you probably won't be recovering anything off that RAID. Oops!
This has nothing to do with computer's DMA still running and passing corrupted data.
It's required by law. An inverter which does not disconnect when the grid goes down is illegal. There are also access laws... there must be an outside disconnect switch in clear view or near the house's outside panel. There are also laws (in CA) governing panel grounding, fusing, breakers, and other safeties.
Slashdot Mirror
And I'll tell you why.
Collisions became a non-issue the moment low-cost 10BaseT switches came into existance, which was, what, over 15 years ago? Don't bother arguing about collisions, not even my home network uses hubs any more. There are no collisions.
Congestion is a lot easier to handle then people seem to realize. All modern switches have packet buffers. Even the CHEAP switches have a few megabytes of buffer. GiGE switches have flow control on top of that.
Buffering and flow control does NOT mean that you can just squirt out packets and let things back up. What it does mean is that a large chunk of the problem space has already been solved. If you use the traditional over-build methodology and gang the links in your trunks you might not even have to worry about congestion at all.
For those situations where you do have to worry about congestion you already have multiple feedback mechanisms available to you to control throttling. Even the simplest algorithms can make a huge difference, and that is the key.
There IS a need for the more complex forms of congestion control. But the simpler forms solve 90% of the problem space. In otherwords, there is an incremental solution space to the general problem and the effect of that incremental solution space will not only be ubiquitous network protocols but also very low costs and the ability to incrementally upgrade your infrastructure as you need it rather then have to spend millions up front for an infrastructure to handle your expected needs for the next X years.
Let me give you an example of a simple form of congestion control for a SAN device. Lets say the device can handle 256 simultanious requests and implementations a reservation protocol for those 256 slots. A simple protocol would be for the host wanting to use the device to request N slots. The device assigns it, say, 3 slots. The host then uses those 3 slots to queue up to 3 simultanious requests, and reuses those slots as long as it needs to or until the device tells it use fewer. Lets say any given request cannot have a payload larger then 8K, just for argument's sake.
Consider the consequences of such a mechanism. For one thing you have immediately put a control on the maximum amount of data that can be backed up in intermediate switches for that device. 3 requests, 8K ... approximately 24K. That is a form of congestion control. For another the device has a limited number of slots for parallel operations (256). That is another form of congestion control. The device and/or host can revoke slots. That is another form of congestion control. The device can order which requests it responds to first. That is another form of congestion control.
Starting to get the idea? There are literally an INFINITE number of ways to control congestion, none of them require anything sophisticated at the physical layer. Even without smart switches you have hundreds of software solutions, all easily tunable.
In otherwords the problem is not only solvable, but even partial solutions will give system operators and network managers plenty of knobs they can tune to make their infrastructure work.
-Matt
What are ethernet's two biggest strengths? Think about it a moment.
It is high speed at a very low cost, and the ubiquitousness of the technology.
It doesn't really matter that the technology is inferior to the numerous very fast low latency solutions available today because all of those solutions are also very high-cost, low-volume solutions relative to ethernet, and have no ability to be incrementally upgraded. It doesn't matter that there are congestion issues when pushing a packet-switched technology to its limit, because anyone who has lived with this stuff for the last few decades knows that you simply overbuild it for your needs and all those problems disappear. It doesn't matter that the price point is GiGE because the technology has proven over and over again that the price point moves very quickly with adoption. The price point will soon be 10GiGE, and after that 100GiGE. It is unarguable. It doesn't matter that ethernet traditionally has higher latencies then currently existing higher-cost solutions. Latency has never been a show stopper for anyone except the super-computing dweebs.
The price of hardware has dropped around the ears of the higher cost solutions to the point where only a very small application space can actually gain an advantage using them. It will only get worse over time.
So even though, GiGE isn't quite fast enough to match platter rates on the best disks, let alone transfer rates available from SSDs, it doesn't matter. The low cost and clear future trends for the technology will trump everything. And the people making the decisions have the choice: They can be early adopters of 100GiGE, or choose to spend more of a premium on 10GiGE, but with the flexibility of NOT having to rip up their entire infrastructure. The ability to piecemeal-replace infrastructure is its own trump card.
-Matt
Hmm. It's really hard to say. Circuit boards are fairly well protected and the metalic contacts and solder joints will be in good shape if the equipment was powered down (they would be corroded if the equipment was powered on, depending on how long). But the electrolytic capacitors are probably in very bad shape. If the electronics have mold on them that means the water wasn't as clean as you might have thought and organic matter got caught up in there. The electrolytics might be unrecoverable meaning the board would be unrecoverable or only work for a short period of time. Similar HDs might work for a short while but don't count on them staying working.
You can try washing the circuit boards carefully in fresh water (someone mentioned distilled water but a Brita filter will work just fine, disolved minerals don't really hurt anything), but then you have to dry it completely and the only way to do that is in a very low humidity environment... for example, place the board in an oven at its lowest setting (~120 degrees F) for at least four hours. Air conditioning also helps on the humidity front but you also need the heat. e.g. using an oven in an air-conditioned room. You would have to be very careful to protect the board from the oven's heating coils since they tend to turn full on and then full off. And even being careful you might still destroy it.
If the circuit board is powered on while still wet any metalic surfaces the water touches will corrode over time and destroy the board. The board might work for a short period of time but then it would just die.
-Matt
Since the protocol is effectively just a low-speed digital signal... almost a square wave, the keyboard cable will radiate broad-spectrum noise around the 16 KHz band (A PS/2 keyboard clocks at around 10-16 Khz from a quick google lookup).
That frequency might be too low for a ferrite bead to stop but its worth a try anyway. The keyboard cable is going to be too short to act as an Antenna at that frequency but because it is a square wave there are going to be a lot of harmonics. And because the base frequency is so low it could very well be that the noise generated from the computer itself would not interfere so much. So a ferrite bead might actually work.
They could also be measuring HF generated by the keyboard processor or matrix. The keyboard matrix itself is being scanned continuously, probably in the high KHz or MHz range, and those *ARE* long wires running in a matrix. Hitting a key will shortcut portions of the scan and produce discernable frequency spikes. Since the keyboard is constantly scanning it would be possible to resample multiple times to kick down the noise floor before the user lets go of the key.
I don't know any easy way to protect against that short of wrapping the whole keyboard in tinfoil, or typing very quickly. A keyboard designer could simply go with a 4-layer board with power and ground planes on the outside, that would put the scanning traces in a faraday cage.
It could be that other effects are being measured as well. When you type there is always a reaction from the computer, such as burning cpu cycles to process the interrupt as well as a reaction from the application being typed into. I doubt those could be translated into actual key codes though.
-Matt
Well, once I was low on fuel but wanted to get home without stopping at a gas station, so I slipped into the wind shadow of a large truck (going at around 60 mph) and my MPH went up drastically. I don't remember how much but it was a lot.
Not sure I would recommend it for general purposes, though, since you almost have to be tail-gating the truck and can't really see what is in front of it. And he might get annoyed, but the guy in front of me didn't seem to mind. Make sure nobody is behind *you*, though, as you might have to hit your breaks hard if something goes wrong.
-Matt
It should be noted that 'ultra capacitor' and 'higher current' don't mesh. All ultra-capacitors that I know of also have high internal resistances (30-100 ohms).
If you short even a small led-acid battery out you can get 200+ amps going through your wires. Oh yah, and the battery can blow up in your face.
Once one of our techs dropped a long screw-driver into a battery box full of led-acid batteries. The screw driver lasted less then a second. There was a bright flash, and that was the end of the screw driver. He never did that again.
If you short an ultra-capacitor out you'd be lucky to get 0.1 amp. It might get a little warm, but that's about as far as it will go, then its charge will run out. There is just no comparison.
-Matt
Yes, massively folded. Similar technology has been in used for many years to produce multi-Farad 'dime' capacitors, whos surface areas start around the size of a tennis court and go up from there.
These sorts of capacitors have very high capacitances (in the multiples, even tens of Farads) and a 20-50 year life span (or longer depending on how they are built), but also tend to only be able to be charged to fairly low voltages (3v, 5v, etc), and also have fairly high internal resistances (though this might be different for the newer Graphene-based caps), limiting the discharge rate.
This means they won't be replacing batteries any time soon, but the advances we're seeing are pretty cool.
We mostly use these things to run real time clock chips and provide backup power for static ram... i.e. very low current applications.
-Matt
It isn't the internet that is slow, not really. Three things have a disproportionate effect on users perception of the internet: (1) Web site load times and (2) Horrible packet management by your DSL/Cable modem for outgoing and (3) Massive packet backlogs on the ISP side of the router in the download direction, mainly due to YOUR devices advertising ridiculously huge TCP windows or otherwise not doing any management of the incoming bandwidth at all. Those three issues cover 90% of the problem space and none of them are really the ISP's fault.
* Web sites access all sorts of crap these days, mostly related to ad content. Many also run horrible javascript all over the page which slows the site way down even once the page has been loaded. Ad content sources often present a larger responsiveness issue then the site itself. Using ad site blockers will improve site responsiveness.
* Many home systems these days have more then a few devices accessing the internet. Very few of these devices do any sort of packet management or bandwidth control. The result is that your interactive traffic is not prioritized over all your other traffic.
* Most consumer (read: windows) boxes, and most cable and dsl modems either have no bandwidth management or have only very primitive bandwidth management for uplink data. They might be capable of separating out various types of traffic, such as VOIP, but they usually can't handle more then a few simultaneous connections and then only under very strict conditions. They simply do not have enough memory to buffer more then two or three packet streams.
* Programs like bittorrent will easily blow-out the downlink direction of an ISPs DSLAM or cable provider side router. It is virtually impossible to manage the downlink packet rate with a cable modem, even with the configuration options available. In fact, the many ways people use to mask bittorent traffic ends up making things worse by defeating attempts by ISPs to simply manage the packet stream (verses cutting it off).
None of these issues are really the ISP's fault. People who know what they are doing throw a unix-based (aka linux, bsd) router inbetween their home network and their cable/dsl modem. Simple QOS filtering doesn't do the job, you really need to run a full-blown fair-share sub-scheduler on top of your basic QOS separation and pre-restrict the bandwidth to move all the packet queues onto your router, for both directions. That will take care of the uplink direction at the very least.
Incoming bandwidth is harder to deal with because you often do not have direct control over the devices trying to downlink the data. The best you can do there is create an artificial bandwidth constriction between your unix-based router and the target devices in the incoming direction. This will shift the bulk of the packet backlog away from the ISP's DSLAM/router and onto your router. Your router has enough memory to deal with megabytes of stream backlog if necessary so you can control all incoming bulk data streams while letting all the interactive traffic bypass the queues.
Here's an example: Take a single TCP stream downloading a movie. If the TCP connection is advertising a very large data window, such as a megabyte, then what winds up happening is that a megabyte of data winds up getting backlogged on the ISP-side of your connection as the bandwidth is constricted down to your cable/dsl modem's capabilities. The ISP cannot handle that large a backlog, particularly if you are downlinking several things simultaneously (each with a megabyte of backlog). Traditionally ISPs have used RED or other congestion control algorithms but the plain truth of the matter is that THEY DO NOT WORK VERY WELL FROM THE POINT OF VIEW AND PERCEPTIONS OF THE END USER. It is far better to not have the backlog to deal with in the first place, at least not on the ISP side of the connection.
In anycase, the issue is more due to the many applications trying to use your pipe as if they owned the whole thing then it
I think all flash storage will have to wind up using that sort of model, it is the only way to really quantify the durability of flash-based SSD. In the world of filesystems there are plenty of people working on flash-specific filesystems, but they are so specialized that the result is always very highly restrictive and inflexible. We need to be able to run 'normal' filesystems (ZFS, HAMMER, etc) without having to worry about sector wear.
I got into a huge argument on the FreeBSD groups about the use of a general filesystem over a specifically flash-aware filesystem. I used your very argument, in fact. It is clearly the future but some people are too myopic to see it.
I still see a huge disparity between write bandwidth and total write capability before the flash dies. Hard drives do not have this disparity... you can write to a hard drive at the platter rate 24x7 for years without pause. You can't do that with a flash-based SSD.
Even if replacement time winds up being the same on average, the important thing here is properly quantifying what that time will be regardless of the load placed on the device. That is the only weakness of flash SSD (other then capacity).
-Matt
This isn't correct. There is infact a drive flush command which all real hard drives support. This command flushes the drive's write cache and does not return until the data is on the physical media. ZFS and HAMMER both use this command, as do numerous other filesystems.
There used be a notion of 'ordered writes', that is the ability to issue several parallel writes but tell the disk the precise order in which they must be committed to the media. As filesystems have gotten better, though, this notion has pretty much been thrown away because it ruined disk performance. What filesystems do now is perform massively parallel non-order-dependant writes (allowing the drive to optimize head movement) and cache flush operations at critical points. Many modern filesystems have this ability.
A cache flush does not prevent new writes from being queued, it simply does not return until all writes already queued have completed. That is exactly the behavior that modern filesystems want.
-Matt
You clearly haven't read my original posting very carefully because I in fact did mention that laptops were a good fit for SSDs for consumer use. A typical consumer uses the machine resources available to him or her so sparingly that the limited write cycles of a flash device are not an issue for the purposes of driving the market. But the storage requirements for even the typical consumer is changing at a very fast pace.
What you are trying to do is make the blanket statement that a SSD is a drop-in replacement for a hard drive. That isn't even close to being true. I would certainly consider a SSD for my laptop, because I do not use my laptop for write-heavy work and I don't store my entire life on it. A SSD is completely out of the question for any of my other half dozen machines, though.
Similarly, a SSD would not be appropriate for any consumer who puts his or her entire life on their laptop. My parents would be a good example of that. The generation in retirement is already using hundreds of gigabytes. People in their 40's are using hundreds more. People in their 20's and 30's are already hitting, and passing the terrabyte mark. Video, Music, Pictures, Voice Mail. You name it. People these days want access to all their information wherever they are. A piddly little 50G SSD drive does not do the job.
Write-heavy applications are on the rise too. The saving grace for the SSD market is that write-heavy applications are more specialized. For your typical consumer the problem is going to be storage capacity and not write use.
In anycase, I think I've proven my point.
-Matt
I don't think this is true any more. My parents already use several hundred gigabytes and the number keeps growing. The reason is that your typical consumer these days is using the storage in the same manner we used to use archival tapes... their entire lives are stored on their hard drive now. Not only are their entire lives stored, but they need backups as well (or in the case of Apple products, simply replicating the entire data set on multiple boxes).
In modern day, that means all the pictures you've ever taken with your digital camera, every CD you've ever bought, and in the next few years it is going to be every DVD or on-line video you've ever bought, too (if not already). Think Apple-TV. Think every email, every voice mail, every cell phone pic, EveryTHING.
I already have friends who use TiVO-like devices with terrabyte+ drives and don't delete anything. They want entire seasons of their favorite shows instantly accessible.
This is where consumers are going.
File-systems are also going through changes. Microsoft's little unwinding FIFO is nothing compared to the full history that a filesystem like HAMMER can retain, or using ZFS snapshots semi-permanently. These changes are going to multiply storage use. It isn't because the filesystems are becoming bloated, they aren't. It's because having access to a snapshot of your filesystem at virtually any point in the past is becoming more and more important in the larger scheme of things. Users *desire* that sort of access. For machine management, for undoing damage from viruses or badly written applications, for maintainance, for all sorts of things. Machines only appear to be fragile today because these features haven't yet made it down to typical consumer use. But they will. Very soon, they will.
-Matt
Don't take manufacturer claims at face value, they never tell the whole story. 50 GBytes/day worth a block I/O operations is not the same as adding 50 GBytes/day in new files or data. It isn't even close.
A typical consumer machine running typical office software, or a game, or a typical laptop being used by a typical consumer might get in under the limit and such a claim might be reasonable in that context. Turn on paging to swap, though, and do any sort of moderate workload and you will blow out that 50 GBytes/day very quickly.
And a production server environment? Forget it. The flash drive will be dead in weeks if you are not very, VERY careful about how you use the drive. I also shudder to think of what a virus could do to a SSD. It would not be difficult to purposefully wreck a drive.
As I have said, and as the Subject line says SSDs have their place in read-heavy production environments, particularly for serving static web content. They have their place, but they are not file-and-forget drop-in replacements for hard drives.
I have high hopes that SSDs will overcome the write limitation. IBM's research is very promising. But current flash technology is crap for writing as far as I am concerned.
-Matt
Write staging is virtually irrelevant with a modern filesystem. Any log-based, undo-baesd, or recursive-update (zfs) based filesystem has virtually no synchronous writing constraints. HAMMER for example can issue a ridiculous amount of write I/O asynchronously even when it is flushing or fsync()ing.
So there are two things going on: First, the OS is caching the write data and disconnecting it from the application. Second, a modern filesystem is further disconnecting writes by reducing write-write dependancies to a minimum, and allowing non-dependant writes (particularly bulk data) to run out even in the face of other parts of the filesystem needing an occassional write-write dependancy.
What it comes down really is fsync() time. Only databases really need to use fsync() and frankly most of that functionality is well covered by battery or dime-cap-backed static ram. You don't really need much more then a megabyte or two of that sort of ram to absorb nearly all the write latency of the backing store's hard drive.
-Matt
I would agree that SSDs can take a large chunk out of the high-performance HD market, but only for read-heavy environments. I can already see it solving issues related to hybrid static and dynamic web content serving, for example. But in write-heavy environments the IOPS capabilities of flash becomes irrelevant because any write-heavy environment will also quickly wear the flash device out. That makes its usefulness questionable as a staging medium for things like database commits. It doesn't take much battery-backed (aka dime-cap-backed) static ram to greatly improve commit staging operations on a database, there is no need to use flash there.
-Matt
Actually that isn't correct. Magnetic media has thermal bleeding and magnetic cells will deteriorate over time. However, many of the issues surrounding magnetic media are directly related to reading and writing, verses just sitting on a shelf, and if you really needed the data you would still be able to recover it many years down the line even after the bearing lubrication turned to mush.
With flash you are dead in the water once a cell dies. There is no way to recover the data. And flash cells will leak whether the flash is in use or not (though flash cells also have issues with adjacent writes). Rewriting a flash cell damages it, so the actual life of the data just sitting on a shelf is going to be all over the map depending on how heavily the flash device was used.
Still, the read-life of a flash cell can in fact be extended considerably if the temperature is kept low. I'm not sure that counts for archival storage (a HD isn't suitable either), but it should count for something.
-Matt
The usefulness of SSDs is undeniable in small devices, but there isn't much of a point of actually using it as a high performance write-heavy device with the limited life of its flash cells. Any heavy write use will quickly wear the device out, and this has already been proven pretty much with people trying to use them as generic HD replacements on microsoft systems with swap enabled.
The amount of storage is also very tiny compared to a modern hard drive in the same form factor. Combine those two together and the usefulness of SSD for any application that writes a lot of data is going to be severely limited. I don't think I would trust it even as a staging device for database transactions.
Laptops and small devices are the only consumer devices that would have a clear advantage in the use of such storage. Laptops for the solid-state nature of SSDs (not the performance), and consumer devices for the same.
On the flip side, SSDs clearly have a major advantage for serving moderately-sized static or mostly-static data sets. Such data sets are often larger then the 2-16G of main memory a server has. Having 50G of 'fast' mostly-read-only SSD storage would greatly improve the performance of static web servers.
Any mostly-read application of moderate size would benefit from SSDs by reducing the need to cache data in main memory, leaving more memory available for dynamic data sets and operations. One would no longer have to separate static and dynamic web content in heavily loaded sites, for example. The static content could be served out of SSD with very little main memory impact and the same system's horse-power and memory could then be directed to the dynamic content.
I'm hoping the research IBM is doing will yield better non-volatile, high performance solid state storage.
-Matt
Use your own bank's bill-pay service, if they have one. It's the only safe way to semi-automate the process, and it is best to not allow it to run fully automated. That is require that you at least review the bill and approve it before the bill is allowed to be paid. You have full control over when and how much is paid and to whom, and you can review your checking account balance at the same time to make sure you don't overdraft the account.
The other thing I would recommend is to use a separate checking account to pay your bills with. Do NOT pay your bills directly from an investment account. Ideally you want three accounts:
* Credit card account, preferably with the same bank you have your checking account with.
* Checking account for bill pay and check writing.
* Investment account for your savings.
* Retirement account, as appropriate for your situation.
All deposits go directly into your investment account. Set up an automatic transfer every 2 weeks from the investment account to the checking account to cover expected bills (this also has the side effect of giving you some spending discipline). Keep only enough money in the checking account to pay the bills, plus a little slop. Write checks off the checking account except for certain large non-monthly bills (such as your home insurance and property taxes). I would recommend folding the mortgage into the checking account too but it isn't a big deal. Pay the large bills with checks off the investment account. Use your credit card for as much as you can, since you get the most protection there, but pay it off every month and never use it for cash advances.
I recommend NOT getting overdraft protection for the checking account, and make sure the credit card account is not set up to autopay from your checking account without your monthly authorization. Do NOT get credit or debit cards connected to your investment account.
Here's the deal. EVEN THOUGH you get good fraud protection by law, the plain fact of the matter is that cleaning up after fraudulent use of your accounts can be a real mess. This is why you want to keep your investment, checking, and credit card accounts separated, and protect yourself on top of that by keeping limited funds in your checking account. Also do not let your bank increase your credit limit to values far beyond your monthly use... you can call them up and actually ask them to lower the credit limit. Believe it or not, this helps against fraud by making the credit card account less interesting.
Multiple credit card accounts are only useful if you need an additional card to receive some special benefit, such as airline miles. You can't run up balances on multiple cards any more these days without it triggering a credit event and causing the interest rate on ALL the cards to spike simultaniously, even if you pay some of them off. Frankly, it is best to have just one card, two at the most. I only have one.
Finally, if you are really paranoid, you can lock your credit report, preventing new accounts from being opened in your name without the express permission of some entity (a third party or your bank, typically). Banks have begun offering this service directly but either third-party or bank-offered services work, and offer the most protection against fraud. The most common type of fraud after credit card fraud is identity theft, where the thief opens up a new bank account or credit card in your name, runs up debt, then abandons it leaving a huge black mark on your credit report, liens on your possessions, and a mess for you to clean up.
-Matt
Fake it. Install some big fans to pull the building air in and exhaust it through the machine room. That's about all you can do if you only have $600 to spend. Of course, if the building manager figures out what you are doing he isn't going to be too happy about it.
You might also want to consider replacing the machines with ones that use less power, or consolidating resources into fewer boxes.
-Matt
Ignoring the license for the moment, ZFS has a lot of desirable features. But it also tries to throw in the kitchen sink, far more then I personally believe a file-system should deal with. I haven't tried it myself so I don't know how well it performs.
HAMMER takes a different approach to redundancy. HAMMER is eventually intended to operate in a replicated multi-master clustered environment. The first release only has the beginnings of that work (aka single-master/multi-slave replication), but the basic principle that HAMMER follows is that no single copy of a file-system can ever be considered safe, no matter how much redundancy you throw into it. Software bugs are far more likely to corrupt a file-system then hardware issues.
Up until now snapshots have always been fairly expensive affairs. They run the gauntlet from outright dangerous in UFS to fairly quick in ZFS, but of all the OSS offerings only HAMMER gives you a fine-grained (~30-60 second interval if you don't lift a finger) historical access to the entire filesystem. All you need is a transaction id and you cd directory@@transaction_id and, poof, you are looking at a file or the entire filesystem as of some point in the past. You have full administrative control over what historical data is kept and what is thrown away, independent for each of your mirrors, backup systems, whatever.
After all, we need to justify getting those cheap, terrabyte+ drives coming out now!
-Matt
As far as we can tell VirtualBox does not properly emulate the 8254, which we use for timer interrupts. We run it in a different mode then linux does and my guess is that VB doesn't emulate that mode.
People have told me that DFly does run under VMWare and MS virtualization and QEmu. And natively, of course.
-Matt
Sorry, you're wrong. It's a nice fantasy but I've lost enough drives to know that powering off a drive while it is writing has a good chance of destroying it. I'm not talking ancient drives here, I'm talking drives made in the last year.
If you think otherwise then go right ahead, try writing to your drive and pulling the power. Keep doing it, I doubt the drive will last more then a few power cycles before it becomes completely corrupted and you have bad sectors coming out your ears.
You actually believe that at most you'd lose one sector? Good luck with that!
-Matt
Er, no. Not at the rate a HD consumes power, particularly while writing. 1/100 of a second is plenty doable (enough to finish a full-track write). Several seconds is not really doable. The HD can only handle a voltage drop of ~1V (if that) on the +12V bus, and less on the +5V bus.
-Matt
If a hard drive loses power while it is writing to the platter there is a very high chance that you will lose the HD. Not only is the HD likely doing a full-track write, and thus touching sectors that aren't even part of the computer-directed write operation, but HD manufacturers skimp on the parts (basically just a few big capacitors) to detect the loss of power, finish the write out, and prevent the HD's heads from writing a swath of garbage across half the disk as they whip over to their parked position.
The result? data corruption and even physical damage.
Probably five out of the last six drives I've lost were due to uncontrolled power failures. One was even from a UPS, which worked just fine but the computers failed to get the shutdown signal and were still writing when the UPS finally ran out of battery time.
The really funny thing about this is that your typical RAID system is doing parallel writes. You can wind up losing several disks at once and if that happens you probably won't be recovering anything off that RAID. Oops!
This has nothing to do with computer's DMA still running and passing corrupted data.
-Matt
It's required by law. An inverter which does not disconnect when the grid goes down is illegal. There are also access laws... there must be an outside disconnect switch in clear view or near the house's outside panel. There are also laws (in CA) governing panel grounding, fusing, breakers, and other safeties.
-Matt