same fw 

win7 8MB/S

XP  15M/S

so why?

Hi,

What API are you using to make these transfers? Xferdata or Begindataxfer / waitforxfer / finishdataxfer??

Regards,

Anand

I have the same problem.

We have developped a USB camera using the CY7C68013 and we transfert the data in Bukl mode using Xferdata interface and the speed on Win XP is almost  twice the speed on Windows Vista/7.

And it seems we can't do much about it with the Cypress Driver.

Any ideas ?

Christian Bouvier, PhD

Research engineer

New Imaging Technologies

A World Class Supplier of CMOS Sensors

www.new-imaging-technologies.com

1-4 impasse de la noisette, Bat D, 1er Etage, 91370 Verrières le buisson, France

Use the streamer/screamer example that comes as part of SuiteUSB as reference and modify the code to use begindataxfer/waitforxfer/finishdataxfer.... That should provide an improvement.

Regards,

Anand

Already tried that, unfortunately that does not improve much the transfert speed.

The problem is that we can achieve 27 MB/s speed with Win Xp and only 9 MB/s on Win 7 with the same code running on the device and on the host. We want to send 768x576 images with pixel depth of 16 bits at 30 FPS which works great on Win Xp and the limit is at only 10 FPS with Win 7 which is very annoying.

One other thing you might want to try is,

The variable XferSize determines the size of buffer allocated on the host controller driver. By default it is set to 8*endpoint size. You might want to set it to 64k and see how the performance varies.

Regards,

Anand

It doesn't change anything, the buffer already has been set to the size of a image.

After further analysis, the problem seems to be related to the USB bandwith management with windows Vista/7.

When we are using Win Vusta/7, the latency is higher than with Win XP during packet transfert and at some point, the transfert is not fast enough and we have a buffer overload on the FIFO side on the device which is already a Quad buffer.  Any ideas why the bandwith seems to be reduced with Vista/7.

After another test, we have found that when the FIFO is set to Byte length without modifying anything else, we are able to go up to 45 FPS with win Vista/7 with now 768x576 image with pixel depth of 8 bits. Ideas ?

Vs 768x576 image with pixel depth of 16 bits at only 10 FPS  when FIFO are set to WORD length

No ideas from the people of Cypress on this speed limitation on Win Vista/7 ?

There is no general speed limit in Windows Vista or 7 with the FX2. We can read with up to 40.5 MByte/s under Windows 7 using slave fifo interface, 16 bit wide with 40 MHz external IFCLK. This is even a little faster then under XP with the same software. Furthermore the WinUSB driver is also a little faster then CyUSB driver. To reach such transfer rates you have to transfer large blocks for filling up the microframes and use BULK transfer with large hardware buffers.

Yes, the only thing that seems to have an effect on mean number of transfered bytes is the Packet. But even with a Endpoint with a size of 1024 Bytes and PacketSize of 1024 Bytes I can't get a stable video stream higher than 12 or 13 FPS after that, images that are requested can't seem to be transfered entirely.
 

Even If the global transfer speed has increase accordingly, there are always missing bytes when an image is requested.

Souldn't an 1024 bytes endpoint quad-buffered be enough for that kind of transfer because everything works just fine with Win XP.

I'll try the WinUSB driver.

1024 Byte BULK Endoint caused strange problems an slow data transfres in our tests. We are using 512 Byte EP for BULK. Did you try this also?

512 bytes is the allowed maximum endpoint size for bulk endpoint as per USB specification. Please do not use 1024 bytes, I've seen quite a machines give BSOD when this was done.

Regards,

Anand

We tried 1024 and 512 and both setting seem to work, only it does not make much diffrence with win 7. We still can't reach the the stable 30 FPS we need and that we have on XP with Win 7. We are now investigating the FIFO management.

Hi bicool,

Do you process the data at your host app end i.e. remove the video class based overhead on the host side?

Do you have a CATC trace of the WinXP and Win7 traffic? Can you please details of the host controller being used.

The fact that you're seeing this with screamer/streamer as well is the confusing part since we run performance tests on these apps before releasing them onto our site.

Regards,

Anand

Dear Anand,

The thing is I have different behaviour when FIFO are set in  Wordwide or simply in Byte. When I set the FIFO with Wordwide size, I encounter the erratic behaviour I described on Win7. But when I set the FIFO to Byte size I can go up to almsot 60 FPS. Both settings works on XP.

The thing is I have a 14 bits ADC in order to sample my pixels so I must use the FIFO with Wordwide size.

And I have the same issues with the Streamer/Screamer example.

Christian

In fact, the problem with 7 is not really the instantaneous transfert speed but the stability which prevent me from having a stable video stream on the host side from a certain frame rate and it looks periodic on the host. Here is whate I see, I receive a batch of complete frames and then a batch of incomplete frames, and I see that the number of complete and incomplete frames is pretty stable in time when I compute stats on a queue using a modified version of the Streamer.

From 14 - 15 FPS I start to receive incomplete frames.

Wordwide and bytewide change causing issues sounds strange since it has to do with the slaveFIFO/GPIF interface and shouldn't affect the stability.

Do you have a way of looking at what is happening at the bus level (CATC trace)?

When you say incomplete frame can you elaborate what you mean? Can dropped packets cause it?

Regards,

Anand

IncompIete frame means I receive fewer bytes than I requested on the host side.

Wordwide and bytewide change causing issues sounds strange since it has to do with the slaveFIFO/GPIF interface and shouldn't affect the stability.

Well i don't understand either but it's happening.  As I said, I don't have issues on XP with Wordwide and BytewiDe. But On 7 I can't have a stable frame rate above 14-5 FPS with Wordwide but I can go up to 60 FPS in Bytewide. Regarding the host controller, I test the USB camera on a machine with double boot XP/7. On XP, everything works as it should but on 7 it is impossible to have a sable video stream above 13 - 14 FPS with Wordwide FIFO.

