GORAN RADIVOJEVIC wrote: > Sorry, my error: buffer size is 4096, packet size is 256. If I'm > correctly calculating: 125uS*12packets*256byte will give me 1.5MB/s transfer > rate > (3072bytes in 2mS period).
The number of packets per request is not part of the bandwidth computation. If you need 1.5MB/s, then you need at least 188 bytes in every microframe. So, 256 would be appropriate. > Host received 16 buffers: 12 are full 4 empty. Everything works fine in > device to host direction. So, your endpoint has a packet size of 256, and an interval of 1, and you're submitting a request with 16 packets. Is that right? > >Seriously, isochronous is much less convenient that interrupt. > > This is where things getting complicated. Interrupt or Bulk transfers > scheduling > are not time guarantied and 1mS period between two packets is sometime bigger > resulting > in very bad synchronization (verified with oscilloscope). No, you are wrong. What you say is correct for bulk pipes, but the packet timing for interrupt and isochronous pipes is IDENTICAL. The scheduling is guaranteed, using exactly the same mechanism. If you have an interrupt pipe with 256-byte packets and an interval of 1, you will see EXACTLY the same results as if you had an isochronous pipe with 256-byte packets and an interval of 1. However, I want to make sure you understand that the placement of requests within a microframe is never guaranteed, for ANY kind of packet. In light traffic situations, you'll find that your transfers occur at roughly the same spot in each microframe, but when traffic gets heavy, they won't. You shouldn't design hardware that needs that level of guarantee. If the timing variability a problem, just use a 384-byte packet instead of a 256-byte packet. That way, if your buffer happened to accumulate some extra bytes, you'll have a way to get caught up. > With ISO packet sync is > almost perfect but I did not figured out yet how to correctly fill/send > buffers. With reduced > bandwidth and Bulk transfer results are good but what will happen if other > USB devices > request bandwidth allocation? That's the gamble. Bulk pipes usually get better bandwidth and better latency, but you're competing with other devices. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
