Intel, Micron Boost Flash Memory Speed by Five Times

Lucas123 writes "IM Flash Technologies, a joint venture between Intel and Micron, announced they've been able to improve NAND memory and its circuitry in order to boost read/write speeds by five times their current ability. The new 8Gbit single-level cell, high-speed NAND chip will offer 200MB/sec read speeds and write speeds of up to 100MB/sec, which means faster data transfer between devices like solid-state drives and video cards. IM Flash Technologies plans to begin shipping the new chip later this year."

Faster USB needed

[flyingfsck]

This will be useful for solid state disk drives. Unfortunately USB is stuck at an effective throughput of about 28MB/s so it won't help for cheap external drives.

Re:Video cards?

[repvik]

Yes, video cards need fast RAM. If you haven't noticed, this article is about flash memory, not RAM. If you shove this crap into a video card, you'll be going a helluvalot slower than you are today ;)

Re:Faster USB needed

[ciroknight]

You're right. If only there was a new, faster USB standard that would be able to take advantage of these new data rates. They could call it "USB 3.0", or "USB SuperSpeed" or something. Oh Wait... [usb.org]

Re:Some interesting possibilities open up.

[Bloater]

LinuxBIOS was already down to 3 seconds

LinuxBIOS is now called coreboot [coreboot.org]

Re:Wonder when...

[Circle of Owls]

AMD had a flash memory division; it's flash ran alongside their logic products in Fab25, but took a backseat to them in both production and engineering. As a result, their flash technology rapidly slipped behind the market leaders. AMD then formed a joint venture with Fujitsu called Fujitsu AMD Semiconductor Limited (FASL) to jointly develop and market their products at about the same time that AMD was moving their logic line to Fab30. FASL was soon split from both companies into a separate entity, and renamed to Spansion. Spansion has been making significant progress to regain both the market share and technology that AMD's priorities lost for them.

Re:filesystem

[Anonymous Coward]

Most flash devices now spread writes to the device using the controller. There is no real need anymore for those kind of file systems. Yes, current devices use FAT. Anything supports FAT and it is easy to implement in small devices (e.g. camera's, phones etc). But you can just as easily put in NTFS, or EXT2/3.

Re:When it rains, it pours

[ColdWetDog]

One place this may really help is cameras. The shutter lag is still bad, and this might help.

If it's shutter lag that bothers you, get a decent camera. Today. Flash RAM isn't the problem here. ANY DSLR made in the past five years has quite acceptable shutter lag for most people. The higher end models have shutter latencies better than any "normal" camera ever made. There are even a couple of point & shoots with reasonable speeds. Check out the reviews on DP Reviews [dpreview.com].

Happy snapping.

Re:Give me better sekk times

[tlhIngan]

Try do random access on the next USB-flash stick you have access too.

That's a USB issue, not a flash issue.

The reason is that USB does things in transactions, and has to schedule all the transactions with priority. This is because of USB's fundamental flaw - it requires the host to poll devices. So a host will poll interrupt devices first, then handle isochronous transfers (bandwidth and time dependent traffic). Leftover bandwidth is then allocated to control and then bulk traffic. A USB host can do this once every millisecond, but most OSes break it out into more coarse granularity to avoid overloading the CPU when doing USB transfers. 10ms is about average for Windows, Linux is around 4ms. Basically, Windows will schedule all traffic on 10ms boundaries, so every part of a transaction will take place every 10ms. (10ms is a nice number because it means Windows can do the scheduling every timer tick).

If you do a USB disk request (read block N), the USB Mass storage driver will make a transaction to read a block. It will then issue the request to Windows' USB stack, which then add it with all the requests. If there's sufficient bandwidth in the next 10ms frame, it'll add the request to that frame. In the meantime, it's handling the current frame. When the next frame goes through, it sends the request, and if your USB stick is fast enough (usually is, but hard disks, it isn't) it responds immediately. If your USB stick isn't fast enough, then it will accept the request and wait for Windows to poll it again to see if there's any data, at which point the data will be transferred.

It's not the flash memory doing the seek (in fact, every time you access it, you "seek" it, it's part of the normal behavior) it's USB.