On Thu, 26 Jul 2012, Alexey Filin wrote: > transfer with 2kB per URB hits artificial limit in our read out module > (19 MB/s for 128 kB URB). I think difference in performance for > pipeline of concurrent URBs and one iterative URB with 128 kB buffer > will be negligible, 128 kB URB takes at least 20 microframes (table > 5-10: max 13 transfers of 512 payload packets per microframe): > > 128k / (13 * 512 bytes/packet) ~ 20 microframes > > so underuse of one microframe of 20 is a very small cost of simple driver. > Moreover we read each set of 4 crates with one USB controller and (I > think) hit its aggregate performance 47 MB/s (table 5-10 declares > theoretical maximum 51 MB/s for bulk transfers). You would exactly fill out 20 microframes if the URB length was 130 KB. Regardless, I agree -- an overhead smaller than one part in 20 is negligible. > > No, it's not a deception. It's simply a mistake in your driver. > > It is not a mistake, it is an intention to guarantee data consistency. > I'm not sure all USB controllers (and USB subsystem) submit URB/call > completion handler for some URBs for one pipe always sequentially. I > worry about data consistency, data are very expensive for us. Can you > guarantee that? Yes, it is guaranteed that every endpoint queue is handled in order. That is, completion handlers are always called in the same order as URB submissions, except if the driver deliberately unlinks an URB. On the other hand, there is no guarantee of coherence for submissions/completions of URBs going to different endpoints... > > On the whole, USB might not be a good way to achieve what you want. > > thanks for advice. It seems to be enough complex. It requires hacked > USB controller driver (and USB subsystem?) and dedicated USB > controller for specialized transfers only to simplify URB handling, is > it? May be even sell my soul to the devil... Yeah. Would gigabit Ethernet work out better? I don't know. 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