Here is my understanding of your setup

You use bulk endpoint configured with wMaxpacketsize of 512 bytes.

Receiving lesser number of bytes than requested happens if the device sends a short packet or Zero length packet in the middle of the TRANSFER (the number of bytes requested from the host).

Is the number of packets you are requesting a multiple of 512?

When you say lesser number of bytes than requested, is the number of bytes received a multiple of 512?

Regards,

Anand

The sensor resolution is 768*576 with pixel depth of 14 bits which means that the pixels are sent with 16 bits depth. For a frame I request 768x576x2 bytes = 884736 bytes = 1728 x 512 bytes.

When you say lesser number of bytes than requested is received, is the number of bytes received a multiple of 512?

What are the values you are seeing for the number of bytes received?

When I pass the threshold above which the video stream is not stable anymore (around 14 FPS), the mean number of missing bytes is around 139 bytes computed on a queue of 32 frame but the number is not constant it can goes up to more than 350 missing bytes.

Hi bicool,

I didn't quite understand what you mean when you say "the mean number of missing bytes is around 139 bytes computed on a queue of 32 frame but the number is not constant it can goes up to more than 350 missing bytes" please elaborate.

Are you seeing missing bytes in the middle of packets? Are you implementing flow control (i.e. check if a buffer is in free in FX2LP before sending packet to it from the SlaveFIFO/GPIF side)?

Say you trigger a 884736 byte transfer, are you always receiving 884736 bytes in response to the transfer? or are you receiving lesser number of bytes and the transfer terminates?

if the transfer is terminating with lesser number of bytes please let me know a few values of the "number of bytes" received in these cases.

Please do not skip the questions. I'm not able to get the full picture of your system and the possible cause behind the issue.

Regards,

Anand

Hi bicool,

I didn't quite understand what you mean when you say "the mean number of missing bytes is around 139 bytes computed on a queue of 32 frame but the number is not constant it can goes up to more than 350 missing bytes" please elaborate.

-> What I mean is : I set up Queue on the host, the same way that it is done in the streamer/screamer example. The buffer on the host is set to 768*576*2 bytes using SetXfersize(). The Queue length is 32 frames. The transfert are initiate with  768*576*2 bytes requested using BeginDataXfer(). Then I enter the infinite loop the same way it is done in the Streamer/Screamer. I record each time the number of bytes effectively transfered to the host before recommitting the Queue element with BeginDataXfer() after finishing it. What I see is that, above a certain Frame Rate that I set manually, there are queue elements for which the amount of bytes received is lower than the 768*576*2 requested and I save the difference between the number of bytes I requested and the number I received. I called that number "number of missing bytes". But this difference is not constant and is not necessarily a multiple of 512. For example, on some queue elements I saw a difference of 1304 bytes. I gave a temporal mean number computed on the 32 elements of the queue in the last message.

Are you seeing missing bytes in the middle of packets? Are you implementing flow control (i.e. check if a buffer is in free in FX2LP before sending packet to it from the SlaveFIFO/GPIF side)?

->No, we use a simple configuration and those issues have never occured during the developpment stage performed under XP. I am not even sure how to do that kind of flow control between the Slave FIFO and FX2LP.

Say you trigger a 884736 byte transfer, are you always receiving 884736 bytes in response to the transfer?

-> Not always, above a certain a Frame rate, fewer bytes are received by the host.

if the transfer is terminating with lesser number of bytes please let me know a few values of the "number of bytes" received in these cases.

-> For example, on some queue elements I saw a difference of 1304 bytes between the 884736 requested and what the host received (ie : 884736 - 1304 = 883432)

Say you trigger a 884736 byte transfer, are you always receiving 884736 bytes in response to the transfer?

-> Not always, above a certain a Frame rate, for some frame fewer bytes are received by the host.

Hi bicool,

This means that your device is sending short packets i.e. a packet less than 512 bytes. When this happens it will end the transfer. This is why you're seeing less than 884736 bytes being reported in transfers.

The fact that you're seeing this screamer/streamer suggests that there is a issue with your hardware interface (slaveFIFO/GPIF) or your firmware (Win7 sends tokens faster than WinXP from what I've seen).

Can you please create a tech support case (MyAccount -> MyCases) with the details that we've deduced so far so that the issue can be analysed deeper.

Regards,

Anand

dear bicool and Anand,

i think i have solved the problem, it seems that SetXferSize(len) is the main cause. FOR XP if i set len = VGASIZE(640*480*2) it can reach 30fps, but for win7 i find it must be set a smaller size(640*480) .and set time=2 to finish one frame transfer.So try to set a small size and to multi-transfer .this is my code for reference:

LONG len=256000; 

int time = 2;

for(i=0;i<time;i++)inContext[i] = USBDevice->BulkInEndPt->BeginDataXfer(pOut+i*len, len, &inOvLap[i]); 

  for(i=0;i<time;i++)
  {
   if(!USBDevice->BulkInEndPt->WaitForXfer(&inOvLap[i],5000)) 

   USBDevice->BulkInEndPt->Abort();
  }
  for(i=0;i<time;i++) 
   bRequest=USBDevice->BulkInEndPt->FinishDataXfer(pOut+i*len, len, &inOvLap[i],inContext[i]);

  for(i=0;i<time;i++)CloseHandle(inOvLap[i].hEvent);

Best Request

there is someting wrong with posting code .

but the key is  setXfersize tosolve the problem

zyjustice,

What is the issue you are seeing in posting code?

Regards,

Anand