FERELLI: Welcome to our roundtable covering SATA, SAS and plugfesting. Special thanks to the SCSI Trade Association for its help in setting this up. Harry, if you would start us off with a brief overview of SAS and SATA.
MASON: Well, the serial attached SCSI is an architecture that was created as a replacement for the legacy of parallel SCSI technology. And it's really both, products as well as an infrastructure. And the infrastructure for Serial Attached SCSI is designed so it can accommodate both serial attached SCSI products, as well as serial ATA products. The intent for serial attached SCSI is really to scale the serial ATA into more of an enterprise class of architecture, so that it has the attributes required to support the enterprise environment. And those attributes are really ones of performance, in terms of the increased link speed, the dual-ported capability of the interface, and the full duplex nature of the interface. The scalability, in terms of being able to address and increase the number of devices that it can address, and then the manageability to be able to run Legacy, SCSI, Middle Works and software--so that we can manage these scalable architectures in these enterprise-class storage environments.
FERELLI: One of the first things I would like this roundtable to address are some of the challenges that are going to come up in terms of physical compatibility and interoperability. You have a number of companies that are going to be involved in development of SAS and SATA-specific product. What is a reasonable expectation for physical compatibility and interoperability between the various elements that are going to be built by various companies?
MASON: Well, the SCSI Trade Association, in order to manage that risk into the market, has created a series of plugfests. The first of which was held March first of this year. The second one will be held the week of June 21st, at the University of New Hampshire in the I/O labs. And we had 16 companies participate in the first plugfest. We do anticipate that there will be even more companies participating in the second plugfest. One portion of the plugfest will be dedicated specifically to testing SATA products operating within the SAS infrastructure. And so, we will have Wednesday afternoon and Thursday morning testing available for companies to bring SATA products in, plug them into the SAS infrastructure and test these products to see how well they operate within that environment.
I think there really are three objectives of the plugfest overall. One, we want to test to make sure that the serial attached SCSI is interoperating. Secondly, we want to make sure that we have the ability to test legacy SCSI software. And third, we want to address this issue that I just spoke about regarding serial ATA interoperability within the infrastructure.
CZEKALSKI: But also keep in mind that today serial ATA products are, in fact, shipping--they're actually a well-known entity. And, in fact, there are solutions from a disk drive standpoint, or device standpoint, that already exist for serial ATA. There are also serial ATA host bus adapters that fall under the SCSI protocol stack. So, the translation between the standard SCSI protocol stack and serial ATA is already demonstrated and well known. That protocol stack is actually the same one used by SAS, so the translation process and entities that go into that, are actually already well known. So, it's just a matter of putting the things within the SAS infrastructure, controllers and host bus adapters and the expanders. From the SAS standpoint, the SAS specification is extremely detailed, far more than any previous specifications done by any of the E-10, T-13, T-11, any of those organizations. And the specification is much simpler, in many respects, than parallel SCSI because of the way messaging is handled. Clearly, I know our folks believe that it is much easier to implement and to debug, and to get working than the current parallel SCSI implementation. So, we feel fairly confident in the interoperability we've also seen with controllers and expanders so far. To date, they have shown that things actually come up very quickly and work very well.
IZQUIERDO: The only thing that I would add is that, from an interoperability perspective at the physical layer, our signal integrity team has been pretty encouraged about what they have seen so far. The fact that it is point to point, and not a bus that requires an infinite number of permutations to test, has made it much easier to assess the physical layer interoperability. From a pro/con operability perspective, the other goal that we had very early on in the SCSI Trade Association was to drive a lot more early interaction between components, suppliers, system suppliers and drive suppliers, at the modeling level. I can't go into them in detail, but we are participating in numerous NDAs with our partners and component suppliers regarding sharing the bus functional models and simulation data, so that even before we see first silicon, we have a pretty good idea that things are gong to inter-operate well. So, I think we've tried to avoid some of the mistakes that we have made. In earlier technologies, the fiber was difficult. I think we caught some of the mistakes we made there and are trying to avoid them with serial attached SCSI.
FERELLI: Actually Javier's comment brings me to another good point. In the plugfest that you have coming up now, and in the future, what sorts of challenges and processes will you be facing and what kind of testing processes do you have to put in place?
MICHELETTI: I think that everyone on the phone will agree that SAS is targeted at enterprise server application space and, you know, this mandates a very high level of reliability, robustness, so all the companies that are working on SAS components are looking at the SATA interoperability as a key requirement. And they're treating it with high importance. One of the advantages that this interoperability brings, though, is that test equipment (such as CAT makes) is inter-operable with SAS and SATA--so, in fact, a vendor can purchase the single analyzer, a tester now, that supports both SAS and SATA. It's one box that does both, so this type of equipment is going to be needed at a plugfest to verify interoperability.
FERELLI: Marty? What grades of test does your equipment perform?
CZEKALSKI: Well, the testers are primarily focused on the SAS side of the fence--in testing compliance right now--at the link layer and transport layer. But in the next few rounds, we will be adding the SATA specific interoperability testing. I think a lot of these analyzers and testers (in particular testers) are pretty generic in that you can create pretty much any kind of packet you wish. And, there's enough similarity, there is so much similarity anyway (SAS designed to be compatible with serial ATA) that the process for making packets is pretty much identical, and you can create both and interchange most with these analyzers.
NEER: From the plug-it-together perspective, the standards organizations have been working on the various types of interconnects involved--whether it be drive to backplane, controller to backplane or external interfaces. And they're all being specified, and most of the connector companies are involved in the development of these specifications, and many are shipping products already. And so there will be compatibility on the physical side, on how you plug these together. It's a more complete system development this time. And we are all involved in it, and each one trying to do his piece.
FERELLI: Jay, that actually brings up another point as well. One of the advantages that is touted per SAS, is its capability not to have to pull things like connector changes as going between SCSI and SATA, or low performance to high performance or mid-range performance to high performance peripheral. How do cabling and connectors leverage in a test situation?
IZQUIERDO: Well, we'll be able to use the same cables, regardless of the interface that we're dealing with. The only part that's really not plug-compatible, if you will, is that the SATA backplane connectors will not accept a SAS drive, but everything else is plug-compatible.
MASON: I'll also add that the hurdle test, if you will, which is the physical layer test that tests for the interoperability, has been implemented by UNH for the SAS plugfest. And that's based upon their experience with Fibre Channel physical testing, as well as other physical testing. So they're intimately involved in that physical level, and that's what we're using as sort of our hurdle test to be able to get into the lab to start interoperability testing. And UNH has also started a SATA consortium, so that we'll also be testing for SATA. In respect, that will also leverage the same test set.
FERELLI: Now, I would like to look at a couple of the traditional criticisms of plugfesting and I'd like you to respond please. The first you may have already taken care of: the issue is that only a limited amount of players are involved and invited into the plugfest situation. But as I understand it, STA has initiated a new kind of membership classification especially for this sort of testing outreach.
MASON: You know, in the past--and I think Javier alluded to this earlier--standards like Fibre Channel created plugfests. Once they had products out and they didn't perform well together, it became more of a debug environment. When we started the SAS initiative, we had planned the plugfest from the outset, and have had products really even at the FTGA level operating in the plugfest environment, prior to some of the original silicon being out. So, I think the plugfest was sort of baked into the thinking very early on. Second, we realized that we did have these three objectives, one with Legacy compatibility, two with the SAS interoperability and three, with the SATA interoperability. So we really felt, as Marty said, since the SATA products have been shipping for about a year, they're a well-known quantity, and those are things that we need to bring into the plugfest environment and--as you said Mark--offer this new level of membership that allows the SATA folks to bring their products into our plugfest environment to make sure that we have accommodated all the nuances of those products that are already shipping and in the market today.
FERELLI: Harry, would you discuss that membership class briefly?
MASON: Yes, the membership is in. We kicked around a lot of different numbers here but it's a membership that allows you to participate in the Wednesday and Thursday SATA test portions of the plugfest. It is open, so you don't have to be a member to participate, but if you do join as a member then you get discounted rates on the plugfest, and you also get a chance to participate in the definition of the tests that define the interoperability.
FERELLI: Thank you. Now the second traditional problem with plugfests, I have to go in with an exemplar. When you are putting together a plugfest, you are sending large equipment and lots of very gifted and talented engineering personnel to keep everything set up. I have had people at large conferences with plugfests say to me, "I don't know if it is the actual products that I would be buying that are being tested." They feel that it is something that has been tweaked in a lab to optimize for performance in the plug fest. Do you understand the nature of their complaint?
NEER: I think I do. Maybe, perhaps, they're a little different than the way we structure these plugfests. I think the kind of plugfests you are talking about are the conferences where people can pretty much go in and see how things are working and get some feel for things. The thing here is, this is all under non-disclosures, and none of the information can be given out other than the participants that are actually there. There are no observers permitted, you can't just go in and watch and see what's going on. You accept at sign-up not only to come to this, and pay your money to come to it, you actually have to bring something and actually have to test it and participate in part of the process.
FERELLI: Oh, you mean I can't come in with just my notebook and cover the thing? Shame on you.
MASON: We've actually modified some of the rules between the first plugfest and the second plugfest to completely discourage any type of marketing activities within the plugfest, and limit the participation from external consultants, if we felt that they were inadequately representing the companies' products they were there to help in the interoperability testing.
IZQUIERDO: The other thing I would add is that the focus hasn't been so much on whether one product is 10% or 20% quicker than a different product. It's been pretty much completely on interoperability and of the protocols and--to maybe high-light what Harry said earlier--the FPGA has actually been invaluable in this whole scenario because it gave us a much earlier opportunity to get some very effective interoperability testing done in early plugfests. So the FPGA concepts haven't been as prevalent until maybe a couple of years ago. So, it was something that we didn't have the opportunity to use and maybe some of the earlier technology transitions, but it has been very valuable for the SAS transition.
FERELLI: Would it be fair to say that the testing activity you are going to be taking up is actually more for the benefit of the participants than it is for the general IT public?
IZQUIERDO: I wouldn't say that. I think that the IT public will benefit greatly from having the technologies, the components, the solutions, from all the suppliers that participate in the interoperability testing. So I think the whole industry benefits.
MASON: Yeah, I think the adoption of the standard is really dependent upon how successful we are, with the three objectives that we've talked about for the plugfest. And I think we realized early on that this is not about getting a couple people's products to work together, it's about making and creating an industry here. And in order for that to happen, we have to have good end-user success and really be able to preserve that compatibility and to inter-operate with the SATA drives.
FERELLI: Correct me if I'm wrong, but this has a lot of the feel of the early development of SCSI itself.
MASON: I would say that, having been one of the people who has been around from those days.
FERELLI: You said one of the only non-compatible areas is the small form factor drive back-plane, is that it?
CZEKALSKI: No, I think what was stated was that the original SATA backplane connector--as it's defined--is meant just for SATA. SATA devices will not accept a serial attached SCSI device, and that is understandable because a SATA-only backplane, a SATA-only controller, obviously would not be able to talk to a SAS device.
FERELLI: Are we talking about a new generation of SATA drives that would be SAS interoperable?
FERELLI: Okay, correct me. What are we talking about?
IZQUIERDO: The SAS infrastructure is a superset of the SATA infrastructure. So, if you have a SAS infrastructure (connectors, controllers, etc.) you can plug in either SAS or existing SATA technology. There are dual-port connectors and additional functionality on the SAS drives that the SATA drives don't have; but they are a superset, so nothing changes on the existing SATA infrastructure. In fact, we chose to totally leverage that physical layer and the connectors, etc., so that they could plug into SAS infrastructure. And that's what we think is the key customer value is that choice. The fact that you can have a SAS infrastructure and choose to deploy enterprise drives or high-capacity lower cost drives.
What we did not want to do is--since existing SATA implementations don't understand the SAS protocol, therefore, don't support the SAS protocol--we didn't want that existing SATA backplane connector to be able to accept a SAS drive. So the connector on SAS is keyed such that it does not allow the end user to insert that SAS drive into the existing SATA backplane connector, and that was done on purpose.
FERELLI: Which devices are going to be examined during the test sweeps at the plugfest? Drives, HBAs, what else?
MASON: Testers, analyzers, cables, connectors, backplanes, host adapters, expanders, controllers ... Maybe a mux, a kind of piping device.
MICHELETTI: Right. A two-to-one SATA mux, Mike, would also be probably be available for testing--as well as some other SATA and SAS-compatible muxes are available.
MASON: I don't know that we'll have any bridges at this one, but I understand that there are bridges being developed.
MICHELETTI: Those go between the parallel SCSI and SAS.
FERELLI: That might not be quite ready for prime time. How many plugfests are you planning between now and the end of the calendar year?
MASON: Including the one in June, there will be three more plugfests this year.
FERELLI: Are they being put together in conjunction with another organizational activity or is this something you're doing completely on your own?
IZQUIERDO: Well, all the plugfests will be done at UNH. And after each plugfest, we do a postmortem and we get the feedback from the test results, and then we, as a group, schedule the subsequent plugfest events. So, at the T-10 week in July, at Colorado Springs, the group will get together, and we'll probably decide on the date for the third quarter plugfest.
FERELLI: Are some of your activities going to be set into some of the ANSI committees to aid in their standards-creating efforts?
MASON: Yes, Marty is our liaison between the SCSI Trade Association and T-10 and--
FERELLI: Oh, he's the one with the bruises, huh?
CZEKALSKI: I'm the one.
MASON: --the go-between, between the standards organization and the marketing organization. So Marty brings the feedback from the plugfest back into T10 though that venue.
FERELLI: How is T-10 reacting to your efforts thus far?
CZEKALSKI: It's been very good. I mean, there's been a lot of participation from the companies in T-10. And actually, if we had any issues that arise as a result of the plugfest, that we identified that require changes, certainly they've been very receptive during the first plugfest. There were no issues that arose out of that one, so we'll see what happens this time.
MASON: I'll just add that one of the things that we've added on the SCSI Trade Association meeting agenda has been these plugfest meetings during the T-10 week, and we've gotten very good participation from the T-10 folks in those meetings. Those meetings are now under non-disclosure, but the companies that are actively involved in it have signed the non-disclosures. A lot of the folks that attend those are actually directly out of the T-10 organization.
FERELLI: That kind of tight cooperation ought to, theoretically, ease the standards efforts, although some of their discussions can get pretty purple sometimes. Could you give me some of the dates for the upcoming plugfests at the University of New Hampshire?
IZQUIERDO: We haven't planned out the entire year. We've been doing that after each plugfest, so we will lock in a date sometime in the second week of July.
CZEKALSKI: It will probably be in the September time-frame, because we are targeting two-and-a-half- to three-month intervals.
FERELLI: If any of our readers would like to come and play, whom should they contact?
CZEKALSKI: There's a link on the SCSI Trade Association website. There's a plugfest drop-down menu. Just follow the link to the application.
RELATED ARTICLE: Roundtable participants
MARK FERELLI: moderator; editor-in-chief of Computer Technology Review, WestWorld Productions, Inc.
HARRY MASON: director of Industry Marketing at LSI Logic; president of the SCSI Trade Association.
MARTY CZEKALSKI: Interface Architecture Initiatives manager at Maxtor.
JAVIER IZQUIERDO: director of Controller Development for the industry server group at Hewlett Packard.
MIKE MICHELETTI: product manager for the storage products at Computer Access Technology.
JAY NEER: strategic product manager (with focus on storage connectors and cables) for Molex Incorporated.
|Printer friendly Cite/link Email Feedback|
|Publication:||Computer Technology Review|
|Date:||Jun 1, 2004|
|Previous Article:||The marriage of physical and logical access: unifying the keys to the kingdom.|
|Next Article:||Smooth sailing for SAS? Not all technologies are created equal.|