This message is from the T13 list server.
> > > > > Hale Landis 04/11/02 08:27AM > > > > > I don't want to start that whole discussion ... but > Andre Hedrick 04/11/02 12:18PM > a more modern document, > if none exists, create one and submit it. The first English draft appears at http://members.aol.com/plscsi/ftf.html , written last Tuesday (April 9). Can I rely on folk here to bleed red ink all over it? Should I also mention that the discussion here on the T13, T10, and sbp2 reflectors has been more useful than may be apparent, just watching it the public half of it? 1) An engineer from Maxtor phoned me in person one day, and clued me into much of life. In particular I had been slow to appreciate that a Ata/pi UDma sender of data can avoid sending more than one fabricated byte - in Ata/pi UDma it's only the count of received bytes discarded that's difficult to control/report precisely. 2) A bridge supplier from Taiwan connected with Utah procurement folk I know thru me because I was speaking up here. The difference between "mostly works" and "just plain works" has value. 3) Hale's teaching me to always speak BSY DRQ in the same breath of C/D I/O. I don't know exactly why I'm finding that hard to learn, but I agree it's a good thing. 4) The discussion produced the attached claim that folk who implement the analogue to Atapi known as 1394a Sbp2 in practice quietly (i.e. without any applicable public spec) resolve host/device disagreements over byte count by copying from/to the host what the host asked, by copying to/from the device what the device asked, they flatly don't check for agreement. That's creative enough I had failed to conceive of that solution, independently. My mind was blocked in part because I know of legacy apps that die nastily if you do this. 5) The discussion produced the http://members.aol.com/plscsi/ftf.html document I mentioned, also the Dos/Windows/Apple/Linux tool set of http://members.aol.com/plscsi/ for demoing how easily host/device disagreements over byte count occur. 6) I hear Usb Mass on Linux for the 2.5 kernel will real soon now be revising its state machines to handle more of real life. Etc. > a more modern document, > if none exists, create one and submit it. Maybe a piece of what's driving this is the VHS/BetaMax reincarnation known as Usb2/FireWire. (I'd buy a flat panel iMac myself, if only I could find a FireWire/Usb2 bridge.) My employer sells PC peripherals - the R&D folk lose something like half their opportunities to having to engineer everything two or more times. We're not solving this once. We're solving this again and again and again for an ever growing number of variations on how to pass thru Scsi traffic. Here I'm sharing my pain, with an as yet credible hope of finding future volunteers to help lessen it as much as the past volunteers have. x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ -----Original Message----- Date: 04/11/2002 11:08 am (Thursday) From: Pat LaVarre To: [EMAIL PROTECTED] Subject: Fwd: your roadmap towards a more transparent Sbp2 As copied below, I think I'll start asking 1394a/Atapi people what their roadmap is towards ever more perfectly transparent bridges ... Meanwhile, anyone want to comment here without benefit of NDA? (-: Who am I? I'm that customer from Hell. :-) Curiously yours, Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ Subject: your roadmap towards a more transparent Sbp2 Another three interrelated questions, if we may: Q1) Can your bridge firmware alter the content of "the status block" before your 1394a/Atapi bridge stores that block to "the status_FIFO address"? How arbitrarily? Q2) Can your 1394a/Atapi bridge firmware determine how many bytes of data your hardware copied from/to the attached Atapi device? For Atapi Pio, we mean the sum of x1F5:1F4 byte counts presented together with BSY:DRQ = 0:1 and C/D = D = 0. For Atapi UDma we mean 2 * N, where N is the number of "word"s clocked across the bus by the sender of clocks. Q3) Can your 1394a/Atapi bridge firmware determine how many bytes of data your hardware copied from/to the 1394 host? And how many bytes remain of the data_size or of the segment_length of the last page table segment used? And if more unused page table segments exist? We ask because ... In 1998, in house, we developed a test suite to evaluate "transparent" Usb bridges to Scsi-over-Ide (aka Atapi). (Some English describing that suite appears at http://members.aol.com/plscsi/ftf.html ). In 2002, we ported our test suite to survey some 1394a/Atapi bridges. No 1394a/Atapi bridge we've tried passes our suite without a problem: none rise above the level of "maybe good enough". The Ansi T10 committee designed one limitation into Sbp2 that makes complete transparency impossible: Sbp2 can't count the bytes copied. An Sbp2 device cannot tell its host that it did copy less than allowed nor that it would have copied more if allowed. This means noone can design a 1394a/Atapi bridge to work everywhere legacy Atapi worked. The bridges we've surveyed settled for one of two strategies. Some hang until reset (and when they hang, they hang til power-cycled no matter how many ManagementORB's you try sending) ... ... the others quietly make up the difference in the middle. That is, they quietly discard data copied from the source or they fabricate data copied to the sink. They copy from/to the host what the host asked, they copy to/from the device what the device asked, they don't check for agreement. This reality shocked some of us. We know for a fact this behaviour breaks legacy apps unprepared to accept more data copied In than a legacy form of Scsi-over-whatever actually does copy In. We're less sure of the effect of fabricating extra data to copy In or Out. We hope nobody ever does read that data later. At a glance, this data appears indeterminate, which by definition makes its effect harder to measure. If your bridge firmware can know how many bytes it lost (fabricated or discarded) before storing "the status block", then we can hope, as the 1394a mass market ramps into existence, we can arbitrarily adapt how we handle these situations to the undocumented strategy that turns out to work best. If not, then til we change out your hardware we have to live with the design you're shipping now. We'd like to hear your design was conscious, indeed we'd like to be told we're wrong to think no public standard guided your choices here. Hence our two questions above. Thanks in advance, x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ ****************************************************** SBP-3 protocol for FireWire Mailing List Unsubscribing: send email to [EMAIL PROTECTED] with subject "unsubscribe sbp3" Set to Digest Mode: send email to [EMAIL PROTECTED] with subject "subscribe digest sbp3" Help?: send email to [EMAIL PROTECTED] with subject "help" ******************************************************
