Slashdot Mirror
Asus Delivers Speed Boost With USB Attached SCSI Protocol
MojoKid writes "When USB debuted in 1999, it offered maximum throughput of 12Mb/s. Today, USB 3.0 offers 4.8Gb/s. Interestingly, modern USB 3 controllers use the same Bulk-Only Transport (BOT) protocol that first debuted in 1999. Before the advent of USB 3, relying on BOT made sense. Since hard drives were significantly faster than the USB 2 bus itself, the HDD was always going to be waiting on the host controller. USB 3 changed that. With 4.8Gbits/s of throughput (600MB/s), only the highest-end hardware is capable of saturating the bus. That's exposed some of BOT's weaknesses. UASP, or the USB Attached SCSI Protocol, is designed to fix these limitations, and bring USB 3 fully into the 21st century. It does this by implementing queue functions, reducing command latency, and allowing the device to transfer commands and data independently from each other. Asus is the first manufacturer to have implemented UASP in current generation motherboards and the benchmarks show transfer speeds can be improved significantly."
Asus doesn't inexpensively license the technology to other board oems. Not sure how much of this is software and how much is hardware, but if there is a special USB-SCSI command set that is separate from plain SCSI then they will need to be open and supporting on that front for all OS's as well.
like I like my women, FAST, WIDE and SCSI
When USB debuted in 1999, it offered maximum throughput of 12Mb/s.
Well, no, it didn't. It was based on 12Mb/s signaling rate, but delivered substantially lower actual throughput. There's a paper on the usb.org website that runs through it all, showing how the relatively large overhead of the protocol affects throughput.
No, Firewire (Apple's implementation of IEEE1394) would allow two external drives to talk directly to each other without going through the host.
This isn't even like SCSI, as there's no true DMA. It's more akin to NCQ. The benefits are there, if you use it for copying from RAM or SSD to USB. Otherwise, you won't notice much difference.
I'd much prefer ESATA myself, not the least because it can allow AHCI and TRIM, but also because it won't slow down if you use multiple drives simultaneously.
With UASP sufficient to provide a good disk interface, will new motherboards keep it simple and eliminate the SATA controller and ports? Will new internal hard drives simply have USB connectors?
According to Electronic Design,
So, a kernel could have a single SAS driver that supports all SAS, SATA, and USB block devices. This could be a marvelous convergence.
Opps, someone didn't do their home work. Sure there were not many USB devices until 98 and 99, but the USB wiki page says 1994. I remember buying my first motherboard with USB in 96.
ASUS's version of UASP is not very new. They announced it late 2011 already here: http://event.asus.com/mb/2010/the_best_usb3_experience/The_UASP_For_USB3.0.htm The drivers it requires are from October 2011.
With speeds now comparable to DDR memory, what's to stop blank USB sticks being used as a temporary RAM boost?
Please consider this account deleted, I just can't be bothered with the spam anymore.
This finally resolves the biggest problem for USB interfaces and hard drives for audio. The primary factor for performance in audio has always been access speed (seek time), and not throughput. Audio software has to access dozens of separate audio files in a very timely manner frequently, and the overhead of the USB protocol has always been a wrench in the gears. From what I'm reading, UASP offers the same advantages NCQ (Native Command Queuing) offers in SATA, which allowed for much higher track counts on the same drive rather than spreading files across several drives, which was a pain in the butt. It was only with NCQ in ~2005 that SATA finally caught up with SCSI-2 (ca 1994) in audio performance, provided the drive was 7200rpm or faster. Firewire has some form of queuing system built into the host, so it's always been better than USB for audio, but it is vanishing from laptops and desktop motherboards, even Apple products.
Now watch how long it takes before audio hardware manufacturers adopt it, and feel our pain. The first Firewire audio interfaces came out about 4 years after Firewire was standard on Mac desktops...
War as we knew it was obsolete
Nothing could beat complete denial
- Emily Haines
Just when I'm really, really tired of the acronyms, there's SCSI over USB. What's next, orange juice out of apples? Kia to Tesla conversion kits? Vegan outback steakhouses? Elegant Perl code?!
esata is just sata with some very very minor phys layer changes. its still sata.
and sata is identical to sas at the phy layer (controllers often can be used for both with diff firmware). ide, as we once knew it, morphed into sata and sata and scsi are now 'friends' in a way.
ahci is the 'real' form of sata. old compatible stuff was just that, running ide over over the sata phy layer.
trim exists whether you run esata or local sata. trim does need ahci (ie, true modern sata) but does not care or know if its internal or external.
just to clear that up a little..
--
"It is now safe to switch off your computer."
Thunderbolt will chew them all.
New Economic Perspectives
Yup, and they don't matter because any modern PHY is designed to support both interfaces.
thegodmovie.com - watch it
This isn't even like SCSI, as there's no true DMA.
I'm afraid this is wrong coming and going. Unfortunately it requires a rather longwinded explanation.
1. SCSI does not imply DMA. SCSI is, loosely speaking, two layers. One is a protocol layer consisting of a set of packet-like commands and responses. The other is a physical layer to transport the commands and responses. The protocol layer has no concept of host memory addresses -- it's just commands like "read logical block number 19235". DMA has no meaning there. As for the physical layer, the SCSI specification only covers the physical SCSI bus, not the host controller which interfaces it to the computer. It is entirely possible (and was once common) to design SCSI host controllers which use PIO rather than DMA.
Today, the most common form of SCSI encountered in the real world is the protocol layer, transported across a non-SCSI physical layer. Even the most common "SCSI" physical layer (SAS) is actually a physical layer design borrowed from SATA.
2. Just like SCSI, USB DMA is a function of the host controller design. Unlike SCSI, every version of USB has had standard host controller designs. (USB1: UHCI, OHCI. USB2: EHCI. USB3: XHCI.) All the USB *HCI designs include DMA functionality. So, it's actually very uncommon for USB to not use DMA. (Yes, USB can have high CPU overhead. This doesn't imply there is no DMA going on.)
3. All USB Mass Storage Devices (whether lowly thumb drives or high end HDDs/SSDs) are SCSI, not just the new UASP ones. The USB Mass Storage class is simply a standardized method of using a USB bulk endpoint to transport encapsulated SCSI commands. The chip at the USB device end usually implements a SCSI/ATA translation layer too, since most disks are ATA or SATA.
(That translation layer is why things like TRIM and SMART often don't work over USB -- old USB Mass Storage Devices tend to only translate the basic SCSI commands required to support reading and writing data. There are newer developments which define how to pass SMART through a USB-SCSI-ATA bridge; if you have a more recent USB disk or disk enclosure you may be able to use standard SMART utilities like smartmontools. (I've done this with a SATA disk in a USB2 enclosure.) I wouldn't be surprised if UASP makes this standard and extends it to include TRIM passthrough, but I haven't read up on UASP in detail yet.)
I'd much prefer ESATA myself, not the least because it can allow AHCI and TRIM, but also because it won't slow down if you use multiple drives simultaneously.
Accessing multiple drives simultaneously is a problem for ESATA too. Whenever you use a single SATA or USB channel (through a port expander or hub respectively) to talk to multiple drives, and those drives can deliver more bandwidth than the channel has to offer, you're not going to get maximum performance. And in both cases, the solution is to split the drives across multiple channels.
Note that Thunderbolt (which Macs have and are possible to get on PCs - I have one an an ASUS motherboard I purchased recently) has a peak speed of 10 Gb/s compared to the 4.8 Gb/s of USB 3.0. Either way, Intel wins (it is backing both horses here).
Quite interesting, all sorts of inside ports can be used to plug flash memory:
http://www.supertalent.com/products/ssd_category_detail.php?type=FDM
The little ones to plug into usb3 ports are 32g already... I'm often finding myself with unused usb connectors on the motherboard these days. There is also sata and pata.
Artix
Your Linux, your init.
Not quite yet. They still have to up the deliverable wattage even more, bring OTG into the high end device range, and switch to a more sensible UTP cabling and line coding to extend the range.
They'll get there... it's the way of the world. Two people invent two things. One thing is thorough, well engineered, but expensive and requires some level of experience to understand -- the other is cheap but braindead-simple and barely functional. The latter wins in the market, and when its shortcomings start garnering attention (e.g. when people who know what they are doing finally try to use it to do something useful) those shortcomings are hacked around in a new standard revision. Eventually we end up with a giant steaming pile of bodgery that mimics the superior standard we already had 10 or 20 years ago but is saddled by loads of legacy compatibility needs. Witness SCSI vs IDE/ATA, ATM vs MPLS/RSVP, SGML vs XML/XHTML just off the top of my head.
Someone had to do it.
http://www.bit-tech.net/news/industry/2010/08/17/gigabyte-first-to-support-uasp-usb-attache/1
USB3 includes superspeed in addition to everything that USB1 and USB2 had - low speed (for keyboards and mice), full speed (for printers, scanners and so on), high speed (for HDDs and camcorders) and now superspeed. The way USB3 is being thought of is like it can only support superspeed, which is not the case at all. 3 just implies the current revision of the standard, nothing more, nothing less. An USB keyboard which one buys will be USB3 - just a low speed one.
Why not use the 4.8Gb/s for just SSDs, where all the parts are solid state and capable of these speeds, and not use that for HDDs, instead of creating a new HDD standard that's either going to be incompatible w/ the current PATA or SATA drives, or too expensive due to the embedding of SCSI protocols? The whole idea of USB is to support devices of varying speeds on its bus, and that can be as slow as USB keyboards and mice, and go right up to camcorders or SSDs. Let every device participate on the bus @ speeds it is comfortable - be it low-speed, full-speed, hi-speed or superspeed (personally, I hate the use of the adjective 'super' to describe anything, due to the implication that there's nothing beyond).
If you look at the hothardware benchmarks, they found very small improvements for high-performance HDDs, and only on large transfers. Contrary to what MojoKid wrote, even USB 2.0 was good enough for the usage patterns of most hard drives. While the USB 2.0 transfer speed couldn't handle the outer zones of the fastest hard drives, it could handle their inner zones and slower hard drives. When you factor in that most disk commands have sizable delays due to seek and rotational delays that the new USB Attached SCSI Protocol can't do anything about (command queuing and seek optimization are generally overrated), there just isn't just isn't a lot to be gained using this new protocol with hard drives. It does make a big difference with SSDs, though.
ATM sucks.
I know tobacco is bad for you, so I smoke weed with crack.