Throughput of the DES application using Python

Spartan-6 USB 3.0 Modules
1

I have been experimenting with the Python version of the DES example on a mac book pro retina which has been previouly reported to achieve 300Mbytes/sec plus using pipes. I made the buffer size adjustable in the DES python code and added some crude timing using time.time(). I used a input file of about 24Mbyte.
My results for a buffer size of 8Mbytes achieve a transfer rate over USB3 of approximately 40Mbytes/sec. (The figure reported at the end of the printout below is half this but thats for a round trip back and forth.)The program attached gives these results for this case:

/System/Library/Frameworks/Python.framework/Versions/2.7/bin/python “/Users/kearneda/opal Kelly/PythonDev/First/first.py” e 1234567812345678 in out
------ DES Encrypt/Decrypt Tester in.old Python ------
FPGA card found
Product: XEM6310-LX150
Firmware version: 1.8
Serial Number: 13250005ZO
Device ID: Opal Kelly XEM6310
FPGA configured with destop.bit
FrontPanel support is available.
Encrypting in ----> out
Time to read file 0.00845003128052
Time to send buffer 0.198985099792
Time to do DES 0.000642061233521
Time to receive buffer 0.190074920654
Time to write file 0.0119378566742
Total time ============= 0.410089969635
Time to read file 0.00647282600403
Time to send buffer 0.198259115219
Time to do DES 0.000720024108887
Time to receive buffer 0.185111045837
Time to write file 0.0174989700317
Total time ============= 0.408061981201
Time to read file 0.00751113891602
Time to send buffer 0.198559999466
Time to do DES 0.000497817993164
Time to receive buffer 0.191733121872
Time to write file 0.0168800354004
Total time ============= 0.415182113647
speed achieved = 20.3604388131 MBytes/s with a file of size 25.165824 MByte

Process finished with exit code 0

My question is: How come the transfer speed maxes out suspiciously close to the USB2 limit when we are using such large buffer sizes where the Python interpreter overheads should be minimal. Should not this size buffer of 8Mbyte allow the system to start approaching the 300Mbyte limit reported by the C++ implementation.

BTW I have yet to try the C examples because I have compiler configuartion problems on mac os x 10.8 with mac book pro retina.

first.py.zip (1942 Bytes)

2

DESTester is not a good example for doing bandwidth tests. The transfers are too small.

Please see the PipeTest or the okCameraApp in the EVB100X-DEV eval board for a better example of high-bandwidth transfers.

3

— Begin quote from ____

The transfers are too small.

— End quote

Can you clarify just which transfer needs to be increased. Obviously its not the buf size used in the Python API. I noticed that the C api has an additional parameter for pipe writes that specifies a length. Is this length fixed in the Python API and if so what is its size. There also seem to be lower level transfer sizes mentioned as well in the docs. Could we have a strait forward explanation of each of these and what values should be chosen to achieve high rates with USB3.

4

Please see the FrontPanel User’s Manual in the section “Performance Notes”. There is a fairly thorough discussion there. The USB 3.0 results aren’t listed there, but they scale similarly. You can use the PipeTest sample to benchmark your system:

pipetest.exe pipetest.bit bench