There's no reason for prices to go down on SSDs. Economic downturn? Not for flash chips, not when there are basically only two vendors making them, not when demand is high, and not when mass production has a low barrier to entry and is already extremely cheap... just plop a bunch of chips on a circuit board and you are done. That is what a SSD is.
People should also remember that Intel's graphics strategy is to try to do it with a general purpose cpu rather than a dedicated graphics engine. This could be part of that strategy. With so many cores available a system can simply dedicate a few to particularly important jobs such as rendering.
I remember having to physically hold a seagate drive in my hand and twist it back and forth while I turned on power to get it to spin up. And then another time I had to take the case off and move the disk with my finger to get it spun up, then race against time to read the data off before the media failed. Oh yes, fond memories indeed:-)
The problem with backups is making sure they'll actually be there for you when you need them. This precludes most offline mechanisms using media not designed for offline storage (hard disks, DVDs, etc), leaving two options: (1) Use tape or (2) Store the backups online in multiple places so you know when the storage fails and can replace it.
Tape is a terrible online storage medium (it just takes too long access data and wears the tape out when you do access the data), but it is just fine for offline storage.
Yah, but be careful. Write performance is virtually a non-issue in the SSD space. There's no point being able to write at a sustained 150-200MB/sec when the only real-world outcome of doing that is your SSD will wear out more quickly. Writes can be cached, so only long-sustained writes will actually impact system performance. If you are bursting a few hundred megabytes worth of writes your system ram can cache that trivially.
I find it unlikely because in the last decade or two it has become very important for programs to be able to know whether accessing a bit of memory is going to cause a long page fault / stall due to I/O, or not. Simply mmap()ing a file isn't good enough in a threaded environment (when running a threaded application) where the app might be holding locks through the memory access. At least not unless the application has very good locality of reference and can assume the memory in question will be well-cached.
That is, standard paging/swapping isn't an issue here, but mmap()ing large data sets and accessing them via the mmap is.
Yes, absolutely. It takes away a significant chunk of the HD market for applications which do not require hundreds of gigabytes or terrabytes of storage, and also takes away a significant chunk of the HD market for high speed storage, and on top of that it also hits the DRAM market because SSD storage is significantly cheaper than DRAM for caching purposes (particularly when you also take into account the motherboard, footprint, and power resources required).
People who were buying big whopping servers with 16G+ of ram used mostly for caching data can now do the same thing with 4G of ram and a 40G SSD and get scaleable caching (just stuff a bigger SSD) out of it in a motherboard footprint which is 1/4 the size and 1/2 or less the power and half the price.
People who were putting together big RAID systems to deal with spindle seek times can now use a SSD to cache whatever the data or meta-data was responsible for those random seeks and now no longer need big RAID systems just for performance reasons.
For the most recent laptop I got I threw away the HD and threw in a smaller SSD, and the laptop screams.
etc. HDs aren't dead, they are still the best mass-storage solution when a large amount of storage is required, but a good chunk of their market is going to the SSD space. MLC flash isn't going to destroy the HD business. Maybe some future innovation (IBM's M-RAM?) will.
It's the nature of the beast. If a company produces goods which are too high in quality their sales volume goes down (because nobody is replacing the item after a few years) and they go out of business. Well, not quite true but close enough. Either the company goes out of business in the high-volume low-cost commodities market *OR* they jack up their prices and go for the low-volume high-quality market. If they do that, of course, the product will no longer be considered a consumer good.
All consumer goods work this way. It's why China can sell cheap tool sets for $20 which crap out quickly and still compete with high quality manufacturers which sell the same sets for $200 (and which last forever). For example. It's why cell phones are not made in a robust fashion and the case physically wears out after only a year of use. It's why case fans use cheap plastic bearings which last MAYBE a year and can't be run at full speed for more than a month before dying, even though the computer itself will run fine for 20 years.
That's what we're seeing. I think of an SSD more like an extension of memory and less like a hard drive. For mass storage the hard drive is the most efficient solution, and for performance the SSD is the most efficient solution. If you can fit the working data-set extracted from the HD onto your SSD you are golden.
Most servers still only use a 1GigE network link, which is only 100MB/sec. The cheapest SSD can trivially do 100MB/sec, so if the data-set fits you now have a server capable of saturating the link. Even the little 40G Intel can do 200MB/sec without breaking a sweat.
At 10GigE things turn around but even so 10GigE is only 1 GByte/sec, and even using 3Gb/sec SATA ports will get you there with only three or four small SSDs (about $500). People who don't want to be on the bleeding edge can simply wait another year when 6GBit/sec SATA becomes a commodity and SSDs capable of driving it do as well. Then you'll only need two devices to saturate a 10GiGE link.
By treating the SSD as if it were cache ram the whole $cost/Gb issue goes out the window. It no longer matters that SSDs have a 30:1 cost over HDs on a per-gigabyte basis. If you need a terrabyte of storage you buy a $100 HD (instead of a $3000 SSD). If you want a 32G data cache you buy a $115 40G Intel MLC SSD. Two different things which combine for really excellent performance.
I've been running tests with the little Intel 40G MLCs. So far I am getting a durability run-rate of around 110TB (the drive is rated for ~40TB). That is, I'll be able to do at least 100TB worth of writes to this particular SSD before it wears out. That's actually quite a lot. Intel's specifications are very conservative.
MLC flash has approximately a 10,000 cycle endurance. It all comes down to two things: (1) How good the drive software is at combining dynamic and static wear leveling algorithms and (2) How friendly the OS is in writing to the drive. DragonFly's swapcache goes to great pains to generate large clustered writes to greatly reduce write amplification and write combining effects, and it seems to work very well.
Clearly the newer SSDs are doing a much, MUCH better job with the wear leveling than older SSDs did. They are plenty good enough now for most applications. Write endurance also scales linearly with drive size. That is, the cells still have a 10,000 cycle endurance but there are more of them available.
Already exists. DragonFly + swapcache, with SSD configured swap (32G nominal on 32bit and 512G nominal on 64bit). It works very nicely with a 40G Intel MLC drive.
Of course, you'd have to run DragonFly:-). heheh. But that said I think most OSs have solutions. There's ZIL for ZFS (Solaris, FreeBSD), I'm sure Linux has something, and Windows 7 has something. The DragonFly solution is quite general purpose though and not tied to any particular filesystem. We use it primarily for meta-data caching for the millions of inodes on our servers.
I agree. That consultant was either misquoted or is just pulling numbers out of his ass. There's no way an engine control system with fly by wire for a car could possibly require that much code. I very much doubt the codebase would even reach 2 million lines of code, let alone the absurd number that was quoted.
I seem to remember this way back then. There was a big brouhaha about Silicon Valley companies hiring programmers as contractors in order to get around various employment rules (overtime pay, etc), and programmers essentially being employees because their so-called contracting work was basically full-time with a single employer for an extended period.
But it seems Congress went overboard in their zeal to reign-in the practice.
I think you're missing the point. The SATA form factor is going to have much higher demand than any PCI-e card, period, for the simple fact that PCI-e is not really expandable while SATA is. SATA has a massive amount of infrastructure and momentum behind it for deployments ranging the gauntlet, small to large. That means SATA-based SSD drives are going to be in very high volume production relative to PCI-e cards. It DOES NOT MATTER if the PCI-e card is actually cheaper to produce, it will still be priced at a premium verses the SATA form factor due to the lack of volume and PCI-e will never achieve the same volume due to its lack of flexibility.
The fact that the form factor has volume demand means that many manufacturers can get a piece of a large pie by selling devices in that form factor. A larger piece than they could get selling PCI-e cards.
In addition, the competition in the space creates innovation. This is why we are seeing such a fast ramp-up in SSD performance and features. The SATA form is driving the ramp-up.
Yes, SSDs are hitting the 3Gbit SATA II phy limit. And your point is what? 99.9% of the installations out there don't actually need more bandwidth, so hitting the limit is not going to magically create more demand for PCI-e and other non-SATA solutions. The SATA phy standards will progress along with everything else. We'll have 6Gbit/s soon enough, and the delay is not going to have any real effect on SATA being the dominant form factor standard for the technology. The single port limit isn't even that big of a hurdle today since most motherboards have several SATA/E-SATA ports.
PCI-e based solutions will track the same lines as all other bus-card solutions have tracked: Low volume, premium pricing, highly-specialized, and non-standard drivers. If you are hoping to see SATA based SSDs disappear in favor of a PCI-e card you are in for one hell of a disappointment.
Yah. And that's the one overriding advantage to SSDs in the SATA form factor. They have lots and lots of competition. The custom solutions... the PCI-e cards and the flash-on-board or daughter-board systems wind up being relegated to the extreme application space, which means they are sold for tons of money because they can't do any volume production and have to compete against the cheaper SATA-based SSDs on the low-end. These bits of hardware are thus solely targeted to the high-end solution space where a few microseconds actually matters.
Now with 6GBit (600 MByte/sec) SATA coming out I fully expect the SATA based SSDs to start pushing 400MB+/sec per drive within the next 12 months. If Intel can push 200MB/sec+ (reading) in their low-end 40G MLC SSD, then we clearly already have the technological capability to push more with 6GBit SATA without having to resort to expensive, custom PCI-e jobs.
At least not the Colossus I bought. Write speeds are great but read speeds suck compared to the Intels. The Colossus doesn't even have NCQ for some reason! There's just one tag. The Intels beat the hell out of it on reading because of that. Sure, the 40G Intel's write speed isn't too hot but once you get to 80G and beyond it's just fine.
The problem with write speeds for MLC flash based drives is, well, its a bit oxymoronic. With the limited durability you don't want to be writing at high sustained bandwidths anyway. The SLC stuff is more suited to it though of course we're talking at least 2x the price per gigabyte for SLC.
--
We've just started using SSDs in DragonFly-land to cache filesystem data and meta-data, and to back tmpfs. It's interesting how much of an effect the SSD has. It only takes 6GB of SSD storage for every 14 million or so inodes to essentially cache ALL the meta-data in a filesystem, so even on 32-bit kernels with its 32-64G swap configuration limit the SSD effectively removes all overhead from find, ls, rdist, cvsup, git, and other directory traversals (64-bit kernels can do 512G-1TB or so of SSD swap). So its in the bag for meta-data caching.
Data-caching is a bit more difficult to quantify but certainly any data set which actually fits in the SSD can push your web server to 100MB/s out the network with a single SSD (A single 40G Intel SSD can do 170-200MB/sec reading after all). So a GigE interface basically can be saturated. For the purposes of serving data out a network the SSD data-cache is almost like an extension of memory and allows considerably cheaper hardware to be used... no need for lots of spindles or big motherboards sporting 16-64G of ram. The difficulty, of course, is when the active data-set doesn't fit into the SSD.
Even using it as general swap space for a workstation has visible benefits when it comes to juggling applications and medium-sized data sets (like e.g. videos or lots of pictures in RAW format), not to mention program text and data that would normally be throw away overnight or by other large programs.
Another interesting outcome of using the SSD as a cache instead of loading an actual filesystem on it is that it seems to be fairly unstressed when it comes to fragmentation. The kernel pages data out in 64K-256K chunks and multiple chunks are often linear, so the SSD doesn't have to do much write combining at all.
In most of these use-cases read bandwidth is the overriding factor. Write bandwidth is not.
We're adjusting our disklabel64 utility and kernel support to set the partition base offset such that it is physically aligned instead of slice-aligned, and we are using 32K alignment. That should fix the problem without having to mess around with fdisk.
The DragonFly 64-bit disklabel structure uses 64-bit byte offsets instead of sector addressing to specify everything. It ensures things are at least sector aligned but we wanted to make disk images more portable across devices with potentially different sector sizes. The HAMMER fs uses byte-granular addressing for the same reason, 16K aligned.
Well, VbV's security issues are a problem for Visa to solve. It's great for merchants who sell high-priced items (like NewEgg, camera stores, etc). Many smaller merchants who had to go through a whole back-and-forth thing with the customer and credit card company before (for large, expensive orders) can now just use VbV for the same high-priced purchase instead. Higher volume merchants like NewEgg can streamline their credit checks with VbV and even allow shipments to addresses other than the billing address.
I'm not sure why people are saying that it transfers liability to the customer, it doesn't. The liability is transfered from the merchant to the Visa (well, actually the issuing bank I think). Customers are not liable for fraudulent use of a credit card by VbV or anything else.
I build new boxes every 6-8 months or so and rotate them into production boxes to make room for the next set. Until recently the Intel chipsets were ahead of the game vs the AMD chipsets with regards to things like E-SATA, AHCI, and PCI-e. AMD has caught up in the last 8 months, though. High-end Intel cpus tend to be a bit faster than high-end AMD cpus and you can also stuff more memory into small form-factor Intel boxes vs small form-factor AMD boxes.
On the flip-side, AMD boxes tend to be cheaper all-around and aren't quite so gimicky when it comes to managing cpu speed vs heat dissipation. Whole systems based on AMD seem to eat less power and from a cost standpoint when running systems 24x7. Power is getting to be quite important.
If you are trying to create the fastest, highest-performance box in the world Intel is probably your game (and for graphics you are going to be buying a 16x PCI-e card anyway with that sort of setup).
If you ratchet down your expectations just a bit, however, you can slap together a very good box with AMD at its core for half the price and 85% of the performance, and that is going to be plenty good enough for just about anything considering how overpowered machines have gotten in the last few years vs what people actually run on them.
Personally speaking I see no point purchasing the absolute bleeding edge when it is just going to become non-bleeding edge in 8-months when I can instead purchase two of something just slightly behind the bleeding edge at a much lower price.
I've been a sailor most of my life. We haven't used Loran C seriously for almost two decades. Most boats don't even have Loran receivers any more. It's GPS all the way whether you are a casual sailor or a commercial ship captain. In fact, large commercial ships are required to use GPS and special transceivers these days (the boater's equivalent of GPS-based aircraft systems). If backup matters one could pack a RDF or maybe even a sextant, but frankly GPS has not failed even once from the day it became available to boaters. Besides, Loran C pretty much only works near the coastline of major industrialized nations (or did)... it wouldn't be all that helpful if you were lost at sea.
The coast guard should have abandoned Loran C years ago.
All it really means is that products which currently require large amounts of rare earths will continue to evolve and require less of the stuff over time. This has in fact already happened to some degree with mature technologies such as catalytic converters. The same thing will happen with newer technologies. An increase in the cost of rare earth materials will also push nanotech development over time, in particular nano-featured surfaces.
California is basically the only reason we have efficient washers and dryers, wallwarts with switching power supplies instead of transformers, consumer electronic devices which actually have low power modes, and vehicle requirements that vastly improve safety and mileage over federal standards. It has all been beneficial in reducing per-capita energy consumption (and water consumption too when it comes to washing machines).
The problem the U.S. has is that most people can't see beyond the end of their nose when it comes to shaping policy. It's really unfortunate that the Feds can't get their act together and it takes action by a state like CA to actually get something done. It's doubly unfortunate that CA regulations designed to give industries upwards of a decade to make changes aren't allowed to take effect until the very last minute by idiot politicians who think they are doing industry a favor when all they are really doing is making our industry non-competitive with other countries and creating massive shocks to the system that are totally unnecessary.
You have to ask yourself, what do you need that kind of speed for vs a more portable, hot-swappable, and likely longer-lived SATA/E-SATA standard? Maybe a transactional store for a database, but that is pretty much it. A PCI-e style interface would be relegated only to those situations where extreme performance is required. Such devices will always be priced at a premium over their SATA counterparts simply by virtue of their lower volume production.
I do have an interest in how well a SSD could be used to expand the effective physical memory for a machine under load. Say, for an applet server. Another possible use would as a disk cache fronting slower multi-terrabyte HD storage. A PCI-e based device might be an improvement over SATA for that sort of thing though probably not enough of an improvement to justify the difference in cost. The real limitation to using a flash device as another caching layer is not performance but instead wear on the flash chips.
Slashdot Mirror
There's no reason for prices to go down on SSDs. Economic downturn? Not for flash chips, not when there are basically only two vendors making them, not when demand is high, and not when mass production has a low barrier to entry and is already extremely cheap... just plop a bunch of chips on a circuit board and you are done. That is what a SSD is.
-Matt
There is absolutely nothing here that a Nuke couldn't also have fixed.
-Matt
People should also remember that Intel's graphics strategy is to try to do it with a general purpose cpu rather than a dedicated graphics engine. This could be part of that strategy. With so many cores available a system can simply dedicate a few to particularly important jobs such as rendering.
-Matt
I remember having to physically hold a seagate drive in my hand and twist it back and forth while I turned on power to get it to spin up. And then another time I had to take the case off and move the disk with my finger to get it spun up, then race against time to read the data off before the media failed. Oh yes, fond memories indeed :-)
The problem with backups is making sure they'll actually be there for you when you need them. This precludes most offline mechanisms using media not designed for offline storage (hard disks, DVDs, etc), leaving two options: (1) Use tape or (2) Store the backups online in multiple places so you know when the storage fails and can replace it.
Tape is a terrible online storage medium (it just takes too long access data and wears the tape out when you do access the data), but it is just fine for offline storage.
-Matt
Yah, but be careful. Write performance is virtually a non-issue in the SSD space. There's no point being able to write at a sustained 150-200MB/sec when the only real-world outcome of doing that is your SSD will wear out more quickly. Writes can be cached, so only long-sustained writes will actually impact system performance. If you are bursting a few hundred megabytes worth of writes your system ram can cache that trivially.
What matters the most is read performance.
-Matt
I find it unlikely because in the last decade or two it has become very important for programs to be able to know whether accessing a bit of memory is going to cause a long page fault / stall due to I/O, or not. Simply mmap()ing a file isn't good enough in a threaded environment (when running a threaded application) where the app might be holding locks through the memory access. At least not unless the application has very good locality of reference and can assume the memory in question will be well-cached.
That is, standard paging/swapping isn't an issue here, but mmap()ing large data sets and accessing them via the mmap is.
-Matt
Yes, absolutely. It takes away a significant chunk of the HD market for applications which do not require hundreds of gigabytes or terrabytes of storage, and also takes away a significant chunk of the HD market for high speed storage, and on top of that it also hits the DRAM market because SSD storage is significantly cheaper than DRAM for caching purposes (particularly when you also take into account the motherboard, footprint, and power resources required).
People who were buying big whopping servers with 16G+ of ram used mostly for caching data can now do the same thing with 4G of ram and a 40G SSD and get scaleable caching (just stuff a bigger SSD) out of it in a motherboard footprint which is 1/4 the size and 1/2 or less the power and half the price.
People who were putting together big RAID systems to deal with spindle seek times can now use a SSD to cache whatever the data or meta-data was responsible for those random seeks and now no longer need big RAID systems just for performance reasons.
For the most recent laptop I got I threw away the HD and threw in a smaller SSD, and the laptop screams.
etc. HDs aren't dead, they are still the best mass-storage solution when a large amount of storage is required, but a good chunk of their market is going to the SSD space. MLC flash isn't going to destroy the HD business. Maybe some future innovation (IBM's M-RAM?) will.
-Matt
It's the nature of the beast. If a company produces goods which are too high in quality their sales volume goes down (because nobody is replacing the item after a few years) and they go out of business. Well, not quite true but close enough. Either the company goes out of business in the high-volume low-cost commodities market *OR* they jack up their prices and go for the low-volume high-quality market. If they do that, of course, the product will no longer be considered a consumer good.
All consumer goods work this way. It's why China can sell cheap tool sets for $20 which crap out quickly and still compete with high quality manufacturers which sell the same sets for $200 (and which last forever). For example. It's why cell phones are not made in a robust fashion and the case physically wears out after only a year of use. It's why case fans use cheap plastic bearings which last MAYBE a year and can't be run at full speed for more than a month before dying, even though the computer itself will run fine for 20 years.
-Matt
That's what we're seeing. I think of an SSD more like an extension of memory and less like a hard drive. For mass storage the hard drive is the most efficient solution, and for performance the SSD is the most efficient solution. If you can fit the working data-set extracted from the HD onto your SSD you are golden.
Most servers still only use a 1GigE network link, which is only 100MB/sec. The cheapest SSD can trivially do 100MB/sec, so if the data-set fits you now have a server capable of saturating the link. Even the little 40G Intel can do 200MB/sec without breaking a sweat.
At 10GigE things turn around but even so 10GigE is only 1 GByte/sec, and even using 3Gb/sec SATA ports will get you there with only three or four small SSDs (about $500). People who don't want to be on the bleeding edge can simply wait another year when 6GBit/sec SATA becomes a commodity and SSDs capable of driving it do as well. Then you'll only need two devices to saturate a 10GiGE link.
By treating the SSD as if it were cache ram the whole $cost/Gb issue goes out the window. It no longer matters that SSDs have a 30:1 cost over HDs on a per-gigabyte basis. If you need a terrabyte of storage you buy a $100 HD (instead of a $3000 SSD). If you want a 32G data cache you buy a $115 40G Intel MLC SSD. Two different things which combine for really excellent performance.
-Matt
I've been running tests with the little Intel 40G MLCs. So far I am getting a durability run-rate of around 110TB (the drive is rated for ~40TB). That is, I'll be able to do at least 100TB worth of writes to this particular SSD before it wears out. That's actually quite a lot. Intel's specifications are very conservative.
MLC flash has approximately a 10,000 cycle endurance. It all comes down to two things: (1) How good the drive software is at combining dynamic and static wear leveling algorithms and (2) How friendly the OS is in writing to the drive. DragonFly's swapcache goes to great pains to generate large clustered writes to greatly reduce write amplification and write combining effects, and it seems to work very well.
Clearly the newer SSDs are doing a much, MUCH better job with the wear leveling than older SSDs did. They are plenty good enough now for most applications. Write endurance also scales linearly with drive size. That is, the cells still have a 10,000 cycle endurance but there are more of them available.
-Matt
Already exists. DragonFly + swapcache, with SSD configured swap (32G nominal on 32bit and 512G nominal on 64bit). It works very nicely with a 40G Intel MLC drive.
Of course, you'd have to run DragonFly :-). heheh. But that said I think most OSs have solutions. There's ZIL for ZFS (Solaris, FreeBSD), I'm sure Linux has something, and Windows 7 has something. The DragonFly solution is quite general purpose though and not tied to any particular filesystem. We use it primarily for meta-data caching for the millions of inodes on our servers.
-Matt
I agree. That consultant was either misquoted or is just pulling numbers out of his ass. There's no way an engine control system with fly by wire for a car could possibly require that much code. I very much doubt the codebase would even reach 2 million lines of code, let alone the absurd number that was quoted.
-Matt
I seem to remember this way back then. There was a big brouhaha about Silicon Valley companies hiring programmers as contractors in order to get around various employment rules (overtime pay, etc), and programmers essentially being employees because their so-called contracting work was basically full-time with a single employer for an extended period.
But it seems Congress went overboard in their zeal to reign-in the practice.
-Matt
I think you're missing the point. The SATA form factor is going to have much higher demand than any PCI-e card, period, for the simple fact that PCI-e is not really expandable while SATA is. SATA has a massive amount of infrastructure and momentum behind it for deployments ranging the gauntlet, small to large. That means SATA-based SSD drives are going to be in very high volume production relative to PCI-e cards. It DOES NOT MATTER if the PCI-e card is actually cheaper to produce, it will still be priced at a premium verses the SATA form factor due to the lack of volume and PCI-e will never achieve the same volume due to its lack of flexibility.
The fact that the form factor has volume demand means that many manufacturers can get a piece of a large pie by selling devices in that form factor. A larger piece than they could get selling PCI-e cards.
In addition, the competition in the space creates innovation. This is why we are seeing such a fast ramp-up in SSD performance and features. The SATA form is driving the ramp-up.
Yes, SSDs are hitting the 3Gbit SATA II phy limit. And your point is what? 99.9% of the installations out there don't actually need more bandwidth, so hitting the limit is not going to magically create more demand for PCI-e and other non-SATA solutions. The SATA phy standards will progress along with everything else. We'll have 6Gbit/s soon enough, and the delay is not going to have any real effect on SATA being the dominant form factor standard for the technology. The single port limit isn't even that big of a hurdle today since most motherboards have several SATA/E-SATA ports.
PCI-e based solutions will track the same lines as all other bus-card solutions have tracked: Low volume, premium pricing, highly-specialized, and non-standard drivers. If you are hoping to see SATA based SSDs disappear in favor of a PCI-e card you are in for one hell of a disappointment.
-Matt
Yah. And that's the one overriding advantage to SSDs in the SATA form factor. They have lots and lots of competition. The custom solutions... the PCI-e cards and the flash-on-board or daughter-board systems wind up being relegated to the extreme application space, which means they are sold for tons of money because they can't do any volume production and have to compete against the cheaper SATA-based SSDs on the low-end. These bits of hardware are thus solely targeted to the high-end solution space where a few microseconds actually matters.
Now with 6GBit (600 MByte/sec) SATA coming out I fully expect the SATA based SSDs to start pushing 400MB+/sec per drive within the next 12 months. If Intel can push 200MB/sec+ (reading) in their low-end 40G MLC SSD, then we clearly already have the technological capability to push more with 6GBit SATA without having to resort to expensive, custom PCI-e jobs.
-Matt
At least not the Colossus I bought. Write speeds are great but read speeds suck compared to the Intels. The Colossus doesn't even have NCQ for some reason! There's just one tag. The Intels beat the hell out of it on reading because of that. Sure, the 40G Intel's write speed isn't too hot but once you get to 80G and beyond it's just fine.
The problem with write speeds for MLC flash based drives is, well, its a bit oxymoronic. With the limited durability you don't want to be writing at high sustained bandwidths anyway. The SLC stuff is more suited to it though of course we're talking at least 2x the price per gigabyte for SLC.
--
We've just started using SSDs in DragonFly-land to cache filesystem data and meta-data, and to back tmpfs. It's interesting how much of an effect the SSD has. It only takes 6GB of SSD storage for every 14 million or so inodes to essentially cache ALL the meta-data in a filesystem, so even on 32-bit kernels with its 32-64G swap configuration limit the SSD effectively removes all overhead from find, ls, rdist, cvsup, git, and other directory traversals (64-bit kernels can do 512G-1TB or so of SSD swap). So its in the bag for meta-data caching.
Data-caching is a bit more difficult to quantify but certainly any data set which actually fits in the SSD can push your web server to 100MB/s out the network with a single SSD (A single 40G Intel SSD can do 170-200MB/sec reading after all). So a GigE interface basically can be saturated. For the purposes of serving data out a network the SSD data-cache is almost like an extension of memory and allows considerably cheaper hardware to be used... no need for lots of spindles or big motherboards sporting 16-64G of ram. The difficulty, of course, is when the active data-set doesn't fit into the SSD.
Even using it as general swap space for a workstation has visible benefits when it comes to juggling applications and medium-sized data sets (like e.g. videos or lots of pictures in RAW format), not to mention program text and data that would normally be throw away overnight or by other large programs.
Another interesting outcome of using the SSD as a cache instead of loading an actual filesystem on it is that it seems to be fairly unstressed when it comes to fragmentation. The kernel pages data out in 64K-256K chunks and multiple chunks are often linear, so the SSD doesn't have to do much write combining at all.
In most of these use-cases read bandwidth is the overriding factor. Write bandwidth is not.
-Matt
Sigh.
--- Matt starts working on Opera Viruses.
-Matt
We're adjusting our disklabel64 utility and kernel support to set the partition base offset such that it is physically aligned instead of slice-aligned, and we are using 32K alignment. That should fix the problem without having to mess around with fdisk.
The DragonFly 64-bit disklabel structure uses 64-bit byte offsets instead of sector addressing to specify everything. It ensures things are at least sector aligned but we wanted to make disk images more portable across devices with potentially different sector sizes. The HAMMER fs uses byte-granular addressing for the same reason, 16K aligned.
-Matt
Robot Chicken.
Oops, that was two words.
-Matt
Well, VbV's security issues are a problem for Visa to solve. It's great for merchants who sell high-priced items (like NewEgg, camera stores, etc). Many smaller merchants who had to go through a whole back-and-forth thing with the customer and credit card company before (for large, expensive orders) can now just use VbV for the same high-priced purchase instead. Higher volume merchants like NewEgg can streamline their credit checks with VbV and even allow shipments to addresses other than the billing address.
I'm not sure why people are saying that it transfers liability to the customer, it doesn't. The liability is transfered from the merchant to the Visa (well, actually the issuing bank I think). Customers are not liable for fraudulent use of a credit card by VbV or anything else.
-Matt
I build new boxes every 6-8 months or so and rotate them into production boxes to make room for the next set. Until recently the Intel chipsets were ahead of the game vs the AMD chipsets with regards to things like E-SATA, AHCI, and PCI-e. AMD has caught up in the last 8 months, though. High-end Intel cpus tend to be a bit faster than high-end AMD cpus and you can also stuff more memory into small form-factor Intel boxes vs small form-factor AMD boxes.
On the flip-side, AMD boxes tend to be cheaper all-around and aren't quite so gimicky when it comes to managing cpu speed vs heat dissipation. Whole systems based on AMD seem to eat less power and from a cost standpoint when running systems 24x7. Power is getting to be quite important.
If you are trying to create the fastest, highest-performance box in the world Intel is probably your game (and for graphics you are going to be buying a 16x PCI-e card anyway with that sort of setup).
If you ratchet down your expectations just a bit, however, you can slap together a very good box with AMD at its core for half the price and 85% of the performance, and that is going to be plenty good enough for just about anything considering how overpowered machines have gotten in the last few years vs what people actually run on them.
Personally speaking I see no point purchasing the absolute bleeding edge when it is just going to become non-bleeding edge in 8-months when I can instead purchase two of something just slightly behind the bleeding edge at a much lower price.
These are just my observations.
-Matt
I've been a sailor most of my life. We haven't used Loran C seriously for almost two decades. Most boats don't even have Loran receivers any more. It's GPS all the way whether you are a casual sailor or a commercial ship captain. In fact, large commercial ships are required to use GPS and special transceivers these days (the boater's equivalent of GPS-based aircraft systems). If backup matters one could pack a RDF or maybe even a sextant, but frankly GPS has not failed even once from the day it became available to boaters. Besides, Loran C pretty much only works near the coastline of major industrialized nations (or did)... it wouldn't be all that helpful if you were lost at sea.
The coast guard should have abandoned Loran C years ago.
-Matt
All it really means is that products which currently require large amounts of rare earths will continue to evolve and require less of the stuff over time. This has in fact already happened to some degree with mature technologies such as catalytic converters. The same thing will happen with newer technologies. An increase in the cost of rare earth materials will also push nanotech development over time, in particular nano-featured surfaces.
So it is hardly a catastrophe.
-Matt
California is basically the only reason we have efficient washers and dryers, wallwarts with switching power supplies instead of transformers, consumer electronic devices which actually have low power modes, and vehicle requirements that vastly improve safety and mileage over federal standards. It has all been beneficial in reducing per-capita energy consumption (and water consumption too when it comes to washing machines).
The problem the U.S. has is that most people can't see beyond the end of their nose when it comes to shaping policy. It's really unfortunate that the Feds can't get their act together and it takes action by a state like CA to actually get something done. It's doubly unfortunate that CA regulations designed to give industries upwards of a decade to make changes aren't allowed to take effect until the very last minute by idiot politicians who think they are doing industry a favor when all they are really doing is making our industry non-competitive with other countries and creating massive shocks to the system that are totally unnecessary.
-Matt
You have to ask yourself, what do you need that kind of speed for vs a more portable, hot-swappable, and likely longer-lived SATA/E-SATA standard? Maybe a transactional store for a database, but that is pretty much it. A PCI-e style interface would be relegated only to those situations where extreme performance is required. Such devices will always be priced at a premium over their SATA counterparts simply by virtue of their lower volume production.
I do have an interest in how well a SSD could be used to expand the effective physical memory for a machine under load. Say, for an applet server. Another possible use would as a disk cache fronting slower multi-terrabyte HD storage. A PCI-e based device might be an improvement over SATA for that sort of thing though probably not enough of an improvement to justify the difference in cost. The real limitation to using a flash device as another caching layer is not performance but instead wear on the flash chips.
-Matt