Lost isochronous packets

NTDEV
1

Hi everybody,
I’ve a question about usb high speed isochronous transfer.
I’m using a Cypress FX2LP to send data from a CCD over USB.

Cypress firmware is configured to send 3 packets/uFrame (3072 packets/microframe) and CCD fills a single FIFO in 34 us (and I have 4 FIFOs, each of 1024 kb).

The problem is that FIFOs are getting full and some data is getting lost. But if FX2 sent 3072 kb every microframe, , FIFOs would never get full!

So my question is: is it sure that host issues an IN token every 125us? I’m using Windows XP SP2 and I’ve tried several number of packets/urb (from 8 to 256).

Thanks in advance,
Giorgio Gallina

2

Do you see that behavior on Vista SP2?

S.

3

xxxxx@gmail.com wrote:

I’ve a question about usb high speed isochronous transfer.
I’m using a Cypress FX2LP to send data from a CCD over USB.

Cypress firmware is configured to send 3 packets/uFrame (3072 packets/microframe) and CCD fills a single FIFO in 34 us (and I have 4 FIFOs, each of 1024 kb).

Are you sure about your numbers? If you are getting 1024 bytes every
34us, that’s faster than an isochronous pipe. That’s 30MB/sec, but an
isochronous pipe is limited to 24MB/sec.

The problem is that FIFOs are getting full and some data is getting lost. But if FX2 sent 3072 kb every microframe, FIFOs would never get full!

So my question is: is it sure that host issues an IN token every 125us? I’m using Windows XP SP2 and I’ve tried several number of packets/urb (from 8 to 256).

As long as you make sure there is always a read request ready and
waiting, you will get a shot in every microframe. That means you must
submit more than one URB. If you ever let the queue run dry, so that
there is no request waiting, then you will miss that frame.

Also note that there is no guarantee on the timing of the transfers.
You will have three 1024-byte transfers per microframe, but there’s no
promise how they will be spaced out. You might get three transfers
neatly spaced 40us apart, but you might get three right in a row,
followed by a 100us gap before the next one. And if your device does
not have enough data to fill the first transfer, the other two are
canceled. You will have to wait until the next microframe.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

4

On Tue, Oct 12, 2010 at 7:18 PM, Tim Roberts wrote:
> ?xxxxx@gmail.com wrote:
>> I’ve a question about usb high speed isochronous transfer.
>> I’m using a Cypress FX2LP to send data from a CCD over USB.
>>
>> Cypress firmware is configured to send 3 packets/uFrame (3072 packets/microframe) and CCD fills a single FIFO in 34 us (and I have 4 FIFOs, each of 1024 kb).
>
> Are you sure about your numbers? ?If you are getting 1024 bytes every
> 34us, that’s faster than an isochronous pipe. ?That’s 30MB/sec, but an
> isochronous pipe is limited to 24MB/sec.

Yes, I’m sure! But I’ve 4 x 1kb FIFOs and packets of 2500 byte to
transfer spaced by 33us. So, actually, I’m filling my FIFOs with 2500
byte in 118us (so 21 MB/sec).

>> The problem is that FIFOs are getting full and some data is getting lost. But if ?FX2 sent 3072 kb every microframe, FIFOs would never get full!
>>
>> So my question is: is it sure that host issues an IN token every 125us? I’m using Windows XP SP2 and I’ve tried several number of packets/urb (from 8 to 256).
>
> As long as you make sure there is always a read request ready and
> waiting, you will get a shot in every microframe. ?That means you must
> submit more than one URB. ?If you ever let the queue run dry, so that
> there is no request waiting, then you will miss that frame.

So IN tokens every 125us are not guaranteed? Are guaranteed only if I
submit a enough URBs?

> Also note that there is no guarantee on the timing of the transfers.
> You will have three 1024-byte transfers per microframe, but there’s no
> promise how they will be spaced out. ?You might get three transfers
> neatly spaced 40us apart, but you might get three right in a row,
> followed by a 100us gap before the next one. ?And if your device does
> not have enough data to fill the first transfer, the other two are
> canceled. ?You will have to wait until the next microframe.

IN tokens are guaranteed to be exactly spaced by 125 us (if I submit
enough URBs)?

Thank you so much!
Giorgio

5

Giorgio wrote:

On Tue, Oct 12, 2010 at 7:18 PM, Tim Roberts wrote:
>>
>> Are you sure about your numbers? If you are getting 1024 bytes every
>> 34us, that’s faster than an isochronous pipe. That’s 30MB/sec, but an
>> isochronous pipe is limited to 24MB/sec.
> Yes, I’m sure! But I’ve 4 x 1kb FIFOs and packets of 2500 byte to
> transfer spaced by 33us. So, actually, I’m filling my FIFOs with 2500
> byte in 118us (so 21 MB/sec).

Yes, but remember that these things are bursty. I’ll give you some
examples.

You might be filling your FX2 FIFO at a constant rate, but the data does
not LEAVE at a constant rate. An FX2 FIFO is not freed up until the
entire thing gets sent out the wire. So, the FIFO empties in units of
1024 bytes.

Also, I don’t know what your source is, but video cameras are also
bursty. You tend to get a high transfer rate during video scanlines,
then a pause during horizontal blanking, and an even longer pause during
vertical blanking. So even though the average data rate might fit,
you’d have to do some math to figure out whether your worst case fits
without overflowing.

I eventually created a simulation script for one of my video cameras to
demonstrate that it would eventually overflow the FX2 FIFOs, even though
the average data rate was fine.

>> As long as you make sure there is always a read request ready and
>> waiting, you will get a shot in every microframe. That means you must
>> submit more than one URB. If you ever let the queue run dry, so that
>> there is no request waiting, then you will miss that frame.
> So IN tokens every 125us are not guaranteed? Are guaranteed only if I
> submit a enough URBs?

Of course. If there is no URB waiting, then there will be no IN token.
There is absolutely no buffering anywhere in the USB stack. If you have
not provided a buffer to receive the data, then there is no point in
asking the device to send data.

> IN tokens are guaranteed to be exactly spaced by 125 us (if I submit
> enough URBs)?

No, not at all. You will get your three shots sometime during the
microframe, but there are no guarantees about how they will be spaced.
Here’s an example. Below, I show a series of microframes. The first
shows how you would LIKE your IN tokens to appear, but that’s just
wishful thinking. The other lines show other perfectly legitimate
arrangements that you might see.

0 125 250 375 500us
|------------|------------|------------|------------|
A 1 2 3 1 2 3 1 2 3 1 2 3

B 123 123 123 123

C 123 123 123 123

D 1 2 3 1 2 3 1 2 3 123

Now, unless the bus is busy with other traffic, it’s very likely each
microframe will look the same, but that’s an accident you can’t rely
on. There are no guarantees.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

6

Thank you very much Tim,
now it’s everything clear.

Giorgio