This message is from the T13 list server.
Jim M: > Pat, What are you talking about? Before I saw the next post I was wondering if we had exceeded the communication limits of email, ... > > Please tell me that and how I'm wrong? > Pat, The problem I have is ... ... but I think now I see we have again inched closer to clueing me in. Thank you again. Specifically ... > > TWO > interfaces here ... I'll assume > > USB ... between host and bridge > > ATAPI ... between bridge and device Ok. > there is a requirement > to transfer correct user data. > the principle applies elsewhere Good to hear. I agree. > as I earlier asserted, > you only need at most > a single bit indicator > read by the bridge > at the end of a command - nothing more. This may be, in a nutshell, the key element in your perspective that I don't yet fully understand. How can you agree the byte counts can be off by one ... ... but then not agree that the byte counts can be off by X * 2 + 1, with the max X rising above zero as burst rates increase beyond SwDma? > If the bridge is the ATAPI receiver > (you earlier mentioned that > the bridge as ATAPI sender is not an issue), Ahhh. Disconnect, whoops, sorry. I don't know specifically what portions of which of my posts to disavow, but this quote from me is wrong, taken in isolation. I can now imagine at least two ways I may have led people to misunderstand me. > the bridge as ATAPI sender is not an issue), > wrong ... at least two ways 1) Maybe my English didn't distinguish sharply enough between sending/receiving clocks and sending/receiving data? By definition, since we added UDma to the mix, knowing just which way the data moves doesn't tell us if the bridge is sending or receiving clocks. Yes, in bridging, we can more often get away with moving ore than expeced bytes OUT than we can get away with moving too many bytes IN. To let us move too many bytes OUT, often all we need is a Usb host that rounded up its allocation of pinned physical pages to the next whole page, and an Ide device that quietly discards extra bytes moved OUT. To let us move too many bytes IN, we need something fewer Usb or Ide device vendors can guarantee: a top-level app paranoid enough to have rounded up its memory allocations far enough to end with at least one free aligned block. All this holds true no matter if the bridge or the Ide device sends the clocks to move data in or out. > the bridge as ATAPI sender is not an issue), > wrong ... at least two ways 2) Maybe my English didn't emphasise sharply enough how symmetric the residue issue is no matter who receives the clocks? The issue I think I see is the receiver of clocks wanting to move at most R bytes but by protocol failing to stop the transfer before as many as R + X * 2 + 1 bytes clock across the bus. I think I see this indeterminacy built into all the Ide data transfer protocols, with the max X rising above zero as burst rates increase beyond SwDma. I only see the indeterminacy go away if I hypothesise some out-of-band communication the receiver uses to limit how many clocks the sender sends. I see now Ata, in contrast to Atapi/Scsi, offers more than one form of such helpful out-of-band communication: a fixed block size of x200, only whole block transfers, a gentlefolk's agreement to discard data transferred with an ERR, etc. > Ata, in contrast to Atapi/Scsi, I hear Apple Scsi tries to keep S = R except for data transferred with an ERR. That helps, except when not talking Ide like Windows does hurts more. > If the bridge knows, as the ATAPI receiver, > how many bytes it wants (say R), > then it just sends those to the host > via the USB interface. Yes if. > so what [if] ... > bytes are still in the bridge > from the recently completed DMA burst? > ... until the last DM burst from the ender. Yes, no matter how confused I was about this two weeks ago. > [when] the command is [] over > ... [a compliant] sender [of clocks] ... > does not send more data. Yes. So how do the sender and receiver come to agree on how many bytes to move before the command is over? They don't. S does not equal R. Not precisely. Not in bus traces of the real world. With UsbMass, if you have a fully transparent Usb1/Pio4 bridge, you can easily trigger on S != R in the Usb bus trace. Before UsbMass, recognising S != R from the reasonably chaotic consequences of the symptoms on a bus trace was rather more difficult. Agreed we have no issue when S = R i.e. when the sender and the receiver agree in advance which byte is the last byte. For example, we have no issue when we're reading and writing an agreed count of whole blocks, each of an agreed size, without ERR. > S does not equal R. Not precisely. One of the distinguishing quality-of-service factors in Usb1/AtapiPio bridges has been how well they handle S != R. We do include a test of this among our procurement criteria - a test whose results correlate loosely with eventual sales volume. I've heard no cause to believe the happening switch to Dma should change that. I'm not saying that people can't ship bridges that don't cope well with S != R. Clearly lots of people do. Hey, it doesn't crash more often than Windows. I'm saying bridges do have to handle S != R well in order to compete well in the plug 'n play world out beyond Windows. > Please tell me that and how I'm wrong? Else if, regrettably, we all now see what I see here, then let's extend the standard. Let's give the Ide device a way to report accurately the (N * 2 - D) residue that only it can observe. (By D, I mean S if the device is the sender of clocks, else I mean R.) > Please tell me that and how I'm wrong? Thanks in advance. Pat LaVarre P.S. > If the bridge knows, ... > how many bytes it wants (say R), I think I do see a"subtle issue of interpretation" hre. Should the Usb host tell the bridge to try to move the expected number of bytes or instead the max number of bytes that any device might move in response to a command? In Usb1, when using the generic UsbMass protocol designed to accomodate Wintel bugs involved in cutting expected transfers short, choosing the latter option perceptibly slows down normal transfers, whoops. Subscribe/Unsubscribe instructions can be found at www.t13.org.
