Slashdot Mirror
Intel's Braidwood Could Crush SSD Market
Lucas123 writes "Intel is planning to launch its native flash memory module, code named Braidwood, in the first or second quarter of 2010. The inexpensive NAND flash will reside directly on a computer's motherboard as cache for all I/O and it will offer performance increases and other benefits similar to that of adding a solid-state disk drive to the system. A new report states that by achieving SSD performance without the high cost, Braidwood will essentially erode the SSD market, which, ironically, includes Intel's two popular SSD models. 'Intel has got a very good [SSD] product. But, they view additional layers of NAND technology in PCs as inevitable. They don't think SSDs are likely to take over 100% of the PC market, but they do think Braidwood could find itself in 100% of PCs,' the report's author said."
When given similar performance but a slightly higher price, i would prefer the SSD. I can't take the flash to the next PC as i can do with the SSD. Hard disks have a highe life expectancy than mainboards (i usually find some good use for old HDs, i never did for old mainboards). Unless the SSD will cost 2-3 times as much as the flash on the mainboard, i believe SSDs will still be used. But maybe this will lead to lower SSD prices.
I mean, why not put cheaper DDR RAM on the motherboard, with a big capacitor or battery to allow it to flush all writes out to disc when the power stops?
In fact, why bother putting ram as an IO cache when you could add the RAM to the motherboard anyway and allow the OS to cache writes. Intel - stop thinking like this, and just hand out free 1GB DRAM sticks with every motherboard, job solved.
Sooner or later, no moving parts beats moving parts. The magnetic disk makers have done an amazing job so far, but eventually they're going to lose out to solid-state.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Now only if they could start following the server side folks and place an internal USB connector inside and then MS and others could give us the OS on its own usb drive (read only) and we could use the hard drive for updates and programs we could enhance the security as well...
Life is but a Beta test...
What does it do, scream "Nooooooooo!" and throw itself underneath the hard drive in slow motion?
If you were blocking sigs, you wouldn't have to read this.
I really don't want to contemplate having my boot volume on a USB device.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Sounds like a good plan. Throw cheap battery backed memory, 4-16Gb onboard to act as a transparent buffer between harddrive(s) and system.
Fast IO is ensured as most operations happen in memory, and dataloss isn't an issue as the memory is battery backed.
RAID cards have done this for ages, but it's becoming real option for desktops as memory price keeps declining.
16Gb might be overkill for most purposes, you could get away with 2 if the system is used only for low-power tasks like surfing and email.
There are no atheists when recovering from tape backup.
The article is bullshit! Random I/O is essentially uncacheable. I don't think the onboard cache will be 128-256GB in size, so tyvm but I'll stick to using a ssd.
The important performance aspects of the SSD is: random read, random write, sequential read, sequential write in this order.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
There have also been rumors, however, that Braidwood has been canceled, at least in the near term:
http://www.dvhardware.net/article37368.html
If the onboard flash is a cache, that means it will be used frequently do it will wear faster. Won't that mean you're more likely to corrupt your data, even if your HD is still good ?
If intel has made an SSD that dont wear out ffs sell them to me now. If not, then stuff that cache somewhere the sun dont shine and come up with a better solution.
HTTP/1.1 400
finally! /dev/hdbraidwood
if the competition moves more things to dedicated on-board hardware, that will be fun for the rest of us!
Looking forward to
Funny - this very thing was being discussed around 1985 (I think), but using battery-backed RAM as a way to reduce boot time. The thinking was people wouldn't put up with a computer that took 30 seconds to start, and if we didn't have a 2-5 second boot time (equal to a TV), the personal computer would never fly. But since it took from 1985 (80386 chip) to 1995 (Windows 95) for a 32-bit OS to become popular, maybe 25 years is reasonable.
Or not. Man, this industry moves at a snails pace in a lot of areas. Why do we still live with the x86 instruction set. Is "the year of UNIX" here yet?
Anyway, three competitors will emerge:
- Someone will put NAND directly on the drive, and get an instant speed improvement. All the tech sites will rave about it and it will be an instant must-have item.
- Their competitor will figure out a way to put the OS files in NAND, for fast booting, via a utility or firmware. The marketing war begins.
- The third competitor will work with Microsoft or Apple to get OS support for fast boot. Apple will get there first and you'll see a commercial on TV with the Mac guy wondering why the PC guy takes the entire commercial to wake up.
In a single drive system, the cost will be about the same. Doing it on the drive will create an instant performance boost on any machine, and well worth the estimated $10 added cost.
Place nail here >+
there is a finite time before changed data are permanently stored even on this new SSD menory. Furthermore that time can be quite large depending on the OS and file system design.
If you flush and sync the file in the thread that writes the file, you can be sure that "[t]he fsync() function does not return until the system has completed [writing data] or until an error is detected." By "that time", do you refer to the time that the program blocks on fsync()?
Memristors?
Why a USB connector ? That causes the same problem as making SSD cards use the SATA interface - the serial interface becomes slower than the things it is connected to.
What I would like to see is a set of sockets on the motherboard, mapped into the main memory address space (not PCI), a physical switch on the board to make them read only and software in the BIOS to make them look like a bootable disk.
Four sockets with 16 or 32G in each would give you enough space to store the entire OS. I don't know how Windows would handle it, but in a Unix or Linux based system it would be fairly easy to mount the devices as read only partitions and map them into the filesystem. This would be ideal for a server system, mapping the entire OS into the main memory address space and making it read only.
In fact all the BIOS would need to do is make the first 100M visible as a boot partition, and leave the OS to handle the rest.
From TFA: "Braidwood, which is expected to offer anywhere from 4GB to 16GB capacity, ..." - In what way would it even compete with the SSD market? I'll stick to my separate 250 gig SSD drives for a while longer methinks.
I RTFA and still fail to see how this will "erode the SSD market". For example, I have a drive with 100+ GB of data on it (music, photos, documents, source code, backups)... my interactions with that drive are completely random and unpredictable. Yes, you COULD cache the entire source code folder when I start up my IDE, but what if I want to listen to some music on shuffle while I'm doing that, or add an image file from the photo directory to the source code... there goes the caching strategy.
When comparing that cost increase with the overall cost of a brand new PC it doesn't raise any red flag. Nonetheless, what it must be said is that, as this brainwood technology "resides directly on the motherboard" (i.e., it's yet another component embedded in a motherboard) , this technology will increase all motheboard cost by $10 to $20. That means that this brainwood technology is an excuse to ramp up current motherboard prices from around 20%.
Call me old fashioned but I prefer my hardware cheap without any unnecessary bells ans whistles. In fact, is this technology even capable of doing what the marketing blurb states it does? Nowadays it's hard to purchase a HD with capacity less than 200GB. Is a 4GB buffer really capable of successfully buffering all that data?
Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
Yeah right
This used to be a huge PITA before GRUB supported UUIDs as groot values. It was an even bigger one before Linux would do it. On Windows you need special tricks, because Windows doesn't like to be installed there; it works on some netbooks with "special" BIOS. I think the specialness is at least partly from their EFIness but I'm just kind of firing in the dark here. I have a 4G Surf and an Aspire One, both will allegedly play this trick. Actually, I have a DT Research DT366 which seems to have some sort of USB disk emulation mode also.
I have used a SDHC in SD adapter (16GB Sandisk) as root for Linux on both the above systems and aside from some slowness (~5 MB/sec, but the 5200rpm disk in these systems is pretty damned slow anyway) it works great. I used XFS as the root, it plays well with such devices as far as journaling filesystems go. So this is actually a flash card in a multi adapter on the USB bus in both cases, and worked great. I have also installed a 4GB Sandisk flash into the internal USB port on an add-in card in my desktop system and used it for ReadyBoost, but that system now runs Jaunty. Having more bootable devices increases boot time, so I just boot from the disk. It would be easy to mirror /boot to flash but there's little to be gained speedwise by doing so little. If you union mounted a flash volume with files needed at boot over the actual boot volume... eh, now I'm just being silly.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The buffer should obviously be on the hard disk. That way the data on the disk will always be in sync, even if there are writes buffered in the flash cache when the computer loses power. I can't see a good reason to put it on the motherboard instead. Especially as most consumer systems have exactly one HDD.
The article says that the flash buffer could work for "all system io". I can only think of optical disks and flash drives possibilities other than hard disks. But optical disks are interchangeable, so they have to be reread on each use anyway, and could just as well be cached in RAM. And it makes no sense to cache flash drives in flash cache...
I want all persistent memory to be detachable or write-protected in hardware. If you want to add something, how about adding a jumper for the write enable line of the BIOS flash memory chip?
On Windows you need special tricks, because Windows doesn't like to be installed there; it works on some netbooks with "special" BIOS. I think the specialness is at least partly from their EFIness but I'm just kind of firing in the dark here. I have a 4G Surf and an Aspire One, both will allegedly play this trick. Actually, I have a DT Research DT366 which seems to have some sort of USB disk emulation mode also.
Basically, it just needs to appear to the OS as a "fixed disk" rather than a "removable disk".
Why would you need 4x16G for the OS - Vista doesn't even take up that much...I was thinking of starting with around 8G for Windows and uses a union FS to map Windows updates over the original files.
No user programs here - interface-wise I wouldn't care that much - USB is everywhere and slow, but drop in SD or compactflash and I'm ok. More of purchase an OS on flash drop it in and nothing can touch it - if I need to wipe no big deal just rebuild the config files and clean out user data, and no more friggin programs writing files into c:\windows...
Life is but a Beta test...
I'm not married to USB CF or SD would work - something semi-portable would be for the best - as I would like to see the OS and OS only on the flash memory - maybe a couple gigs of that space wwould be writable for config files...
Think boot/OS disk...I'm all for speed, its just that USB is everywhere.
Life is but a Beta test...
What I would like to see is a set of sockets on the motherboard, mapped into the main memory address space (not PCI), a physical switch on the board to make them read only and software in the BIOS to make them look like a bootable disk.
The one issue, here, is one of address space. Unless people do a wholesale migration to 64-bit, it won't be possible to simply map the address space of such a device into memory.
Databases and the like can often write the same block multiple times in succession over a long period only the most recent needs to be written to disk.
But each write still needs to be written to a non-volatile journal; otherwise, the database is not durable.
one doesn't control the fsync behavior of every application running on his/her system
Users can choose applications that properly sync, or in the case of free software, they can put fflush(fp); fsync(fileno(fp)); in strategic places and recompile. Braidwood, which appears to implement a nonvolatile ring buffer for writes, should make it less painful for application developers to sync when appropriate.
By the way that was a sloppy application coding problem
That, and the fact that fsync() doesn't provide any sort of reasonable performance guarantees. Some of the slowdowns of Firefox 3.x on netbooks are due to an SQLite COMMIT (which calls fsync()) taking several seconds to flush writes to a cheap HDD or cheap SSD. That's one thing this Braidwood chip is intended to correct.
Hybrid drives are a few years old, but apparently not very popular.
Samsung makes some with 256 MB of on drive NAND flash.
I do have to question the effectiveness in multiple drive scenarios. And they talk about 4 GB of space - how do you avoid getting your page file stored on it? And how quickly will the 4 GB be worn out and read only? From the latest AnandTech article on SSDs:
7 GB of data, 4 GB of space to store it. And since it's only going to be used as a sort of intelligent cache, you'll have a lot of erasures, as you'll be moving data off of the cache onto the harddrive to make room for new stuff, and back onto the cache again.
They say they'll use SLC, but how quickly will the OEMs demand MLC for lower end models and thus cut the number of write cycles by 10?
And at what point can you be certain that the document you've been working on for several hours a day for the two weeks is stored on the laptop's harddrive and not on the cache? It's bad enough when your laptop dies on you and you have to send it in for repairs, but if you cannot be certain that your data is safely tucked away on your removable harddrive ... especially if it's the motherboard that developed a failure.
It's a nifty idea, but for stuff like this I'd be worried about data safety more than performance gains. I can get performance gains by putting an SSD into my laptop right now and I know that I can remove the SSD again if the computer needs repairs.
Why do we still live with the x86 instruction set.
Three reasons:
This is why I keep hoping someone will produce a complete computer architecture designed to be virtualized, so that I can genuinely run Windows and Linux (for example) and have both have access to the hardware. I'm tired of deciding who can access the video card. On a system with unified memory it seems especially silly that I can't do this gracefully.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
If the onboard flash is a cache, that means it will be used frequently do it will wear faster. Won't that mean you're more likely to corrupt your data, even if your HD is still good ?
NAND flash chips are generally guaranteed for at least 100,000 erases per block. As I understand this Braidwood chip, it's a non-volatile ring buffer for data writes. Ring buffers are the easiest thing to wear-level, meaning you can just multiply the cache capacity devoted to writes (let's say 2 GB) by the longevity guarantee to get 200 TB of buffered writes before any failure occurs. And not all blocks on a flash chip fail after the same number of writes; you'll just start to lose ring buffer capacity over time.
If you're going to flush/sync after every write, you might as well not have a write cache at all.
And if you're not going to flush/sync after every write, relying instead on a volatile write cache that may or may not get committed before power loss, you might as well not have files at all. But with a nonvolatile write cache like Braidwood, on the other hand, half of a sync can happen before power loss and half after. Writes doesn't have to wait for the hard disk to spin up; instead, they can proceed, and the OS will spin up the hard disk when it's ready to commit.
I have an SSD for increased reliability, heat ans shock resistance on some of mu data. This mainboard-contraption does nothing in that direction.
Also, depending on usage patterns, it should be far, far inferiour to memory buffer-cache. I think this is a publicity stunt.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Is this the latest FUD? That if a company brings out a successful product that's priced cheaply it'll "erode the market"?
How did the :"market" become so sacred that it must be preserved at all costs by keeping prices high? It's really funny the crap that'll come out of an MBA's mouth. He'll be all for "free markets" until someone comes along with a better product and then he'll start to squeal that the "market" is under siege.
Good for Intel.
You are welcome on my lawn.
I would prefer to see my O/S be able to decide how to use this cache.
If the caching logic is all hidden behind some naive firmware caching algorithm, presumably you are not getting the best caching for your workload - which the operating system will have a better idea of. Algorithms only improve over time, who is to say the firmware algorithm will be the best (and updated in the future)?
Would the $10-20 dollars be better spend on a dumb PCIe (or better) flash device. I'm guessing yes.
"- Someone will put NAND directly on the drive, and get an instant speed improvement. All the tech sites will rave about it and it will be an instant must-have item.
- Their competitor will figure out a way to put the OS files in NAND, for fast booting, via a utility or firmware. The marketing war begins. - by MasterOfGoingFaster (922862) on Friday September 04, @08:50AM (#29309875)
I use TRUE SSD's in this manner here (the kind that use PC-133 SDRAM or DDR-400) for performance gains:
----
1.) Pagefile.sys placement
2.) WebBrowser Program Caches (all of them in IE, FireFox, & Opera) - &, on an NTFS compressed partition, so the files are even TINIER & pickup that much faster into memory (small offset due to decompression of data into memory, but, today's CPU's & RAM speeds make up for that)
3.) OS and application logs (like eventlogs & far more from apps + the OS also) - again, on an NTFS compressed partition, for the same reasons as above.
4.) %Temp% &/or %tmp% environment alteration (so app & OS 'temp ops' take place in a higher speed environs & off the main disk too)
5.) %Comspec% placement (cmd.exe on Windows NT-based OS')
----
The performance gains I see are:
----
A.) Faster seek/access to said files, especially since they're small & OF BOTH "READ/WRITE NATURE" (which normal RAM types FLY on, vs. FLASH, & no "writeback caching" required really).
B.) A lot less "read/write head movement contention" on my main OS + Programs bearing HDD's, simply by moving said files + activities from my main HDD's
C.) No fragmentation of my main OS + Programs bearing diskdrive from said activities &/or files I moved from my main OS + Program bearing HDD's
----
It just works... some ideas/"food 4 thought" on this note, in addition to your statements (which ARE other "possibles" here).
PERSONALLY? I think we're being sold "FLASH" ram, for what many folks here noted - in 'planned product obsolescence'... & the future of these units?
WELL - I think that 64-bit capability will LASTLY "usher in" drives like I use here: "REAL RAM" on them (DDR etc.) instead of FLASH - so you have longer life (the CENATEK I am using has been going strong on read/write tasks since 2002, no hassles, for example, but has a 4gb per board size limit (16gb when 4 boards are striped/spanned though).
Well, that is once drivers for the kinds of SSD I use can go over 4gb memory addressability? Then, & ONLY THEN, will we be using these units to their FULL capability, AND performance potentials... w/out the need for "wear levelling" or "garbage cleanup" processing occurring, nor the limited lifespan of FLASH units, vs. ones that use "TRUE RAM", as the ones I do, as examples today (but, which are limited to 4gb per board memory onboard due to 32-bit driver nature on them)
(Call it a "hunch"... as to what I think the future is on these units, & it's NOT "FLASH" RAM based, not when high-end performance is concerned, and when 64-bit becomes more "mainstream"...)
APK
P.S.=> Been "into this stuff" since the days of the software based RamDrive (circa 1991-2001, when I wrote one myself (APK Ramdisk) & later did work for EEC Systems/SuperSpeed.com & their ramdisk softwares), & later I got "into" Solid-State Boards (2002, via the CENATEK RocketDrive (2gb PC-133 SDRAM, PCI 2.2 133mb/sec. bus transfer rates) & more currently using a faster one called the Gigabyte "IRAM" (4gb DDR-400 RAM, SATA 1 150mb/sec. bus transfer rates) & they work for things like the above + how I use them, for better overall system performance (better than HDD's do, due to less latency & tremendous access/seek speeds, especially w/ smaller files) - &, yes, I can "keep state" between boots (CENATEK's unit has a backing power supply, & the GIGABYTE unit has a Lithium Ion battery for that), & can even boot up from the IRAM, but I choose not to (WD Velociraptor, 2 WD "Raptor X's", a 74gb Raptor, + 36gb Raptor as my 10,000 rpm disks I use here, they're all quite quick is why & larger) is all... apk
Unless you are making some extremely teoretical scenario, in which case the I/O is not really random anymore, you will still statistically hit some data in cache and you will hit more the more cache you have vs. data. For instance, if your cache i larger than the data, then random I/O will be 100% cacheable... Also, while the read might have low cache hit rates (which is more correct than saying it is not cachable), a NVram cache can still give you great benefits on writes as it might open for better write scheduling. That is, you can delay the flush to disk and coordinate that better with head movements which can significantly speed up things.
long enough to exceed the lifetime expectancy of the flash?
* Winners compare their achievements to their goals, losers compare theirs to that of others.
http://hardware.slashdot.org/comments.pl?sid=1357803&cid=29311441
I would want any on-mobo items to outlast the computer, or at least degrade gracefully.
In certain environments, pinning should help with wear-level. For example, in servers, pinning files that load at boot or pre-loading files likely to be needed at boot during a non-reboot shutdown will speed up boot-time, and on any system good cache management systems that are aware of what causes human-perceptible delays and what doesn't will help as well.
In a human-in-the-loop environment to help guide decision-making, multi-boot environments can pin boot-time files for multiple OSes in the cache, making it faster to swap between OSes.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Most motherboards already have internal USB headers.
I suffer from attention surplus disorder.
Just add the extra 32GB of RAM to the OS, and let it more intelligently manage the data.
I want to delete my account but Slashdot doesn't allow it.
okay so "NAND flash will reside directly on a computer's motherboard as cache for all I/O and it will offer performance increases and other benefits similar to that of adding a solid-state disk drive to the system" to me means that they're adding a big 1GB, high speed flash cache chip to the motherboard. Like you're writing a file to the hard drive and it goes straight to cache and says "okay, finished" then slowly sends it to the hard drive. That would simulate SSD write speed but only on the surface.
Okay, so who wants a 30 second delay between when the file says it's done trasnfering/copying/saving and when it's actually on the hard drive? Write caching is a horrible idea that corrupts hard drives and loses files if you power off at the wrong time. Get one of those on your motherboard and you're basically guaranteed to never, ever be able to force shutdown or restart it with the instant restart button on the front of your case. Technically any data still on the flash chip would be saved and could resume transferring to the hard drive when you power back on but the file it was currently working on just got split in half on the hard drive!
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
You wrote "Or not. Man, this industry moves at a snails pace in a lot of areas. Why do we still live with the x86 instruction set. Is "the year of UNIX" here yet?"
Actually, when you are in 64-bit mode, you are most certainly not using anything like the classic x86 instruction set. There are many more registers, and the limitations on specific register uses are mostly gone. x86-64 very much changed things for the better.
I STILL don't find anything to rant and rave about when people start talking about SSDs....having worked for a fair while as IT technician I've seen some Netbooks come in with major hardware failures and when they're in guarantee we have to send them off to Acer elsewhere in the coutry, and they have a "I don't give a crap about your documents" policy that means that they format your C:/ Drive also meaning if the customer has documents that need saving we (currently anyway) don't have any way of recovering those documents from a SSD. ...just thought you'd like to know if your computer habits usually end in visits to IT Assistance...
this is a virtual insanity that always seems to be governed by our love for this useless twisting of our new technology.
Would you have to open the computer case every time you installed an OS patch? If so, would that make your system more or less secure?
Expected time to finish is 1 hour and 60 minutes.
This will have minimal impact on the adoption of SSDs ( well for smart consumers ). What it might do, is reduce the amount of RAM
that gets installed by default. 4-16 GB is ridiculously small as a substitute for mass storage but right up there with volatile RAM.
Also, the best way to speed up a system is to increase the performance of the slowest subsystems ( especially if they're heavily used).
Right now, that would be magnetic, rotating hard disks. And, Intel is not so stupid as to undercut one of their own products that's
clearly better than any competing product at the moment.
Pain is merely failure leaving the body
in a Unix or Linux based system it would be fairly easy to mount the devices as read only partitions and map them into the filesystem
That sounds just like Asus's Expressgate: a Linux OS on the motherboard independant from the main OS
I run Ubuntu server as a NAS, booting from an 8GB Patriot XPorter. Not fast, but easily fast enough for what it's doing, and one less noisy hdd giving off heat. I can't say I would hope to do that for desktop use though.
I am literally 3000 tokens away from the chaotic crossbow --Stephen
What's new about this exactly? I have I2O controllers with on-board cache from ten years ago, and we had RAM-based PCI cards for caching back in the nineties on some servers I administered.
So now Intel's just integrating a cheaper I/O cache into the backplane ... flash instead of RAM ... big deal, and hardly innovative. Its also not going to help streaming data speeds at all, which will always rely on spindle speed, nor random access of changing data for that matter, only data that can be cached -- which is why we've been doing RAM caching for all these years.
- Michael T. Babcock (Yes, I blog)
"It does look like a much better idea though." - by Anonymous Coward on Friday September 04, @01:45PM (#29313683)
Thanks - It works, & very well... I just listed some "alternate ideas" for others here to "latch onto" & perhaps even extend...
----
"That doesn't improve boot time." - by Anonymous Coward on Friday September 04, @01:45PM (#29313683)
It could (IF I elected to boot up from the GIGABYTE IRAM True SSD, which can do that (my CENATEK True SSD cannot though))
I just don't elect to do so since my system was setup pretty much perfectly, already, by the time I got the GIGABYTE IRAM - so, no sense redoing a machine that runs & has run WELL, since early 2006... & again - The GIGABYTE IRAM's the ONLY bootable SSD I have.
----
"And it doesn't involve the Flash being placed in the drive." - by Anonymous Coward on Friday September 04, @01:45PM (#29313683)
I am not sure I understand your reply, but, I'll just state this again - there is no FLASH RAM on the types of SSD I use... The types I use in the CENATEK RocketDrive (PCI 2.2 bus 133mb/sec. transfer rates + 2gb PC-133 SDRAM) & the GIGABYTE IRAM (SATA 1 bus 150mb/sec. transfer rates + 4gb DDR-400 RAM) don't use FLASH RAM - they use what PC's use on their mainboards/mobos, which is MUCH faster on writes especially.
APK
P.S.=> I would have noted DB work, because my work for EEC Systems/SuperSpeed.com was featured as a FINALIST @ Microsoft Tech-Ed 2001-2002 in the hardest category there: SQLServer Performance Enhancement, 2 yrs. in a row (because it works for database engines, & webservers as well)... again, as some "alternate ideas" for how/when/where/what gains in performance, bigtime, using SSD's... but, this exchange here seems more "end-user oriented" is all! apk
http://www.google.com/search?hl=en&source=hp&q=%22Is+Linux+UNIX%3F%22&btnG=Google+Search
Many of those search results tend to state that LINUX is a UNIX...
PLUS, over time, I have heard tell that Linux is indeed a UNIX (heck, it is a UNIX imo, that's where I started in this madness & lunacy: It surely IS a UNIX to myself @ least).
Well, amending that - Except that I personally think LINUX is a BETTER UNIX than most "classic UNIX's" are, & so is MacOS X (but, I respect Linux more)).
Question is though, is it OFFICIALLY (for whoever controls that, & honestly though? "So much for that" anyhow) a UNIX? I have honestly always wondered that myself, but, I am more of a "Win32 fanboy", admittedly (@ least since 1992 I have been).
APK
P.S.=> Apparently, the ONLY reason that Linux has not been (& this might not be true anymore/currently either & my source MAY be "stale"... I say that, because for SOME REASON, I recall that Linux was actually classified as a form of UNIX) officially classified as a form of UNIX, is because of some license fee that hasn't been paid to the Open Group, per this source for that much:
http://tldp.org/FAQ/Linux-FAQ/general.html#is-linux-unix
PERTINENT QUOTE:
"Q: Is Linux Unix?
A: Officially an operating system is not allowed to be called a Unix until it passes the Open Group's certification tests, and supports the necessary API's. Nobody has yet stepped forward to pay the large fees that certification involves, so we're not allowed to call it Unix. Certification really doesn't mean very much anyway. Very few of the commercial operating systems have passed the Open Group tests.
A: Unofficially, Linux is very similar to the operating systems which are known as Unix, and for many purposes they are equivalent. Linux the kernel is an operating system kernel that behaves and performs similarly to the famous Unix operating system from AT&T Bell Labs. Linux is often called a "Unix-like" operating system. For more information, see http://www.unix-systems.org/what_is_unix.html."
(Many of the other GOOGLE search query results tend to say much the same, & I feel that way myself, but... there is that "officiality" (is there such a word?))... apk
I'd have thought that without OS support whatever things braidwood magically decided to cache would also be cached by the OS. Looking at my desktop here it has almost a gig of memory used a cache. If I had a 2 gig Braidwood then half of it would presumably be wasted if it wasn't intentionally caching things the OS wasn't. I suppose you might get a one off improvement on boot but then again the boot process is probably going to hit a lot of files that aren't used thereafter and so won't be in the cache any more.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
This is something that I've been wishing we had some solutions for -- some multi-level cache whether it's like traditional hierarchical storage or not...
/var/lib/pgsql/data/pg_xlog on different spindles, and Linux will make use of excess RAM as cache, we don't really have the ability to make use of 80GB of SSD as just a straight cache for a 1TB drive.
While we do have some ability to do things like put the journal or
This is something I've been wanting to write, but just haven't found enough
roundtuits... I figure it could be implemented as a dm module in Linux
sitting in front of the back-end block device, with fancy data-structures
for handling infomration about what blocks to cache.
ZFS has recently added some ability to have the journal *AND* a cache device externally, but in my testing of it the performance really didn't improve.
I've also been thinking about the next generation of RAID cards... I can imagine them having some ability to augment their RAM-based cache with a much larger SSD. Volume X is just to be used as a cache for volume Y. Then you put 4 2TB spinning discs in as RAID-5, say, and 4 80GB SSD drives in as RAID-0 cache (if it's a read cache then all the data is redundant from the spinning discs anyway) or RAID-whatever if you are storing write cache information on it...
So who is going to get to market first? Intel with it's motherboards, or the RAID vendors? Adaptec already has a card with 4GB of flash on it, that it seems to just use as permanent storage for the RAM -- powered by a supercapacitor to give it the time required to write the DRAM to flash. They are pushing this as "A BBU that you never have to maintain". But I could easily see the fluash expanding to be much larger and being used to cache more.
Sean
"I HATED APK ramdisk...it had far too many problems and was just code based off of the standard MS code which gave it far too many limitations."
Your customers seem satisfied, LOL.
Your comments are prime examples of one of the reasons why I hate USB:
iNTEL sells it as a cure-all.
There is absolutely no reason at all to put that many hardware and software layers between the CPU and flash you're mounting (or socketing) on the motherboard. Built-in floppies, well, yeah, sort of. Maybe. (But I'd still rather the defacto standard for slow/small mass storage/IO devices to have been not so, well, braindead.)
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Let us all praise intel for getting yet another thinly veiled attention grab on slashdot!
(As noted already above.)
Or is it for putting their own product markets at risk to grow another product market? No, these are not competitive products, except in one particular application (boot media), as also noted above. (Not that you necessarily would have seen the comments above. I didn't check the posting times.)
Sure does seem to be a lot of misunderstanding about the purpose of this product. Not that I appreciate it that intel is building the chipsets for both the mobo and for the on-board bulk flash, without, apparently, publicly referenced standards (Or did I miss something?), but the basic idea is one whose time has come.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
The fan?
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
"and was just code based off of the standard MS code which gave it far too many limitations." - by Anonymous Coward on Friday September 04, @05:54PM (#29317793)
Software Ramdisks are ALL built from the same Microsoft DDK template, so you know... &, they're initially based on a FAT-12 filesystem (floppy type iirc? Not sure on this trivia anymore), iirc on filesystem, no less (hence the 32mb sizelimit, this can be overcome & discussions I had w/ ArSoft Ramdisk's designer turned me onto that much, how to beat the size limits, but... I moved on, to SSD's - REAL ONES, not the "plastic imitations" based on FLASH the thread here @ /. is talking about - but ones with much faster dedicated RAM (not shared like system memory))
----
"I HATED APK ramdisk...it had far too many problems" - by Anonymous Coward on Friday September 04, @05:54PM (#29317793)
Opinions + experiences vary -> http://72.3.248.187/bbs/t52080.html
PERTINENT EXCERPT/QUOTE:
----
"kenancy2000
Active Member Join Date: May 2003
Posts: 217
VERY EXCELLENT thread on hard drive setup and page/swap files!
See here...
http://www.ntcompatible.com/postprint137030.html
This thread mostly covers WinNT/2000/XP, but the principles probably could be applied to Win9x systems, too.
I will be trying this out for my rig in the next few days and report back if successful.
This thread has responses from Alec Staar, creator of APK RamDisk 4.
My initial question was about sectioning off part of a large system memory (like 512MB or 1GB) RAM and using it as a drive letter, and putting the paging/swap file there because RAM is so much faster than a hard drive. We answer that and several other important hard disk topics related directly to video editing performance.
From what I can tell, you can significantly improve the performance of not only your video editing by placing certain files and services off your main hard drive, but you can improve other aspects as well, like program launching and web surfing. The only drawback will be a little additional noise and heat generated by an extra hard drive or two - but with todays Fluid Bearing hard disks coming from most manufacturers these days, the noise is no so bad at all, and the heat issue can be overcome by choosing drives that are known not to heat up too much (I noticed my Seagate Barracuda IV drive (and probably the V models, too) is much cooler idle than my new Maxtor Series 9 drive is at idle, so there is a tip for you).
Last edited by kenancy2000 : 03-18-2004 at 02:25 PM."
----
(HEY - Still: The person you quoted may have a point & that might be possible though, as I have not looked @ or tried it (even here) in years (too small @ 32mb size limits (Fat12 is why), & on Windows Server 2003 let alone 2000 or XP on service packs + hotfix patches also (they can change a LOT of things & there IS the LEGACY DRIVER registry areas to worry about here in this situation, possibly, in regards to installing this software based MS-DDK driver + GUI combination, after you have put in service packs &/or hotfix patches))...
So, I am not even sure if it will run with current Service Pack Patch Levels, in other words!
IF you were to install it? Do it on a FRESH unpatched model of an OS (2000/XP)...
See, if you do not install it from the "get-go" with an UNPATCHED model of the Operating System nowadays in fact, to be quite honest about it, it may not work (LEGACY DRIVER ENTRIES again etc. & all that comes with them).
So what you quoted, might be possible on today's fully patched distributions of Windows for all I know (I went hardware ramdisks & have not looked back since, much less maintenancing an old ware I wrote)... that might be something that pe
Where's the Funny?
What about jokes like: "I -wish- I was long enough to braid -my- wood!" ?
Come ON guys!
"What I mean by that is, that this discussion is about something fundamentally different from what the original poster described. Go back way up in the chain, someone was talking about some sort of SSD built-in to the HDD" - by MobyDisk (75490) on Friday September 04, @05:56PM (#29317809) Homepage
Ok, I understand your reply now: Yes, Seagate had such a drive, iirc (with an "SSD" of sorts, FLASH RAM based, "built into" the disk itself), & you're correct - it's a bit different here.
----
"But such a device cannot know about what files are in what directory, and cache them accordingly. It only sees sectors. Like for example, it could not know that files in the "temporary internet folders" directory doenot need to go to the permanent storage." - by MobyDisk (75490) on Friday September 04, @05:56PM (#29317809) Homepage
Good point, & point taken here: It'd work like a software diskcache does @ the DISK subsystem level (yes, there are such diskcaches, & the one produced by SuperSpeed.com (formerly EEC Systems) in "SuperCache I/II" is such an example), rather than the logical filesystem subsystem level (as Windows' own diskcache works & this is the level it works @)...
I.E.-> You're saying it wouldn't be as "intelligent", in other words, & thus (good example on YOUR part) not as efficient.
APK
P.S.=> I "strayed" a bit, noting diff. ways of using a SSD for superior performance, & via diff. kinds of SSD's (the type that use PC-133 SDRAM or DDR-400) as well (the type NOT affected by slower write cycles, & that doesn't need write-back caches to offset it, nor "wear-levelling" or "garbage cleanup" either)... &, it appears others "strayed" to noting drives w/ built-in FLASH RAM caches (&, I am pretty sure it was Seagate that made such a disk) - still, a lot of GOOD solid ways to use SSD units has been noted here by many, & that is what counts (trading tips/tricks/techniques on how to use them for that better speed)...
WHEW: Time for some "a.m. consciousness fuel", I think... (COFFEE!!!), lol... apk
The one idea I've not seen talked about that seems like it'd help magnetic disks is to just store the first megabyte or so in cache, so that the disk can seek to the next part of a file and read at whatever expected transfer speed. In other words, cache away the seek time and live with the transfer. It seems like a nice match for an SSD cache if the goal is to pretend you have a huge SSD storage but can't afford it. It'd stretch the cache across a whole lot more files, so that almost all files could appear to live in cache. Well, if the number turned out to be as high as 1 MB than I guess 16000 files could live in it, not accounting for smaller libraries that could fully fit within it.
pimtamf