On Fri, 17 Feb 2006, Mukund JB. wrote: > Dear Alan, > > >> After that see the Table 5-1. Low-speed Control Transfer Limits. > >> Even though there are a total of 43 bytes to be transferred, I > observe > >> that data payload is less that 8 bytes some times which is against > the > >> above rule in 5.5.3. > > > >Where do you get that 43 from? > I got it through (Max transfers + Bytes remaining). > I guess Max > > The table has 4 rows. The first row > >illustrates what happens when 1 byte is to be transferred. The second > row > >illustrates what happens when 2 bytes are to be transferred. The third > >row illustrates what happens when 4 bytes are to be transferred. And > the > >fourth row illustrates what happens when 8 bytes are to be transferred. > > Thanks for the explanation. > But, I did not get how MAX Transfers vary? > And what does "bytes remaining" mean?
In Table 5-1, here's what the various columns mean. Max Bandwidth is the number of data bytes that can be transferred in one second using the specified payload size. For instance, if the payload size is 1 byte (first row) then you can transfer a maximum of 3000 data bytes per second. The Frame Bandwidth per Transfer is the percentage of the available bandwidth used by transfers with the specified payload size. For instance, if the payload size is 2 bytes (second row) then a single transfer will use 27% of the bandwidth of a frame. The Max Transfers is the maximum number of transfers per frame with the specified payload size. For instance, if the payload size is 4 bytes (third row) then there can be up to 3 transfers per frame. The Bytes Remaining is the number of bytes that could be sent in the remainder of the frame after the maximum number of transfers with the specified payload have been sent. For instance, if the payload size is 8 bytes (fourth row) then after sending 3 transfers in a frame there would still be time to transmit another 19 bytes. The Bytes/Frame Useful Data is the maximum number of payload bytes that can be sent in a frame using transfers of the specified size. For instance, if the payload size is 1 byte (first row) then at most 3 bytes of useful data can be sent in a frame (1 byte per transfer times 3 transfers). By the way, note that the Protocol Overhead values listed at the top of the table are wrong. The actual overhead used in the table is 48 bytes, not 63. I don't know why the table says there are 15 SYNC and 15 PID bytes; there should be 9 of each as in table 5-2. And apparently the interpacket delay is taken to be 10 bytes, not 13 (although it probably should be 7 or 8). Anyway, you can easily confirm the values for yourself. All you need to know is that the total number of bytes in a frame is 187 (bottom right corner) and the overhead is 48 bytes per transfer. So for example, if your data payload is 4 bytes then you get a total of 52 bytes per transfer (48 + 4). 52/187 = 27.8%, and only three 52-byte transfers can fit in a 187-byte frame. There will be 187 - 52*3 = 31 bytes remaining, and the number of data bytes transferred will be 3*4 = 12. Since there are 1000 frames per second, the maximum number of data bytes per second is 12000. > And I find two ways of addressing like transfers and transactions. I > understand them as follows. Please correct me in case I am wrong. > I guess 1 transfer will involve multiple transactions. Generally it will > be 3 i.e. setup, data and handshake. If the data to be transferred is > more the transaction count will increase. > > I guess, > 1 transfer = (1 setup transaction + 1 or more data transaction + > 1 handshake transaction) The three stages are called Setup, Data, and Status. The Setup stage consists of a single SETUP transaction, the Data stage consists of zero or more IN or OUT transactions (there will be no transactions if the data length is 0), and the Status stage consists of a single OUT or IN transaction. This is all discussed in Section 8.5.3 of the USB 2.0 spec. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
