I'd say you most likely have a flaw in your code, because what you describe is only around 1.6 MiB/s.
I'd also like to point out that you will rarely, if ever see any USB interface that will achieve a full 450Mbit/s. For example, the g_ether network gadget driver at best usually only achieves 105-115Mbit/s, but that partly due to the code written. On Wed, Mar 22, 2017 at 7:13 AM, Dennis Lee Bieber <[email protected]> wrote: > On Tue, 21 Mar 2017 22:08:17 -0700 (PDT), ags > <[email protected]> declaimed the > following: > > >I need to provide about 32 KiB to the PRU within 5 milliSec, repeating > >every 20 milliSec. This seems like it should be easily accomplished, if a > >USB driver can sustain 480 Mbps data rates. I must be approaching this the > >wrong way. Any suggestions on how this should be architected will be > >greatly appreciated. > > If you've got a USB system that actually manages 480Mbps for more > than > a few bytes, you've got something miraculous. > > USB is a polling intensive protocol, with lots of turn-arounds > (host: > Are you ready to receive?, client: ready, host: data packet send) > > High Speed USB has a data payload size of 1kB plus a few bytes for > sync/PID/CRC16... Or about 8k bits per transaction. Sure, the 8k bits goes > out at 480Mbps... And then gets followed by polls of connected devices to > find out which is the next device to be serviced. > > The effective rate for high-speed USB is only around 280Mbps (USB 3 > Superspeed is rated 5Gbps, but the spec is considered met with an effective > rate of 3.2Gbps -- USB 3 is full-duplex signalling, the others are > half-duplex) > > I've not encountered any protocol that requires something like > 32kB as > a continuous stream with no subdivisions for handshake/error-checking. > Ethernet breaks data up into (with overhead) ~1.5kB chunks; TCP may be able > to send multiple chunks before getting an ACK back on the first chunk, but > it is still chunked... > > -- > Wulfraed Dennis Lee Bieber AF6VN > [email protected] HTTP://wlfraed.home.netcom.com/ > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/beagleboard/eg05dc5tkbdb1ae3up4aoi92h9er1lq1sn%404ax.com. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORqB39srDKhYGHhK6s%2B02YTEKa9oXM4UqydaCTKZJ_1hgQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
