On Mon, 28 Oct 2013, Chris McClelland wrote: > > 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.
Operating on the other port must have been significantly slower than a direct connection. Otherwise you wouldn't have mentioned the reduced throughput. > 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. Okay. Good luck! Alan Stern ------------------------------------------------------------------------------ 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
