Talk:SCSI/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

sustained transfer rate

What is the sustained transfer rate for a 15000RPM Ultra320 SCSI drive w avg seek time of 3.3ms? is it still 320MB/s? for example an STA150 drive at 7500 RPM w avg seek time of 8.5 ms (16MB cache) has a sustained transfer rate of 64-35 MB/s & burst transfer rate of 150MB/s. --Ario 12:34, 13 June 2007 (24.2.143.239 16:37, 13 June 2007 (UTC))

Fibre Channel

Fiber Channel is not an alternative spelling of Fibre Channel.

SPI vs SCSI

The concepts relevant only to SCSI Parallel Interface should be separated from the article on SCSI proper. Although SCSI-1 and SCSI-2 include SPI as a central part of the protocol, SCSI-3 has completely split the framework into separate layers. --Cy jvb 20:20, 2 February 2006 (UTC)

Dis iz a good suggestion so I have split out the SPI content and created a new page called Parallel SCSI.
Neilm 12:43, 7 February 2006 (UTC)

Pleonasm?

"SCSI is pronounced "scuzzy" when spoken aloud"... Isn't this a bit pleonastic? --Edcolins 11:51, Oct 28, 2004 (UTC)

"while occasional attempts to promulgate the more flattering pronunciation "sexy" have never succeeded." Nowadays we're trying to get it to be pronounced "sucksy" ;) --148.84.19.92 15:25, 9 Mar 2005 (UTC)

IDE?

The article says that PATAPI is SCSI over IDE. Isn't this a misnomer? As I recall, parallel ATA is not the only form of IDE, though PATAPI is, of course, over parallel ata.

Not quite; something the article doesn't make clear is that SCSI is a command set as much as (and, now even more than) it is an interface. If you look at the official specs for ATAPI, it is indeed sending SCSI commands over the ATA bus; in fact, most ATAPI devices these days are actually SCSI devices that speak enough ATA to get by. -lee 07:11, 13 Jun 2005 (UTC)

spice up SCSI

good article, Mac users in particular grew up on SCSI and SCSI peripherals

How about some pics of the typical fat cables and giant terminators that people remember:

http://images.google.com/images?q=scsi&hl=en&lr=&sa=N&tab=wi


Also what about the SCSI logo ?

http://images.google.com/images?hl=en&lr=&q=scsi+logo&btnG=Search

I agree that this article needs some pictures. Anyone willing to take some? 203.208.80.13 00:51, 14 September 2005 (UTC)

I've added some self-made images including the SCSI logo, a SCSI terminator, 25 pin SCSI cable, and Mac SCSI port. Feel free to move them around in the article if you feel some of them might be better placed. --CB1226 23:37, 2 March 2006 (UTC)
Why were the pictures removed? Its extremely helpful to see what the connectors look like. Egret 23:04, 19 June 2007 (UTC)

SCSI is dead

hasn't Apple totally stopped using SCSI ???

Hasn't sun totally had sales of SCSI equipped systems plummet ?

Isnt sales of SCSI hardware now limitted to maintainance (including any strictly run enterprise that has SCSI as standard, so any new hardware must meet the old standard ...one would think that if they made the choice of standards now, they might chose SATA over SCSI .. ) and "main frames" situation, eg fibre channel for connecting 50 scsi devices to the 30 cpu supercomputer. —The preceding unsigned comment was added by 203.82.182.242 (talk) 02:31, 17 January 2007 (UTC).

SCSI protocol

This article only seems to talk about devices...as far as I know, in the Linux kernel (for 2.6 at least), firewire IEEE1394 / USB storage devices / Ipod's, etc. they also use the SCSI protocol to communicate to the kernel. Any elaboration on this? -- Natalinasmpf 02:27, 19 Apr 2005 (UTC)

