FX3 Isochronous bandwith issue in Linux

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Using cyfxisosrc example, on Windows I can easily get large bandwith above 100 MB/s but in Linux, no matter what I do, I am stuck at 8MB/s. I however use a recent version of Ubuntu which is supposed to have full support for USB3.

   

It seems the computer completely ignores the desciptor that changes settings such as CY_FX_ISO_BURST and CY_FX_ISO_PKTS, as altering those values has absolutely no effect on the bandwith, which is always 8MB/s.

   

I even tried to remove support for other speeds than Super Speed, but this had no effect.

   

Also, the doccumentation http://www.cypress.com/?docID=48135 is wrong, as there is nowhere a parameter CY_FX_ISOSRCSINK_DMA_ BUF_SIZE in the source code.

   

Help please.

0 Likes
5 Replies
Anonymous
Not applicable

 Hi Are you using the example project in the latest SDK 1.3.3 or the project along with the Application Note Document? Please let us know.

   

If you are using the IsoSrcSInk example along with the Application Note, please note that, in the AppNote the macro "CY_FX_ISOSRCSINK_DMA_ BUF_SIZE" appears with a line break as "CY_FX_ISOSRCSINK_DMA_  BUF_SIZE"

   

(Please note the "blank space" between DMA and _BUF. In your question, you have also posted with the blank. Please remove this blank and search for the term in the project. You will find it)

   

Regarding the throughput, can you please try the IsosrcSink project in the SDK 1.3.3 and see if it is also giving the same result. (These two similar example projects i.e one in SDK and one with AppNote have minor differences). In the SDK project, you can change the DMA Buffer size directly by changing dmaCfg.size in the cyfxisosrcsink.c file. 

   

Regards,

   

- Madhu Sudhan

0 Likes
Anonymous
Not applicable

 Hello Mady, thank you very much for your anwer.

   

 

   

I am talking about 'cyfxisosrc' and 'cyfxisosrcsink' from the "basic_examples" included in the SDK 1.3.3. This should be the latest version, it appears to date from the 6 december 2013.

   

 

   

There is no macro such as CY_FX_ISOSRCSINK_DMA_BUF_COUNT (witout space), there is just CY_FX_ISOSRCSINK_DMA_TX_SIZE and CY_FX_ISOSRCSINK_DMA_BUF_COUNT. The cyfxisosrcsink.h file is very small so it's not like it is possible to miss it, it is not here (and is not here in cyfxisosrc.h either).

   


The dmaCfg.size is assigned to different values depending on CyU3PUsbGetSpeed(). I removed the switch to ensure that SuperSpeed is always used, so the DMA BUFFER size should be always 1024 (equal to the block size). This however does not fix the problem : I still get a very consistant 8 Mb/s

   

To determine the speed in linux I trust the GUI (when it does not print "inf", which it does sometimes).

   

 

   

I forgot to mention that the speed of 'cyfxisosrc' is (much) higher in Windows than in Linux even when rebooting the PC while keeping the firmware on the FX3 intact. It does not matter if I compile or download the firmware with Windows or Linux.

   

 

   

Strangely, the speed is of 'cyfxisosrcsink' is exactly 8 Mb/s in both Windows and Linux, while the speed of 'cyfxisosrc' is 8 Mb/s in linux and arround 180 Mb/s in Windows. (For 'cyfxisosrc' I use alternate setting 2 for 'cyfxisosrc', because it is supposed to be the fastest, but the results are the same with alternate setting 1, exept it is slower in Windows).

   

 

   

I had this problem with two different FX3s and two different PCs, so this is not a problem caused by faulty hardware.

   

Thank for your help.

   

 

   

PS : At the bottom of page 12 of the doccumentation "cyusb_linux_user_guide.pdf", we can see that whoever took the screenshot got even lower rates than me, as he got ~5 MB/s for 'cyfxisosrcsink'.

0 Likes
Anonymous
Not applicable

I'm experiencing this same problem under Mac OS X, using firmware derived from cyfxisosrc. Has anyone found where the problem is?

0 Likes
Anonymous
Not applicable

Hi,

   

I am experiencing the same problem here. Is there a solution to this yet? I am using Ubuntu 16.04 as host and the "cyfxisosrcsink" firmware. I used a libusb based program. It turns out that the bandwidth for ISO endpoint is limited at around 8M/s.

   

Best

0 Likes
Anonymous
Not applicable

Hi,

   

 

   

This problem is solved.

   

As the cyusb_linux program uses the libusb to perform usb transfers, I reviewed the code and found the following snippet:

   

 

   

cyusb_linux_1.0.5/gui_src/streamer.cpp, line 298 to line 305:

   


298            case LIBUSB_TRANSFER_TYPE_ISOCHRONOUS:
299                libusb_fill_iso_transfer (transfers, dev_handle, endpoint, databuffers,
300                        reqsize * pktsize, reqsize, xfer_callback, NULL, 5000);
301                libusb_set_iso_packet_lengths (transfers, pktsize);
302                rStatus = libusb_submit_transfer (transfers);
303                if (rStatus == 0)
304                    rqts_in_flight++;
305                break;
 

   

 

   

the packet length is set to pktsize, which, in their program, is the maximum size of each packets. This is right if there is only one packet per time interval. However, for USB-3.0, if there are, e.g. 16 burst packets per transfer, and 2 transfers per service interval, this setting is not right. This may due to a fuzzy definition of the libusb or its implementation.

   

So the solution is, set the iso packet lenths to the maximum data size that would be transferred in a service interval. i.e., 

   

packet_size * (burst_num + 1) * (mult_num + 1).

   

This way, in the buffer of the iso transfer, you will find the data sent in one service interval being treated as one packet. 

   

So using a program written in libusb-1.0 on linux, the speed of the transfer reached around 250 MBytes/Second on my side.

   

 

   

I believe you have already solved this problem (since this thread was posted in 2015). But just post my solution here and hope this will help someone with the same issue. 🙂

   

 

   

Thank you!

0 Likes