USB Mass Storage and USB-Attached SCSI Are Both SCSI
devever.net
devever.net
ATAPI tunneled SCSI commands over PATA for CD drives and other such things.
AFAIK SATA uses the SCSI command set too (as does Serial Attached SCSI obviously). To the point that most SAS controllers can also run SATA drives without issue.
Apparently USB mass storage also uses SCSI in both BOT and UAS forms.
Sometimes a protocol is designed so well to fit its purpose yet just flexible enough to support future use cases that there is no need to replace it. Hats off to the original designers of the SCSI command set.
I wonder if its worth spending some time trying to understand what makes some protocols so robust and widely adopted. It's not just being open vs closed.
A few other examples:
- PostScript (probably) / PDF (iffy)
- CAN (adaptable)
- G-code
- Serial
- HTTP
- HTML (sort of, badly)
- VNC (maybe)
- JSON (for now)- The QuickTime container became the container for AAC audio, ISO MPEG4/h264/h265 video, HEIC, AVIF
- Zip files have become a generic container used in all kinds of formats (Java jar files, Android apk, Microsoft office documents, usdz, etc )
SAS HBAs are backwards compatible with SATA drives because they're specifically designed to be. So I guess they're capable of passing either SCSI or, when SATA drives are used, ATA commands.
Where it gets amusing is when you use SAS expanders, since then the link from the HBA to the expander is SAS, but the link from the expander to the drive is SATA. Thus SAS has a special protocol called Serial ATA Tunneling Protocol (STP), which allows ATA to be tunneled over SAS.
What's really comical is that this means if you attached a SATA optical drive to a SAS expander, it follows that you'd be talking SCSI tunneled inside ATA/ATAPI tunneled inside STP over SAS.
There are SATA drives that understand SCSI over ATAPI albeit in a limited way just to be clear.
Very interesting! I just looked it up - it's the ATA PASS-THROUGH command in the SCSI-ATA Translation (SAT) specification. Someone just told me this is apparently a common way to read SMART data from hard drives in USB enclosures.
>There are SATA drives that understand SCSI over ATAPI albeit in a limited way just to be clear.
I assume you mean hard drives. This is extremely interesting. Can you provide more information? Examples of drives, any links?
The clerk at the store went off on this surprisingly lengthy and heated diatribe about how SCSI was mediocre technology, and how nobody in their right mind should ever want anything SCSI ever again.
I kind of miss that sort of passion in computer store clerks.
"Hear that fellas? You're just mediocre."
Out of curiosity, what's that for? I'm struggling to think of a case where reading that many optical discs is actually useful
It took months, but would have taken months longer if I only had one drive.
I remember when we were trying to burn CDs, about 1/4 of the time it failed. I pointed out that we didn't have a SCSI terminator on the other slot, but my dad insisted what difference could that possibly make? And to be honest, at the time (I must have been between 8-10 at this point), I couldn't really disagree with him. It was just this chunk of plastic that plugged into the port, it looked more like a protector than anything actually useful. Anyway, we tried it out and it did resolve our issues, but I still had no idea why until I got to college and learned about different buses in some computer engineering class.
My first x86 PC had a 425MB SCSI-II hard-drive and a "triple Speed" (3x) CD-ROM. Having a SCSI drive with a seek time of UNDER 11ms was enough to blow the doors off of every other computer I came across (IIRC 4ms was the actual time vs 11ms for most other 120MB HD's at the time.)
Everything about SCSI was cool. Over powered, over engineered, and willing to take abuse better then anything else.
It was an AMD 386DX-40, 8MB of RAM, a VGA-Wonder XL video card, a Logitech bus mouse, soundblaster, and 2 modems; 14.4 & a 56k USR.
AND I ran linux on it. Well I could install linux, and couldn't really figure out what to do with it after that. But Even back then Linux detected EVERYTHING, and it was FAST.
Then SCSI-II and SCSI-III and ATAPI/UATA/PATA cables came along and started making the ease-of-identification based on just visual traits a lot more difficult.
"What, no, I have Facebook."
vs What in 1990? Pray tell. Parallel IDE? I'd have laughed in his face if he said that.
The biggest problem with SCSI was always the fact that you had to understand termination or the bus you built wasn't going to work.
The second biggest problem with SCSI was always the fact that it was more expensive. Cables were especially expensive, but controllers weren't cheap either.
Yeah, back then Macs were bad, but at least they had SCSI, so they had something going for them. Of course, then they went to IDE, and had nothing going for them anymore.
This is just a fundamental limitation of a high-speed parallel shared bus for 1990s' technology, not really specific to SCSI. Termination is needed because of physics, there was no way to workaround it. Moving termination to the drives and backplane is a solution (e.g. PCI uses it), but I guess it was too inflexible for SCSI when cables were often chained together. Ultimately the problem has been solved by Moore's Law - when chips are powerful enough, it makes sense to just stop using parallel buses entirely, and move to point-to-point serial lines. Termination is implemented at end-points, and the bus is never shared, eliminating this problem.
Just like how Ethernet began as a low-cost bus network (and yes, you need to add terminations on 10BASE-2) and ultimately evolved to point-to-point serial lines.
While PCI does solve the reflection problem in the backplane, the PCI bus is not terminated. When a signal first passes by the receiving device it only sees a weak signal that is only a fraction of the expected amplitude. When the signal reflects off the end of the bus, it passes by the receiving device again. The receiving device sees the initial signal's amplitude added to the reflecting wave's amplitude as the expected full strength signal.
I should have used "and/or".
> the PCI bus is not terminated.
I'd say PCI, arguably, is still terminated. It just uses series-termination instead of parallel-termination. In a parallel-terminated line, when the signal hits the receiver, the termination resistor to ground absorbs the energy, an ideal textbook scenario. In a series-terminated line, there's a resistor in series of the transmitter, which is the termination of the line. When the signal hits the receiver, it reflects back to the transmitter via the series resistor again, and the energy is absorbed.
Quote High Speed Digital Design by digital guru Howard Johnson,
> 1. The driving waveform is cut in half by the series-termination resistor before it begins propagating down the line.
> 2. The driving signal propagates at half-intensity to the end of the line.
> 3. At the far end, the signal reflection coefficient is +1. The reflected signal is half-intensity. The half-sized reflection plus the original incoming half-sized signal together bring the signal at the receiving end to a full level.
> 4. The reflected signal (half-sized) propagates back alone the line toward the source, where it damps out at the source termination.
Note the step (1) and step (4), when omitted, gives an impression that Reflected Wave Switching has no termination at all, which is not how it actually works. The termination resistor is chosen in a way that, when the resistor is combined with the driver's internal impedance, they approximately match the characteristic impedance of the transmission line, thus ensuring the termination is optimal.
> Reflected Wave Switching
It's the most common method to terminate a point-to-point digital interconnect, usually people just call it "series termination". I just finished designing a circuit board yesterday and the data interface was terminated using this technique. Reflected Wave Switching was just another confusing term for that ("confusing" because, while it's a fairly descriptive name, but in many books with a voluminous discussion on serial/parallel termination and whether the signal is reflected, the term Reflected Wave Switching is often not explicitly mentioned. On the other hand, we have computer books that mention Reflected Wave Switching in PCI, but without a discussion of how series termination really works).
The problem of series-termination on a shared bus is, first, there's no clearly-defined transmitter or receiver, a signal can come from either end from multiple devices. Also, the impedance of the bus is affected by the number of cards and the physical locations of the slots on a backplane. It's simply impossible to select an optimal series termination resistance to achieve an ideal series termination. Using series-termination in a shared bus is a hack, but PCI managed to successfully engineer a "good enough" compromise solution for PCI's data rate.
One can say PCI doesn't have termination since many drivers feature on-chip series termination. But it's true for other interfaces as well, so I still like to imagine PCI's "Reflected-Wave Switching" as a compromised form of series termination, as described by Howard Johnson [0].
[0] http://www.sigcon.com/Pubs/news/3_3.htm
---
Ultimately, it was the transition to point-to-point serial lines that ended all the termination headaches.
Perhaps ubiquitous OS support was one of the main driving forces behind the SCSI protocol being adopted by so many technologies since.
In the meantime I hope USB4 with pcie takes off. AMD needs to make it happen. Not enough mobile chip makers about for them to try to be competitive & throw in support on cell phones, not till 2026l5 or so I'd guess, even though it's be so neat & thoroughly bridge the chasm between pc & mobile.
It's basically a solution in search of a problem, since it is needed when commands are delivered asynchronously with respect to responses but you don't have autosense. BOT only has a single command in flight so it didn't need ACA, but UAS has autosense so it doesn't need it either...
Suppose I schedule 10 commands all at once, with the Ordered task attribute. If the third command fails, do I necessarily want the remaining commands to be executed? Possibly these are a logical sequence (e.g. for a tape drive, rewind, write, etc.)
I have no idea if anything actually exists which can make constructive use of ACA in this way, but it occurs to me that there is still potentially some use there even when autosense is enabled.
That is, if I'm understanding ACA correctly.
As a sidenote, if you configure FreeBSD on Raspberry Pi 0 to serve USB Mass Storage (like the gadget functionality in Linux), the USB-tunneled SCSI requests will be handled by the same target that serves Fibre Channel or iSCSI, with persistent reservations, VAAI and other features that might feel like a bit of an overkill for a virtual flash drive.