On Wed, 15 Jul 2009, cihan öztürk wrote: > Thank you very much for being interested Mr Stern. > Here are answers to your questions: > > What type are your transfers (bulk, interrupt, control)? > If they are interrupt, what is the period? > > We are using bulk transfers. > > What are the maxpacket values? What are the actual packet > sizes (you said some of them are 33 bytes)? > > 33 bytes is the max size of a packet according to our communication > protocol, has nothing to do with USB. Our USB driver buffers incoming > max-33-byte requests until a flush signal is received (which is > signalled every 2ms according to our design). Therefore, I guess, > USB HC splits the buffered data into transactions with 64byte payload, > adds necessary USB wrappers,and sends consecutive transactions to > target device controller within the same frame (since it's bulk mode). > The target firmware is designed such that it accepts a max of 512 byte > data as input, and sends a max of 1024 byte data stream as > output within a frame. > > How many packets do you send in each frame? How many packets > do you receive in each frame? > > The main loop of application sends a max of 15 write requests (each > write req includes 33 byte of data to write to device buffer in the > current frame, & 3 bytes of ACK response will be received in the > next frame) and 15 read requests (each read req includes 3 bytes > of data in current frame > that commands device to respond with 33 byte data in next frame). > For instance, the application sends a total of 15*(33+3) bytes in one > frame, receives 15*(33+3) bytes in next frame, and so on. Therefore, > the number of packets is kept at 30(15*2). It is important to > note that since we use a timer that flushes the buffer every 2ms, > above numbers are just an estimation. There may be less than > 30*2 packets of data when a flush signal is received, or more. > When there is constantly more packets than a certain upper bound, > this causes an accumulation at the appropriate linked list of > application library. What we are trying to find is this upper bound > in terms of Mbps. Let's say your application submits A write requests and B read requests during a frame. Then your library will want to send 33*A + 3*B bytes in that frame. These will get merged into USB packets, and your firmware will accept no more than 512 bytes per frame. Hence if 33*A + 3*B > 512, you will build up a backlog. Also, since your firmware won't send more than 1024 bytes per frame, if 3*A + 33*B > 1024 then you will lose data. Depending on the balance between A and B, you can figure out the maximum transfers rate in Mb/s. For example, if B is 0 then the limiting value for A is floor(512 / 33) = 15. If A = B then the limiting value is floor(512 / (33 + 3)) = 14. If A = 15 and B = 0 then the total amount of data transferred per frame is 15 * (33 + 3) = 540 bytes. Thus the upper limit to the throughput is 540 * 8 * 1000 = 4.32 Mb/s for each device. If A = B = 14 then the total amount of data transferred per frame is 2 * 14 * (33 + 3) = 1008 bytes. This yields an upper limit to the throughput of 8.064 Mb/s for each device. > Is your external hub full speed (USB 1.1) or high speed (USB > 2.0)? > > It's a Digitus 7 port High speed hub(both 1.1 and 2.0 compatible). This explains why you are able to achieve throughputs higher than 20 Mb/s when using multiple devices. Most likely each port on that hub has its own Transaction Translator, and consequently each port is able to sustain 12 Mb/s independent of the other ports. Similarly, if you have two separate root hubs on your PC, then each can sustain 12 Mb/s independent of the other. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