You are correct; most of this article focuses on what is now officially referred to as the SCSI Parallel Interface, which is just one part of SCSI-3 and has little to do now with the SCSI command set (which is, as you and others have noted, is implemented on things that are about as far from SPI as you can get). At some point (not tonight, since it's late) I'll go through and sort things out. -lee 07:05, 13 Jun 2005 (UTC)
I have created a new page called Parallel SCSI and moved some content to it. Neilm 12:45, 7 February 2006 (UTC)


June 22, 2005:

The article should mention "packetized" SCSI that was introduced with Ultra-320. IBM preferred the term "information units" over "packets". I think this was around 2002 or early 2003.

Also, the "Ultra" designations were promoted by the SCSI Trade Association but not used in the ANSI standards. After SCSI-2, the physical interface standard was separated from the logical layers, and became SPI (for SCSI Parallel Interface) and went through generations SPI-1, SPI-2, SPI-3, SPI-4 and SPI-5. STA wanted marketing-oriented nomenclature that reflected the actual maximum data transfer rate of the bus. Note that the SPI acronym can easily cause confusion with other standards.

I don't think "All SCSI standards have been modular, defining various capabilities which manufacturers can include or not" is true of SCSI-1 or SCSI-2, which were monolithic specifications, unless "modular" means something different from what I take it to mean.

I didn't write that part. But certainly SCSI-2 has wide scope for variation in device capabilities, with all sorts of contexts in which initiator and target are supposed to negotiate for a set of common capabilities.
I think this is too opinionated for the article, but to my mind one of the weaknesses of SCSI is that it is a humongous specification--SCSI-2 is about an inch thick--and it is very easy for devices to fail to implement some portions of it correctly. Obviously, if an Adaptec card doesn't work properly with Seagate disks they'll catch it and fix it, but obscure corners of the specification can be ignored, resulting in SCSI cards that work with most but not all devices, and vice versa.
It is similar to problems encountered with TIFF in, say, the early nineties, when it was quite possible to have a TIFF file that completely conformed to the TIFF spec but which could not be opened by PageMaker.
Another problem, to my way of thinking, is that the safety margins on things like cable length appear not to be conservative enough. I notice that Adaptec consistently specifies maximum cable lengths that are exactly half those allowed by the spec! And, worse yet, in the real world, if you have a cable configuration that theoretically should work, but the terminations are slightly bollixed, or there are slight impedance mismatches where cables join at connectors, the result is subtle and sometimes intermittent problems, rather than obvious failures.
Yeah, one big issue with multi-drop cables is for devices in the middle (or anywhere not at the ends) of the cable. They would be much more susceptible to reflections on the received signals, and also have the burden of driving two cable segments and not just one, so they would produce about half the signal strength on the incident wave that a device on the end of the cable would.
Vendors try to solve these problems by building in automagic self-configurating features, which help when they work and make things worse when they don't. For a while we had an issue with Adaptec cards, when they first introduced a feature they called "domain validation." This meant that instead of trusting what the device said its capabilities were, the card would dynamically test for certain device characteristics and capabilities. Our device would sit there and say "I'm synchronous, I'm synchronous, please please run synchronous so we can get the data transfer rates we need" and for some reason the card would say "Nyaah, nyaah, I don't BELEEEEVE you, say what you like, I'm going to run asynchronous anyway" making our stuff basically not work unless the end-user turned off domain validation. This is no longer true, but we never found out exactly what had changed about their "domain validation" process. Dpbsmith (talk) 19:21, 22 Jun 2005 (UTC)

Termination

The description of the termination network is inside out and backwards. Passive termination uses 2 resisters to TermPwr and ground. Active termination uses 1 resistor to a regulated 3.3 volt source. Differential is 2 lines that are each terminated. In single ended, the other line is a ground. The active termination uses less power and therefore uses a smaller resistance that more closely matches the cable impedance. The tutorial that is already link to has it right <http://www.scsita.org/aboutscsi/SCSI_Termination_Tutorial.html>. It should also be mentioned that the term power fuses have mostly been replaced by a current limiting device. ~ Dan Oetting 136.177.111.33 00:32, 5 November 2005 (UTC)

Thanks. I got that wrong so I have now corrected it. neilm, 5 November 2005.

What's used now?

It's been a long time since I used SCSI. What is used now in servers? Isn't some form of IDE used now? --Gbleem 16:13, 8 November 2005 (UTC)

Newbie Question

In a read or write command block is the data transfer length in bytes or LBAs?

JimT

Always LBAs. See the SCSI Read Commands article for more info.

neilm

Note that Read/Write Long have a byte count in their CDBs. —Preceding unsigned comment added by 195.212.29.92 (talk) 14:58, 5 January 2009 (UTC)

Connectors

I miss the description of various SCSI connectors.

xerces8 --213.253.102.145 12:31, 16 January 2006 (UTC)

I have added a new page called SCSI connector

neilm 19 January 2006


Clockspeed ("SCSI interface overview" table)

2 Gbit isn't a clockspeed. In fact it's not a measure of speed at all. It's an amount of data. Clockspeed is measured in Hertz, and ONLY Hertz.

  • Agreed. The interfaces starting with SSA really do not fit in with the given column headings. Clock speed is mostly only relevant for the various iterations of SCSI Parallel Interface (don't quote me on that - I am really only familiar with SPI and iSCSI). Perhaps we should generalize the table and provide a decent overview of all of the SCSI transport protocols? Cy jvb 19:05, 22 February 2006 (UTC)

MB/s over Mb/s

I think it should be made more clear what speeds the different SCSIs run at. Most transfer rates are defined as bits per second (bps) where as what is described here (Bps) which i have come to associate as Bytes per second. This does not, how ever translate over well when comparing transfer speeds.

So either the MB/s needs to be changed over to Mb/s or a subtle hint needs to be added to the text. Is this reasonable?

yet another Matt 14:30, 22 March 2006 (UTC)

  • The word "Bandwidth" was not a good choice as a header for the column in the table. It is related more to clocking rates rather than the amount of data moved in a period of time. The same goes for "baud rate" and "transfer rate". The SPI-4 standards define "transfer rate" as the negotiated number of megatransfer per second. Megatransfers/sec is equivalent to MB/s only on an 8 bit bus. This is why Fast-20 Wide has a maximum throughput twice as much as Fast-20 Narrow. The usage of "transfer rate" in the specifications definitely does not match the usage in the table column. I have changed the table header to "Max. Throughput" to correct the context of the column.
    As for the MB/s v. Mb/s issue - from my experience with dealing with storage devices, using orders of 8 bit bytes for measurements fits the storage context better than using orders of bits. Current SCSITA terminology for SPI devices (ex. "Ultra160") match the maximum interface throughput in Megabytes/sec. Since SPI was at first the one an only SCSI transport interface, it seems natural to continue the convention. Cy jvb 18:53, 22 March 2006 (UTC)

Disk size limits

What are the device size limits in SCSI ? This subject is always popular with ATA :-) Isn't there a limit at 2 TB (2^32 x 512 byte sectors) ?


- Actually, the new version of SBC supports 64x512 byte sectors, but sometimes the initiator or the OS doesn't support such big disk driver. —Preceding unsigned comment added by 65.113.40.1 (talk) 07:38, 10 September 2008 (UTC)


xerces8 --213.253.102.145 11:00, 24 April 2006 (UTC)

Parallel port SCSI

There's nothing about "parallel port SCSI"... I gather it was used for a great many scanners and external disk drives, but beyond that, I don't know much about it. Also, I've seen ATAPI being described as partly based on SCSI, but I'm not sure whether to believe that. --StuartBrady (Talk) 14:34, 10 July 2006 (UTC)

What do you mean by "parallel port SCSI"? Never heard that term. Mirror Vax 01:56, 11 July 2006 (UTC)
I'm not really sure — which is why I asked! It's SCSI, somehow using a parallel printer port. See [1] and [2]. It seems there's a special SCSI<->Parallel port cable that's required (and I've no idea if this could even vary from one manufacturer to another), at least for some devices... but I'm not sure if all of these devices need one. (There's also "parallel port IDE", which is presumably the same thing for ATA/IDE.) --StuartBrady (Talk) 16:51, 11 July 2006 (UTC)
There are scanners that are designed to be used over a parallel port but these scanners do not use SCSI in anyway but rather advanced bi-directional parallel port technology. There are adaptors that allow SCSI-based peripherals to be connected to a parallel port ([3]) which is what I believe the links you mentioned refer to. Also, the "parallel port IDE" is likely a special drive enclosure that allows you to hook a attached an IDE drive to a parallel port as external drive. Inside the enclosure is circuitry that coverts the IDE signal to a bi-directional parallel port signal. Similar enclosures are available for "IDE to USB" allowing any internal hard drive to be used externally over a USB port. --Cab88 20:49, 11 July 2006 (UTC)
Right. I'm not really interested in the "ordinary" parallel port devices... but it certainly seems that "parallel port" perpherals were sold which were really SCSI peripherals with an adaptor cable. It seems the Zip Drive was one of these, but AFAIK, there was a SCSI version of the Zip Drive which was not the same (you couldn't plug a parallel printer into it, for instance). It sounds as though there probably isn't much to it... The interesting thing is that it seems that most/all of these devices used the same adaptor... --StuartBrady (Talk) 21:55, 11 July 2006 (UTC)
Are you sure this isn't a misunderstanding of "parallel SCSI?" Traditional SCSI transmits the data bits in parallel, over 8 wires ("narrow") or 16 ("wide"). In theory the standard also allows 32-bit-wide parallel SCSI but I don't know whether anyone has ever implemented it. Ten years ago this was just called "SCSI," but when SCSI-3 introduced new flavors (Fibre Channel, serial SCSI and I don't know what all), and when the SCSI protocol started to be implemented within FireWire and USB, people began referring to the traditional interface as "parallel SCSI." The fact that 50-pin Centronics connectors were once a popular connector could have added to the confusion. Dpbsmith (talk) 20:01, 3 August 2006 (UTC)
You're probably thinking of stuff like the Trantor Mini-SCSI T348. It is a bona fide parallel to scsi adapter (uses bidirectional parallel port to talk really slow scsi). Naturally you need drivers, and booting from such a device is right out of the question. As an aside, referring to the CHAMP connectors prevalent on SCSI-1 as "Centronics" is *wrong*. Centronics (IEEE-1284 parallel printer bus) connectors have 36 pins. SCSI-1 has 50. IEEE-488 GPIB (aka HPIB) connectors are similar but have 24 pins. Would anyone refer to SCSI bus connectors as "GPIB connectors"? I think not. Yes, I'm perfectly aware that there is a lot of common misuse out there, but Wikipedia articles should note the vernacular and then use the proper name. Ke4djt 13:37 20 September 2006
I think you mean SCSI which used a DB-25 connector, which was physically identical to the parallel port. This implementation was used on a lot of consumer level computers, like Macs and Amigas, and for many scanners, and even some versions of the Zip drive. It is not part of the SCSI standard, in that it drops the 25 shield lines and is therefore less resistant to noise. However, it was more compact than the alternative 50 pin centronics connector, and cheaper to implement. IIRC, there were at least two versions of pin outs for the DB-25 connector, however the vast majority used the same pinouts as found on the Mac, so this was the defacto standard. To confuse things further, there were available adaptors for regular PC parallel ports to SCSI. 59.167.243.34 (talk) 04:50, 11 January 2010 (UTC)

Parallel SCSI

  • This is esentialy the same thing as traditional SCSI. Also for additional argument Parallel ATA -> Advanced Technology Attachment. --Pboyd04 02:33, 20 July 2006 (UTC)
    • NO, see the #SPI_vs_SCSI discussion above for the reason for the split and re-read the SCSI and SPI articles (the intros should have been enough). Parallel SCSI is only a physical transport layer specification within the greater SCSI framework. Detailed discussions about SCSI-1, SCSI-2, and the SCSI-3 SPI specifications (signaling, termination, etc.) should be confined to the SPI article. Home users generally downplay the significance of SCSI-3 with discussions about ATA & SATA for some reason. I don't see this being anything other than end of discussion. --Cy jvb 03:08, 20 July 2006 (UTC)

Compatibility

The article states "You can attach both narrow and wide SCSI devices to the same parallel bus. To do this, you must put all the narrow SCSI devices at one end and all the wide SCSI devices at the other end, and terminate the high half of the bus in between (because the high half of the bus ends with the last wide SCSI device). "

According to Adaptec, a 68-to-50 pin adapter can be used to put a narrow device on a wide cable, and the high 9 part of the wide cable does not have to be terminated at that point. See Adaptec's KB answer ID 9, "Procedure for connecting both narrow and wide devices to a wide Adaptec SCSI card", in particular the description of the "Adaptec Internal Converter (ACK-68P-50P-IU)". Or are they wrong? Jeh 18:13, 3 August 2006 (UTC)

The Wikipedia article isn't strictly correct. My cursory reading of the Adaptec KB article leads me to be believe the it is more correct. However, I don't think you are understanding the Adaptec article correctly. Here's how it works: Both ends (and only both)ends) of the wires in the SCSI bus must be terminated. Otherwise, when the electrical signal hits the end of the bus, it "bounces back" and causes problems. However, you can terminate the wires used for the wide bus (the "high byte") independently of the wires used for the narrow bus ("low byte"). That is what the ACK-68P-50P-IU does, I believe: It terminates the wide bus, but continues the narrow bus to narrow devices (and a terminator for the narrow bus). Furthermore, the article is wrong in that you can connect a narrow device in the middle of a wide bus; you just have to make sure all the bus lines are connected. --DragonHawk 18:55, 3 August 2006 (UTC)
Yes, I well understand the need for termination. But no, that isn't what that adapter does at all! It has no termination whatsoever; it simply tees off the narrow part of the bus, for benefit of the narrow device. The entire (wide) bus continues on, more wide devices can be connected beyond the narrow device, and it is all terminated by a regular wide adapter at the far end. Adaptec DOES have a "wide cable to narrow cable" adapter that works as you describe (they mention it earlier in the article). Jeh 20:20, 3 August 2006 (UTC)


You can connect a narrow device in the middle of a wide bus.

You can connect a narrow cable to a wide bus, but you must terminate the high data lines at the point of connection between narrow and wide ...

Wide SCSI cards have which have a narrow cable connector usually have a way to terminate only the high data lines at the card. At the other end of the narrrow cable, you need to terminate (in the normal way for narrow), which can only terminate the low (narrow ) data lines ..

And at the other end of the wide cable, you need to terminate in the normal way for wide.


- I can tell you from firsthand experience that it did not work out with a Adaptec 2940 UW, a 8-bit (scsi-50) flat cable and a to-SCA-adaptor driving a Maxtor SCA hdd. with a wide cable (68) on the same sca adaptor it does work --145.253.2.232 16:28, 25 September 2007 (UTC)

Clock Speed on Table

i noticed that on the table at the SSA row the Clock speed goes from Mhz to Mbit. to me that dont seem like it should be Mbit, seeing how it is a clock speed not a transfer rate.
longbow 17:58, 27 Sept 2006 (EST)


As its serial , which means one bit at a time, which means Mbit=MHz.

H for Mr Hertz. Its a name, so its capitalised.

Computer Hardware Bus Infobox

This infobox really does not properly summarize the SCSI protocol suite, so I have removed it.

  • It is specific SCSI Parallel Interface
  • It lists SATA as a superseeding protocol - that's an EXTREMELY misinformed tidbit (can I laugh a little about this??)
  • Hardware bus attributes cannot be generalized for all SCSI physical transport protocols (some attributes do not even apply to other transports!)

You could probably add this infobox to the SCSI_Parallel_Interface article, but you need to perform some fact checking first. -- Cy jvb 13:38, 11 October 2006 (UTC)

Since when does SCSI do kilometres?

Consider me ignorant, but where and when is this possible? :: Colin Keigher (Talk) 05:35, 21 December 2006 (UTC)

http://www.fibrechannel.org/OVERVIEW/topology.html Its very expensive, but it is technically a SCSI system that runs quite a long distance ... :)

In practical terms, its rare fibrechannel system, that is for mainframes, and outside of the scope of standard SCSI

Overhaul

FYI, I'm starting a major overhaul of this article. My goals include: make it easier to navigate; move the focus from SPI to the entire SCSI suite; add citations (to the actual T10 draft standards, when possible); add explanations or links for the tech terms; move individual SPI standard levels out of section headings and into a table, section, or article of their own. While I'm doing this, I may checkpoint with the organization somewhat less perfect than it could be. I may leave it for a day or four while I do things like work or sleep. But I will come back to it, and hopefuly quickly. I just wanted to let people I have a plan, and I'm not just chewing up the article for the heck of it. I'll try and note major progress here. Suggestions, comments, commendations, condemnations, etc., are welcome. —DragonHawk (talk) 05:27, 17 January 2007 (UTC)

FYI, my own notes on this are at: User:DragonHawk/SCSI —DragonHawk (talk) 23:47, 28 January 2007 (UTC)

cool; I will not touch now. I was going to ream out the "connector" column from the tables and try to find a good place to link to the scsi connector article instead. Stuff I don't see mentioned which probably should be somewhere, although not necessarily in the main scsi article:
  • pronunciation, the sassy->sexy/scuzzy thing
  • as mentioned above, stuff like the iomega zip drives that use parallel printer port <-> scsi converters; is there a defacto standard for scsi over parallel? did everyone use the same chipset or were there multiple incompatible solutions?
  • scsi can be used for host-to-host networking; the commodore amiga implementation did this. then dec modified scsi to create dssi in order to provide better capabilities in this area. (heck, there isn't even a dssi article!)
  • some peripherals have multiple scsi interfaces; in particular, I'm thinking of how the first generation of tape stacker units from exabyte, dec, and others had a seperate scsi port to control the tape-swapping robotics. mention of the scsi serial port/terminal server units might also be made.
-- Akb4 14:22, 2 February 2007 (UTC)

SCSI hard drive is dead

availability of largest hard drives SATA drives: 800 gigabytes, reasonable price SCSI drives: 300 gigabytes, hideous price

Um, non-fibre scsi is dead. Perhaps mainframes will continue to use it, perhaps IBM will order or utilise SATA attached SCSI enclosures, putting SATA drives onto a SCSI bus..

Speculation

Forgive me for being blunt, but you are just throwing wild speculation into the article (evidenced by your choice of words - probably, indicates, etc.). Your additions are based on a very narrow data point and obviously biased criteria. If you want to comment on the predominance of SATA-interfaced HDDs in the consumer market opposed to SPI-interfaced HDDs, then be my guest. Capacity and price would be obvious factors in the consumer market. You can even comment on the trend towards the cost-effective use of SATA HDDs in SPI/Fibre Channel RAID enclosures for the SMB. What you cannot do is unilaterally proclaim the death of a product (also insinuating the failure of a transport protocol) merely because you do not see a consumer mass-market appeal. There is plenty of information to cite to the contrary.

I'm going to withhold the unleashing of a revert war since in-depth discussion about SCSI HDDs is too SPI-specific anyway. Hopefully DragonHawk's overhaul will set the focus correctly on the protocol suite. Cy jvb 15:31, 18 January 2007 (UTC)

I agree. I am completely bemused by both the substance and the aggressive tone of this whole "controversy". I bought a small HP SCSI based server for £500 only a few months ago. Sure, SATA is more common now but there is no justification for pronouncing SCSI dead for hard drives, never mind for other peripheral types. While I don't like edit warring, I also don't like nonsense being left in the article either. I hope it will be corrected soon as part of the overhaul. --DanielRigal 11:54, 19 January 2007 (UTC)

We just ordered a bunch of servers from Dell and ended up specifying 15k SAS drives because we need performance, not capacity. So, SCSI is most definitely not dead. Parallel SCSI is close, though. LTO-4 is probably going to be the last tape generation with parallel SCSI. Everybody *hates* SCSI-320, it's so marginal, and SAS is coming down in cost. Ralf-Peter 02:07, 12 March 2007 (UTC)

IPA reverts

While I think that an IPA rendering would be lovely, I don't think we should have such a big ugly box on the article. What the heck is up with that anyway? I can hardly think of any article for which the most significant feature on first loading the page should be "Hey, we need IPA for this"; tons of things need or could use IPA, but unlike NPOV and Source Cite notices, I hardly see it as critical to paste a giant warning on. crappy template; where do we go to gripe about it? On the discuss page, a label like that would be ok as a sort of To-Do reminder. (Really, I think discuss pages should be supplemented by a bug tracking system so issues with pages could be neatly categorized, discussed, and resolved). Anyway, there should be a pronunciation section explaining the whole sassy/sexy/scuzzy thing; useful both to non-native/fluent english speakers and people interested in hilarious marketing debacles. But please talk about it here instead of edging towards revert battle. -- Akb4 09:43, 8 March 2007 (UTC)

I think the IPA would be /skʌzi/. No time to muck with article or do IPA for sexy right now. -- Akb4 10:00, 8 March 2007 (UTC)

SCSI Writes

Hi I have a technical question about scsi write which, if answered, should help improve the description of that command.

SCSI Write, all variants, specify a LBA into a LUN where the data is to be written. There is also a transfer length. presumably the data from a buffer is written to the start of a the specified LBA for the number of bytes in the transfer length. That in itself would be a useful explanation to have on the scsi write page.

however, what happens if the desire is to write, say, 1 byte at offset 10 inside of some LBA? The command does not seem to handle this sort of addressing. Certainly a user can modify a single byte of a file, say in C code.

Under the covers, does this sort of write involve a read to pull in the full 512 byte block, then the one byte is modified, followed by a write? I know this is a bit beyond the low level scsi protocol, which may just say you cant write a single byte, but isnt that what has to be done?

Kdohm 22:19, 29 March 2007 (UTC)

Yup - such is the nature of block addressing. See the SCSI Block Commands document (www.t10.org) for info on Write commands for block devices (disk). Note that for SBC, the transfer length is specified by the number of logical blocks, not bytes.

I think that you can use variable block mode to write a single byte with tape - at least it's valid as far as the command definition states (in this case, the transfer length is specified in bytes). Whether or not the device supports it is another question. Tape also supports relative read/writes depending on the current position of the tape. --Cy jvb 01:54, 30 March 2007 (UTC)

You can indeed write a single byte—at least theoretically, as you state. Tape drive firmware implementation varies all over the place. Having worked a lot with tape drives of various types, I wouldn't be surprised if some devices either refused to execute such a command, or did execute it but wrote a block that was actually longer than one byte. +ILike2BeAnonymous 01:58, 30 March 2007 (UTC)

Some say SCSI used to be spelled SC/ASI at some point in history

I'm snipping this

Some say SCSI used to be spelled SC/ASI at some point in history.[citation needed]

pending a citation. Interesting if true, but we don't need a "some say" / "at some point" assertion in the article.

Along the same lines, long ago, in the heyday of Digital, when RT 128 in Massachusetts was a center of minicomputer development, SCSI was pronounced "sexy." I have no idea how or where ths could be verified, however. Cuvtixo 14:33, 21 August 2007 (UTC)

Vendors tried hard to promote the "sexy" pronunciation against the users seeming preference for "scuzzy". It didn't take. I remember meetings when we were switching from SASI controllers and drives to SCSI --- they'd say only "sexy" and we'd say only "scuzzy", though we were all talking about the same equipment: 5-20MB drives and controllers. ISC PB (talk) 02:54, 19 November 2008 (UTC)

I remember reading that anecdote about the "sexy" pronunciation in a magazine back in the early 1990s. Byte? PC World? I'm sure that's not enough information to do a periodicals index search with, unfortunately. —Eric S. Smith (talk) 18:31, 9 January 2008 (UTC)

Introduction year/timeline for commands?

Does anyone have references as to when different commands were introduced like read(6), read(10), read(16). Which sets the absolute limit on how large discs that can be handled in practice (re ata 48bit mess). Electron9 04:49, 26 July 2007 (UTC)

Edit war by tom94022 and ILike2BeAnonymous

One: BOTH of you are in violation of WP:3RR. Please allow a cooling off period.

Two: I personally find Tom94022's additional text: begs questions; answers no questions anyone was asking; is misleadingly specific (e.g. not every low level interface to which SCSI interfaced was ST506); incorrect factually (there is nothing as simple as a "bit serial" data stream in the ST506 interface); and poorly worded ("sectors (blocks) of bytes of data"). Apologies, Tom, but that's how I see it. Exactly what are you conveying here, and why does it need to be added to an article on SCSI, which long ago stopped being a bridge -- or an interface -- to another, older interface? Jeh (talk) 07:26, 31 January 2008 (UTC)

I'm not sure what questions are begged, and the asked question is, tell me some more about SASI other than it was a bridge. Beyond that, the original edit is not misleading in any way. There are a number of mis-statements and/or misunderstandings in your analysis of the edit as follows:
First, my original edit was to correct a long standing sentence and not "additional text." Please go back and check. The original sentence was inaccurate. ILike2BeAnonymous truncated the edit and removed IMO significant information.
Second, the statement uses "typically, ST506" which in no way implies, as u state, that ""every low level interface to which SCSI [sic] interfaced was ST506." Furthermore, the sentence is about SASI not SCSI. It happens that most of the SASI controllers attached to ST506 drive interfaces but that is not what is said. So this part of the sentence is factually correct and in no way misleading.
Third, the data cable of the ST506 interface contains lines "+/- MFM READ" and "+/- MFM WRITE" which are bit serial read data and write data lines respectively. In fact, most low level drive interfaces were bit serial since only one head was read at a time. It is that simple and the edit language is factually correct. BTW, the original word was analog and that was wrong.
Fourth, the original language was "sectors (blocks) of data" which i revised to "sectors (blocks) of bytes of data" to add the fact that under SASI like SCSI the blocks are byte organized. It also gets across the point that the bit serial data are converted to blocks of bytes of data. If you have better wordsmithing go ahead and change it but I think it is an important factual point.
Fifth, my last change was technically not a revert since I adopted the term bridge as suggested by ILike2BeAnonymous. So it is not clear that i have violated WP:3RR; he on the other hand appears to have changed nothing from his original truncation.
Sixth, I posted a discussion on ILike2BeAnonymous' talk page to which he never responded.
Based upon posted comments, it appears that both you and ILike2BeAnonymous do not have sufficient knowledge of the historical products and their interfaces to factually comment, so I suggest you leave the technical facts alone and work on wordsmithing. I will shortly make yet another edit in an attempt to keep this information accurate. Tom94022 (talk) 01:30, 1 February 2008 (UTC)
Sigh.
One: The original sentence accurate, though perhaps misleading, in the word "RLL" (MFM is run length limited, but does not use the same run length limits as were used by the early drives billed as "RLL drives"). It was also accurate in the word "analog": see point three below.
Sigh, not only are you wrong about "analog" (see 3 below) you are wrong about the sequence of usage of RLL vs MFM; MFM was used in disk drive art long before the term RLL (to my recollection, first in context of a 2/3(2,7)1 RLL by IBM circa 1978). It was only later that the industry started describing MFM as one form of RLL (specifically a 1/2(1,3) [please don't ding me too hard if i have the specific values wrong, I'm doing this from memory, but the timing is correct].
Two: The entire article is about SCSI, not SASI. If you insist that details on exactly what SASI was an interface to belong in an article about SCSI, I suggest wording such as "(originally ST506)". However this then begs the question of what the ST506 interface is like, and why it needed anything layered on it at all. This is why I strongly suggest wording such as "low-level."
Sigh, RTFP (for paragraph). The paragraph is entirely about SASI. BTW, the first SASI bridge controllers attached to the Shugart SA1000 which predated the ST506 so your proposed wordsmithing would be inaccurate. But don't stop trying :-), that's what gives good articles.
Three: Those lines are analog signals. MFM = Modified Frequency Modulation; frequency modulation is an analog signal. The job of encoding bits as MFM, or decoding MFM to produce bits, was done on the ST506 controller, not the drive. It isn't merely frequency modulation (a la a Bell 103 modem) either; additional frequency shifts are included to avoid excessive length runs, and there is NRZI as well: see MFM. It wasn't until ESDI that the data separator moved to the drive... and incidentally, the historical importance of SCSI as a front end to an ESDI drive is far more important than SASI as a front end to ST506.
Sigh, You are just wrong about the signals being analog. Each is a differential digital signal, they have TWO states, RTFM! They happen to be serial channel bits encoded in a 1/2(1,3) run length limited code that then decodes into serial data bits. The channel bit position is noisy due to the recording process and electronic noise but that does not make it an analog signal. BTW, ESDI was not the first drive interface with an embedded VFO, my recollection is that several SMD models in thee 1970's came with embedded VFO's as did the Xebec Owl (first SASI drive), and Digital Massbus attached drives. BUT AGAIN, why do you insist that we talk about SCSI when this historical paragarph is all about SASI.
Three, continued: As for "bit serial", this is not at all distinctive to ST506. All of today's hard drives are st::::ill fundamentally bit-serial devices at the low level. Only one head is read or written at a time and a single head provides only a single serial bit stream. Very few hard drive have as many as eight heads, and even if they did, it would be pretty much impossible to synchronize them. How would you spare a "bit sector", for example?
We agree that virtually all "hard drives are ... fundamentally bit-serial devices at the low level" so i find it hard to understand your objection to the sentence. I can't take your example question seriously, perhaps you didn't know that the first parallel head hard disk drive was circa 1960, operating 40 heads in parallel and solving synchronization and sparing problems.
Four: Again, there is nothing unique to SASI or SCSI here. Blocks are "byte organized" at the host interface of ANY hard drive controller. As for the phrase "sectors (blocks) of bytes of data", please at least omit the "of data."
I think it is better to drop the term sectors, so as to read, "blocks of bytes of data." This then contrasts bytes with bits. I don't think it is true that all controllers are byte oriented, aren't there still some word oriented systems around? And it certainly wasn't true at the time of SASI.
Five: "Technically not a revert" does not halp you; please see WP:3RR.
OK, I was not aware of the WP:3RR policy, but as I now read it, since i did notify of ILike2BeAnonymous first and early (see 6 below) his subsequent reversion become the first violation of the policy and the page should be restored to the something similar to original language while we pursue dispute resolution, agree?
Six: Yes, but you only did that after a large number of reverts. In any case the article talk page is a much better place for content discussions.
Sigh, I believe I posted the talk at 16:57 after my second, 16:36 revert - this is not a large number! Although his talk page may not have been the best place, I thought it was appropriate because it seemed to be of interest to only the two of us and I was more likely to get a dialog going there. It didn't work, instead what we got was continued reverts.
I believe I have addressed your "technical knowledge" objection. Please, let us not be angry mastadons. You do not wp:own the article, nor even your most recent contribution to it, and you do not have exclusive (or perfect) access to technical information. Jeh (talk) 06:09, 1 February 2008 (UTC)
While I have no desire to be an angry mastadon I continue to assert that the language I propose is technically correct and relevant. None of us wp:own the article. You, in support of the ILike2BeAnonymous' edit, continue to assert facts that I believe to be wrong or at best current truths, so I cannot accept that u are an informed third party to mediate this dispute. In accordance with the WP:3RR policy, I intend to restore the page to nearly the original edit (some of the suggestions are meaningful) and then write it up for dispute resolution. Do you agree this is the appropriate procedure? Tom94022 (talk) 18:47, 1 February 2008 (UTC)
The most obvious objection to your edits, which you make abundantly clear by your very arguments here, is that the edits you propose are TMI—too much information—for the article. The article isn't about SASI, ST-506, MFM or any of the other interfaces being discussed.
Here's the deal: An encyclopedia (at least a worthwhile one) is not just a disembodied collection of information. Therefore, the details given in an article such as this should be pertinent to the topic being described, SCSI in this case. It is not helpful to introduce terms and things which are not themselves described, and which do not contribute to an understanding of SCSI. If you can demonstrate how ST-506, et al, do so contribute, then perhaps they can be put in. Until then, these things are better left out. +ILike2BeAnonymous (talk) 18:55, 1 February 2008 (UTC)
IL2BA's last two sentences here describe my main objection to the overall thrust of these changes. If WP is "not an indiscriminate collection of information" (WP:NOT), then certainly an individual article such as this one on SCSI should not be. Details on SASI or ST506 should be in their respective articles, if anywhere. As for the technical points raised by Tom above, I don't have time atm to collect references and respond in detail ATM, but I will. I've found says that the MFM data lines at the ST506 connector are indeed analog; but I'll look deeper; I suggest you do the same.
In the 1980's I designed ST506 compatible disk drives and controllers; the signals are digital, noisy but digital, save yourself the time.Tom94022 (talk) 20:14, 1 February 2008 (UTC)
Thanks but I won't; now I have to find out why I was that confused. Jeh (talk) 07:37, 3 February 2008 (UTC)
Meanwhile, let me assure you both that my intent in posting the 3RR warnings was simply to bring the discussion to the talk page here, where it belongs, and hence attract the attention of other interested editors. I don't see that any mediation or dispute resolution procedures are yet indicated. If you want to escalate to a dispute resolution process anyway that is of course your right, but I don't see why you think that's required now that all parties have at least started talking here. Jeh (talk) 19:56, 1 February 2008 (UTC)

The questionable sentence:

"The Shugart SASI controller provides a interface between a hard disks serial analog interface (called RLL) and a host computer's need to read sectors (blocks) of data."

was added by by Bergert (Talk | contribs) at 06:09 on 30 January 2007 and has survived unedited for one year. You may think it is TMI but he did not and I do not, nor has anyone else for one year. Nor do I understand both of your continued and unexplained refusal to accept SASI as part of the history of SCSI - initially the major difference was the name. The only question on the table is what version we return to while we work out the dispute. So I am going back toward the original version but with some of what I believe to be obvious errors corrected. Since we are under WP:3RR policy, i believe it to be a violation if either of you then make any substantive deletions. Tom94022 (talk) 20:14, 1 February 2008 (UTC)

Subsequent to the above posting IL2BA completely reverted three edits back to his singular version. I consider this to be a gross violation of the WP:3RR policy and have so reported it. It is particularly disappointing that he went as far as to suppress a correction (with reference) to the SASI announcement date, 1979 was not correct, but I guess accuracy doesn't matter in his zeal to own the page.Tom94022 (talk) 23:01, 1 February 2008 (UTC)

Subsequent to the above posting IL2BA again completely reverted the three edits back to his singular version without any talk at all. Is he even bothering to read the edits? It is clear from a deleted reference that SASI was introduced in 1981 but he continues to revert to 1979 - is there some basis to his reversion other than he doesn't want it changed? It is clear from a deleted reference that SASI and SCSI-1 are the same thing (actually SASI is a compliant subset of SCSI-1)! Isn't this relevant and doesn't it rebut any contention that somehow SASI should be on a different page? It turns out because of my inexperience, my first posting at the Wikipedia:Administrators' noticeboard/3RR 3RR Administrators Noticeboard was not formatted properly and no action was taken, so I have resubmitted my request in what I hope is an appropriate form. Tom94022 (talk) 07:10, 3 February 2008 (UTC)

I'm not sure that is strictly 3RR (it's three reverts, or near-reverts, wihtin 24 hours, per editor) but it sure doesn't feel like an attempt to build consensus. My understanding is that the Right Thing in cases of content dispute to put your suggested version here, and then subsequent revisions can be "tried out" here and commented on. Jeh (talk) 07:37, 3 February 2008 (UTC)

SASI as a part of SCSI history

((RFCsci | section=SASI as a part of SCSI History !! How much SASI history is relevant to SCSI !! time=19:00, 3 February 2008 (UTC)}}

It has been suggested that information about SASI in the SCSI history section is TMI (too much information) and on such a basis a number of edits have been disputed and continuously reverted. 216.103.87.80 (talk) 19:00, 3 February 2008 (UTC)

As one of those who raised the objection to the recent edits as TMI, I think my latest revision has rectified much of that (basically, removing the bit about "bit serial interface" that adds nothing to the understanding of the SASI--> SCSI history). The remainder of it seems to be OK. We'll see. +ILike2BeAnonymous (talk) 20:08, 3 February 2008 (UTC)


With all due respect to your knowledge of the subject, some of your proposals have been dealt with already, and you seem to have ignored my most recent edits, which were copy edits that didn't change the substance of your previous edits. I removed the phrase "bit serial interface" for reasons stated above and in the edit summary, and clarified the sentence about the size and location of the SASI board in relation to the HDD. I think at this point, all of your substantive issues have been resolved, correct? +ILike2BeAnonymous (talk) 20:28, 3 February 2008 (UTC)
We had an edit conflict (now commented out) during which you accepted 2 of the 3 disputes, leaving only the second one - thanks for finally agreeing to something. I take it SASI history is no longer, IYO, TMI?

Regarding the one remaining, second dispute, I am restating it below

  • Second dispute:
Original sentence:
The SASI controller provided an interface between a hard disk's serial analog interface (called RLL) and a host computer, which needed to read sectors (blocks) of data.
Proposed correction:
A SASI controller provided a standard interface between a hard disk drive's bit serial data interface and a host computer, which needed to read blocks of data.
IW2BA proposed truncation:
The SASI controller provided a bridge between a hard disk's low-level interface and a host computer.
Comments:
In the original sentence which existed for about 1 year, the terms "analog" and "RLL" were incorrect and the phrase "sectors (blocks)" awkward. After several iterations I am proposing the corrected sentence. I would have preferred to include the ST506 as an example of a then extant bit serial interface, but reluctantly have agreed to drop this.
At this point there is no dispute that the low level interface of virtually all disk drives at that time was bit serial. The whole point of SASI was that bit serial interfaces then existing and projected for the future acted as a barrier to system integration but a standard byte oriented block interface would eliminate and/or greatly reduce the barrier. That was SA's objective in promulgating SASI! The term that came to be used was "intelligent interface" and today all HDDs come with intelligent interfaces, the low level interfaces have disappeared! To leave out SASI's historical tranformative nature from bit serial to block is to remove the relevant information. I actually intend to expand upon this point by tying the SASI concepts to the SCSI concepts above when I have some more time to find supporting references, btw I think some of the SCSI concepts are incorrect and that is what has delayed my further edits. I would welcome any such additions. Tom94022 (talk) 20:59, 3 February 2008 (UTC)

I'm not wishing to throw gasoline on any fires, but I suspect that the less-than-exact use of the term 'analog' when referring to ST-506 bit-serial MFM signalling isn't entirely inaccurate, if you use it to mean non-digital. Where 'digital' would imply some sort of fixed clock or framing type of system such as RS-232 has. ST-506 didn't, and was merely a faster form of the common floppy interface at the time, where the bit serial stream was wobbly and about as raw as could be had. I don't think there was much more on the drive than the usual head amplifier, one that used differential signalling for the hard disks. The required clock/data separator (for reading) was the hard part! I don't know if there is a term suitable for use between analog (obvious) and what is commonly thought of as a digital interface. ISC PB (talk) 03:11, 19 November 2008 (UTC)

Its hard to say its a fire when there has been no comment since February. Analog is a continuously variable signal, the signal on the interface is a binary digital signal with the information contained in the timing of the transitions. The fact that the timing is noisy doesn't make the signal analog. Digital is accurate, binary might be better. Tom94022 (talk) 03:40, 19 November 2008 (UTC)
Just to try to put some water (OK perhaps fuel!) on this fire, IMHO the interface to an ST506 drive, just like to a floppy, is digital in voltage and analogue in time. The controllers I used were all MFM encoding, but ISTR we looked at another one (ca 1982) that used 2,7 RLL but rejected it on grounds of cost despite its technical superiority. That change does not alter the data as far as the drive sees it - it's still just a stream of phase transitions on the media, it's still a TTL signal on the interface, and it's still the job of the controller to extract clock and data from that stream. Number774 (talk) 16:50, 9 February 2009 (UTC)
The dictionary definition of analog is continuously variable. The digital transitions in the data stream are not continuously variable, they are quantized about an expected time. During write the noise is low but during read the noise is high for several reasons. You might contrast this to FM, where discrete transitions vary in a continuous manner as a function of the transmitted bandwidth. There is no FM in these disk drive signals, there is phase noise but no modulation. Tom94022 (talk) 18:10, 9 February 2009 (UTC)

I struck out the malformed RFC at the beginning of this section. Since there have been no substantive comments proposing the deletion of the SASI material from the article I am going to delete the dispute tag from the History section. Tom94022 (talk) 18:10, 9 February 2009 (UTC)

Devices

SCSI is a peripheral interface: up to 8 or 16 devices can be attached to a single bus.

Cisco says up to 15 devices?!? --Stefán Örvarr Sigmundsson (talk) 20:18, 12 February 2008 (UTC)
They may mean not counting the "initiator" (the SCSI controller itself), which is counted as a "device". +ILike2BeAnonymous (talk) 20:22, 12 February 2008 (UTC)

Is the parallel SCSI market dead?

It appears that SATA and SAS now own the hard drive market, and parallel SCSI is nearly obsolete.

Looking around on big-name drive manufacturer websites, I cannot find any information about current parallel SCSI drives bigger than 300 gigabytes, and that drive size has been available for a couple years now. Meanwhile there are many SAS drives over 300 gigs:

Are any new parallel SCSI drives still being manufactured? DMahalko (talk) 08:20, 26 October 2009 (UTC)

Parallel drives are still being manufactured and, in fact, we exclusively use parallel drives in our servers. We haven't been sold on the supposed "advantages" of SAS—we've noted no performance advantage over the parallel architecture.
Bigdumbdinosaur (talk) 19:33, 19 July 2011 (UTC)

Server drive performance: Data density vs RPM ?

In the server marketplace the fastest drives are the most expensive, and pushed as being the "enterprise class" models. However, if you have a 300 gb 15000 RPM drive, and a 600 gb 7200 RPM drive, both with the same number of platters, is the 15000 RPM really faster? Or is the performance going to be about equal?

Perpendicular recording allows a higher sector density per cylinder, so a 7200 RPM drive with twice the sectors per track of the 15000 RPM drive should apparently perform equally.

It would appear that what Seagate calls their "enterprise class nearline storage" 2 TB 7200 RPM SAS, will probably have performance at least equal to, or exceeding the abilities of their 600 gb 15000 RPM drives. Since the 2 TB drive has about 3 times the cylinder data density of the 600 gig drive, and it appears that it may perform as well as a 21,600 RPM enterprise class drive.

DMahalko (talk) 08:28, 26 October 2009 (UTC)

Error in Fast SCSI Max Length?

I'm looking at the Parallel SCSI table in the article and am a bit confused over a couple of the maximum length entries. Both "Fast SCSI" and "Fast-Wide SCSI" have a maximum single-ended length of "1.5–3 m". I believe this should simply be "3 m".

I recognize that both "Ultra SCSI" and "Ultra Wide SCSI" have max lengths that vary between 1.5 meters and 3 meters based on the number of devices connected to the bus, but have been unable to find any such reference for Fast SCSI.

Unfortunately I don't have access to the actual SCSI specifications. Can anyone verify whether or not the article is correct?

ChadCloman (talk) 05:34, 19 March 2010 (UTC)

Yes, Fast SCSI is allowed up to 3m, regardless of no of devices - I've just corrected it. -- Zac67 (talk) 13:14, 21 March 2010 (UTC)

U320 redirect is unexplained

"U320" redirects to the SCSI page. However, there is no mention of "U320" in the article, so the meaning of the term and the purpose of the redirect both remain obscure.207.188.235.142 (talk) 19:03, 3 June 2011 (UTC)

It would be useful to have the standard diamond logo in this article, to help in port identification. Some people also seemed to think that the cuniform-style glyph in the below photo (far right) is a non-standard SCSI logo.

-- Beland (talk) 12:17, 11 July 2008 (UTC)

Can anyone add logos for the single-ended, differential and LVD SCSI variants. Alecv (talk) 11:33, 26 October 2009 (UTC)

Other SCSI interfaces

I believe that this section has information mixed up; I don't have personal knowledge of SSA or SSA 40, but I do know that FC-AL is based on Gb (8Gb = 1GB).

This means that 1Gb, or 1000 Mb, would actually be 125 MB per second. Same for 2Gb, =250MB/s. 4Gb = 500MB/s. These are also theoretical throughputs, which noting that in the columns wouldn't hurt.

SAS has a 3Gb connection, not 3GB. 3Gb = 375MB/s. FC AL 8Gb & SAS 6Gb exist as well. Madrigaldeath (talk) 22:21, 3 June 2011 (UTC)

FC speeds match those of the FC article - I assume they use 8b10b line encoding (1Gb/s line speed = 100 MB/s net throughput) - SAS does that as well. Zac67 (talk) 22:41, 3 June 2011 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:SCSI/Archive_1&oldid=1159465216"