> It seems clear from the traces that this isn't a problem in libusb.
Agreed. But (a) I needed someone to sanity-check my approach using the
async API, and (b) I knew that you look at this list, and I hoped you might
have some suggestions. And you did!
OK so I tried a few things:
1) Rather than read the SDRAM, have the FPGA just send back 16MiB of zeros.
With this, I could NOT get it to fail. From the USB perspective, the only
difference is the produce-rate of IN packets: without the SDRAM reads, the
FPGA can produce data at about twice as fast, fast enough to saturate an
otherwise-idle bus. Why that should make a difference I don't know.
2) Try exactly the same host code and firmware, but a completely different
PCB, also with a 16MiB SDRAM. With this, the failure happens much earlier -
whilst the FPGA is being programmed in fact.
3) Try different cables. No change.
4) Try a different port on the hub. Surprisingly, this fixed it, albeit at
a reduced throughput.
> Have you noticed any difference in the time it takes the program to run
> with the hub present compared to a direct connection? If it takes
> longer with the hub, that's a good indication you're getting a lot of
> failures and retries.
Not significantly slower. Here are some timings (from gettimeofday()) for
the direct connection, in microseconds per 64KiB chunk, firstly eight runs
of reading back 1GiB of zeros, and secondly four runs of reading back 16MiB
from SDRAM:
Direct connection (uS/64KiB), readback zeros (doesn't fail):
0 1 2 3 4 5 6 7
max: 12369 20450 17668 14060 20200 20706 13874 16654
min: 924 893 956 919 917 918 938 940
avg: 1818 1829 1833 1827 1830 1828 1830 1833
Direct connection (uS/64KiB), readback from SDRAM (doesn't fail):
0 1 2 3
max: 20393 10668 12718 16280
min: 880 894 869 874
avg: 2942 2853 2888 2871
And here are the same timings for the connection via the hub (using the
original port, so the four SDRAM readback tests failed to read the last
chunk, but the eight read-zeros succeeds):
Connection via hub (uS/64KiB), readback zeros (doesn't fail):
0 1 2 3 4 5 6 7
max: 13997 15339 13518 19416 17600 19487 15494 13272
min: 908 896 913 943 916 906 933 924
avg: 1949 1960 1962 1961 1960 1958 1962 1968
Connection via hub (uS/64KiB), readback from SDRAM (DOES fail):
0 1 2 3
max: 10227 12610 18895 11823
min: 950 910 1006 897
avg: 3009 3099 3007 3050
> Maybe it's not the hub itself but one of the USB cables or connections.
> Have you tried using a different brand of hub? Maybe a powered hub?
I tried several different cables, which made no difference, and a different
port on the hub, which DID make a difference (no more hangs, but the
throughput is reduced to about 10MiB/s compared to about 17MiB/s with the
original port). The hub itself is powered.
To be honest I'm beginning to think my hub is just not very good, or
perhaps not very compliant. It works fine on x64 Linux and Windows, but has
what appear to be timing-dependent intermittent issues with the RPi. Also,
the RPi itself has in the past had almost unusable USB support, which has
improved enormously with successive Raspbian releases. I'll buy a couple of
other hubs and see if they're any better, but as to my original fear that
this is some systemic problem with my code that will affect other platforms
in time: I suspect those fears are unfounded.
Chris
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
